OWASP

資安管理 WebGoat (1)

基本介紹

教學目標

初步了解 WebGoat 平台有系統學習網站漏洞,以利進行後續資安管理。

重點概念

首先 WebGoat 平台主要是由 OWASP 研究開發的弱點測試平台,主要是以 J2EE 進行開發的網站,其中設計了大量的網站漏洞,同時一步一步引導使用者如何利用這些漏洞進行攻擊的方式,以利我們學習資安管理。

接著請先從 OWASP WebGoat 專案官方網站,下載「webgoat-container-7.1-exec.jar」檔案,下一步執行下述指令就能開啟 WebGoat 平台。

1
$ java -jar webgoat-container-7.1-exec.jar

再來開啟瀏覽器輸入「127.0.0.1:8080/WebGoat」網址,下一步輸入使用者帳號和密碼為「webgoat」進行登入 WebGoat 平台,此時畫面的右方為課程分類,中間為課程內容主要有顯示程式碼、解決方式、目標與目的和提示等功能。左方為 HTTP 請求的資料主要顯示 Cookies 和參數。

最後課程分類主要以攻擊方式的類別為主,總共有十六個類別,每個類別還有許多不同的攻擊手法,分別為:

  1. Access Control Flaws
  2. AJAX Security
  3. Authentication Flaws
  4. Buffer Overflows
  5. Code Quality
  6. Concurrency
  7. Cross-Site Scripting (XSS)
  8. Improper Error Handling
  9. Injection Flaws
  10. Denial of Service
  11. Insecure Communication
  12. Insecure Storage
  13. Malicious Execution
  14. Parameter Tampering
  15. Session Management Flaws
  16. Web Services

總結我們可以透過 WebGoat 平台將能夠有系統的學習利用網站漏洞進行攻擊的手法,唯有清楚知道如何駭客如何攻擊網站,才能夠進行網站防守,同時目前許多企業的解決方案皆還是以 J2EE 平台為主,此時我們要能夠因應不同的攻擊手法採取適當的設定,以利達到適當的資安管理。

相關資源

技術標準 OWASP ASVS (1)

基本介紹

教學目標

初步了解 OWASP 組織所提出針對行動應用程式的安全驗證標準。

重點概念

Introduction

OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigor available in the market when it comes to performing web application security verification.

How to Use This Standard

  • To help organization’s develop and maintain secure applications.
  • To allow security service/tools providers and consumers to align their requirements and offerings.

Mobile Verification Requirements

LEVEL 1

An application achieves Level 1 (or Opportunistic) certification if it adequately defends against application security vulnerabilities that are easy to discover.

V17.1

Verify that the client validates SSL certificates

V17.2

Verify that unique device ID (UDID) values are not used as security controls.

V17.3

Verify that the mobile app does not store sensitive data onto shared resources on the device (e.g. SD card or shared folders)

V17.4

Verify that sensitive data is not stored in SQLite database on the device

LEVEL 2

An application achieves Level 2 (or Standard) verification if it also adequately defends against prevalent application security vulnerabilities whose existence poses moderate-to-serious risk.

V17.5

Verify that secret keys or passwords are not hard-coded in the executable.

V17.6

Verify that the mobile app prevents leaking of sensitive data via autosnapshot feature of iOS.

V17.7

Verify that the app cannot be run on a jailbroken or rooted device.

V17.8

Verify that the session timeout is of a reasonable value.

V17.9

Verify the permissions being requested as well as the resources that it is authorized to access (i.e. AndroidManifest.xml, iOS Entitlements) .

V17.11

Verify that the application binary has been obfuscated.

V17.12

Verify that all test data has been removed from the app container (.ipa, .apk, .bar).

V17.13

Verify that the application does not log sensitive data to the system log or filesystem.

V17.14

Verify that the application does not enable autocomplete for sensitive text input fields, such as passwords, personal information or credit cards.

LEVEL 3

An application achieves Level 3 (or Advanced) certification if it also adequately defends against all advanced application security vulnerabilities, and also demonstrates principles of good security design.

V17.10

Verify that crash logs do not contain sensitive data.

V17.15

Verify that the mobile app implements certificate pinning to prevent the proxying of app traffic.

V17.16

Verify no misconfigurations are present in the configuration files (Debugging flags set, world readable/writable permissions) and that, by default, configuration settings are set to their safest/most secure value.

V17.17

Verify any 3rd-party libraries in use are up to date, contain no known vulnerabilities.

V17.18

Verify that web data, such as HTTPS traffic, is not cached.

V17.19

Verify that the query string is not used for sensitive data. Instead, a POST request via SSL should be used with a CSRF token.

V17.20

Verify that, if applicable, any personal account numbers are truncated prior to storing on the device.

V17.21

Verify that the application makes use of Address Space Layout Randomization (ASLR).

V17.22

Verify that data logged via the keyboard (iOS) does not contain credentials, financial information or other sensitive data.

V17.23

If an Android app, verify that the app does not create files with permissions of MODE_WORLD_READABLE or MODE_WORLD_WRITABLE

V17.24

Verify that sensitive data is stored in a cryptographically secure manner (even when stored in the iOS keychain).

V17.25

Verify that anti-debugging and reverse engineering mechanisms are implemented in the app.

V17.26

Verify that the app does not export sensitive activities, intents, content providers etc. on Android.

V17.27

Verify that mutable structures have been used for sensitive strings such as account numbers and are overwritten when not used. (Mitigate damage from memory analysis attacks).

V17.28

Verify that any exposed intents, content providers and broadcast receivers perform full data validation on input (Android).

相關資源