ASVS 應用程式安全驗證標準(三)、Level 1A & 1B 要求細項

什麼是 Level 1A 動態掃描(Dynamic Scan) ?
動態掃描(Dynamic scan、application vulnerability scanning),當應用程式正在執行時,使用自動化工具存取應用程式的執行路徑。目的是藉由工具模擬使用者的行為,找出應用程式的弱點。須注意的是,這種黑箱工具不適合檢驗,程式架構、實作品質、安全控制點的使用。

1A 有哪些步驟 ?
Level 1A 動態掃描安全控制驗證要求(Dynamic Scanning Security Control Verification Requirements)包含以下兩個步驟:
  • L1A.1 根據"驗證要求細項(Detail Verification Requirements)",執行應用程式的動態掃描。
  • L1A.2 利用人工滲透測試(Pen test)或源碼檢視(Code review),驗證動態掃描的結果。沒有經過人工驗證的掃描結果,不能證明為滿足 Level 1 的要求。
這兩個步驟完成之後,你便可以宣稱應用程式滿足 Level 1A 的要求。或者你可以宣稱你的資安解決方案可以幫助WEB應用程式達到 Level 1A 的要求。

什麼是 Level 1B 原始碼掃描(Source Code Scan) ?
原始碼掃描(Source Code Scan、Static Analysis Scan),利用自動化工具搜尋程式中符合漏洞特徵的原始碼。須注意的是,這種檢測方式不適合檢驗,程式架構、實作品質、安全控制點的使用。

1B 有哪些步驟 ?
Level 1B 原始碼掃描安全控制驗證要求(Source Code Scanning Security Control Verification Requirements)包含以下兩個步驟:
  • L1B.1 根據"驗證要求細項(Detail Verification Requirements)",執行應用程式的原始碼掃描。
  • L1B.2 利用人工滲透測試(Pen test)或源碼檢視(Code review),驗證原始碼掃描的結果。沒有經過人工驗證的掃描結果,不能證明為滿足 Level 1 的要求。
這兩個步驟完成之後,你便可以宣稱應用程式滿足 Level 1B 的要求。或者你可以宣稱你的資安解決方案可以幫助WEB應用程式達到 Level 1B 的要求。

Level 1A & 1B 有哪些詳細要求 ?
ASVS 驗證要求細項(Detail Verification Requirements)共分為14大項。安全的架構、身分鑑別、Session 管理機制、存取控制、輸入資料驗證、輸出內容編碼、密碼學、錯誤訊息管理和紀錄、資料保護、通訊安全、HTTP 安全、環境設定、尋找惡意程式碼和內部安全。

註:要達成 Level 1A & 1B 只需要滿足14大項目其中幾個項目即可。
V1. 建立安全架構的文件(Security Architecture)
為了滿足基礎安全,你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能追蹤到高階安全架構。例如:假設檢測結果指出您的"一般會員購物車.php" 和"VIP會員購物車.php"存在著 XSS 漏洞,剛好這兩著繼承自相同的"購物模組.php",表示問題可能來自於系統中的購物模組。Level 1A 應滿足,Level 1B 應滿足

  V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。

V2. 身分鑑別(Authentication)
本項目將要求你安全的建立和控管使用者的認證資訊。Level 1A 應滿足,Level 1B 應滿足

  V2.1 除了公開資源以外,所有頁面和資源都須經過身分鑑別,才能存取。
  V2.2 所有密碼不能以任何方式顯示在網頁上。
  V2.3 當身分鑑別的失敗次數過多,應用程式需自動將該帳號鎖定,而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。

V3. Session 管理機制(Session Management)
本項目包含以下要求: 安全的使用:Http request、response、session、cookies、headers,並適當的紀錄session狀況到log。 Level 1A 應滿足,Level 1B 應滿足
  V3.1 應用程式已經採用framework 預設的控制項。
  V3.2 當使用者登出時,session 應當失效。
  V3.3 當使用者停止活動一段時間時,session 應當失效。
  V3.4 需身分鑑別後才能使用的所有頁面,都存在登出功能。
  V3.5 Session id 不能包含在URL、錯誤訊息、Log,且重送URL不能取得合法的Session、Cookies。

V4. 存取控制(Access Control)
大部分的應用程式都會根據不同類別的使用者提供不同的服務。本項目包含各種資源的存取控制:URL、商業功能、資料、服務和檔案。Level 1A 應滿足,Level 1B 應滿足

  V4.1 使用者須經過授權才能存取受保護的功能。
  V4.2 使用者須經過授權才能存取受保護的URL。
  V4.3 使用者須經過授權才能存取受保護的檔案。
  V4.4 物件或檔案的直接連結只有經過授權的使用者才能存取。
  V4.5 網站目錄不能被直接瀏覽,除非特別設計過。

V5. 輸入資料驗證(Input Validation)
當所有輸入資料都是通過合法驗證的,才能保證安全的使用應用程式。Level 1A 應滿足,Level 1B 應滿足

  V5.1 應用程式的執行環境不能有緩衝區溢位問題,即使有也能避免影響到應用程式。
  V5.2 所有輸入資料都使用正向驗證規則(Positive Validation、又稱白名單規則)。
  V5.3 當輸入資料驗證失敗後,應該退回、或消毒(過濾特殊字元)此筆資料。
V6.輸出內容編碼(Output Encoding/Escaping)
本項目要求,所有輸出資料應該適當的編碼再輸出到瀏覽器。Level 1A 應滿足,Level 1B 應滿足

  V6.1 所有不受信任的資料(包含HTML元素、HTML屬性、Javascript、CSS和 URI 屬性)輸出到HTML網頁前,必須轉譯敏感字元(例如<> 轉換成&lt;&gt;)。

V7.密碼學(Cryptography)
本項目對象是通過 Level 1的應用程式,包含:應用程式的加密方法、金鑰管理、亂數、雜湊運算。你可以參考 FIPS 140-2 標準,採取符合美國國家標準的密碼模組。Level 1 在此項目並不用滿足任何要求。

V8. 錯誤訊息管理和紀錄(Error Handling and Logging)
本項目包含,追蹤相關資安事件和攻擊行為的特徵。Level 1A 應滿足,Level 1B 應滿足

  V8.1 所有錯誤訊息不能包含敏感資料,例如:Session ID 或 使用者個人資訊。

V9. 資料保護(Date Protection)
保護機敏資料保括信用卡號、護照號碼、個人ID,是本項目的主要要求。Level 1A 應滿足,Level 1B 應滿足

  V9.1 機敏資料不得存放在客戶端的快取,也不能啟用自動完成功能。

V10. 通訊安全(Communication Security)
本項目包含,確保應用程式的通訊過程是安全的。Level 1A 應滿足,Level 1B 應滿足
  V10.1 確保可信任憑證中心(Trusted CA)和 TLS 憑證之間的路徑暢通,且憑證是有效的。

V11. HTTP 安全(HTTP Security)
本項目包含,所有HTTP相關的安全要求,包括request、response、session、cookies、headers、logging。Level 1A 應滿足,Level 1B 應滿足

  V11.1 網頁重新轉向(Redirect)不應包含未驗證的資料。
  V11.2 應用程式的POST、GET應制訂規則,定義使用的方法。
  V11.3 HTTP response 的 header 應包含一種安全字元集,例如UTF-8。

V12. 環境設定(Security Configeration)
本項目對象是通過 Level 2的應用程式,要求如下:應用程式環境中的所有和安全有關的設定檔應存放在安全的位置。保護設定檔資訊對於應用程式的安全是很重要的。Level 1 在此項目並不用滿足任何要求 。

V13. 惡意程式碼的搜尋(Malicious Code Search)
本項目對象是通過 Level 3的應用程式,確保應用程式中完全不包含惡意程式碼( 被掛馬 )。Level 1 在此項目並不用滿足任何要求。

V14. 內部安全(Internal Security)
本項目對象是通過 Level 2的應用程式,確保應用程式中擁有自我驗證保護,避免內部開發人員的實作缺失或是邏輯炸彈。Level 1 在此項目並不用滿足任何要求。

下次我們將介紹 Level 2 人工驗證。

留言

這個網誌中的熱門文章

資安JAVA(八):HTTP強制傳輸安全(HSTS)

以 SharpPcap 實作可收聽封包的 C# 程式

資安JAVA(四):Session Cookie HTTPOnly Flag