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

什麼是 Level 2A 安全測試(Penetration Test)?
本階段的要求細項又稱為人工滲透測試要求。你必須建立動態測試以驗證應用程式符合適當的設計、適當的實作和適當的使用安全控制措施。以下是 2A 的安全架構要求：
  • L2A.1 根據 Level 2A 的驗證要求細項(Detail Verification Requirements)，人工執行應用程式的安全測試。
什麼是 Level 2B 原始碼檢查(Code Review)?
Code Review 指的是對應用程式的原始碼以人工搜尋和分析，來驗證應用程式符合適當的設計、適當的實作和適當的使用安全控制措施。以下是 2B 的安全架構要求：
  • L2B.1 根據 Level 2B 的驗證要求細項(Detail Verification Requirements)，人工執行應用程式的原始碼檢查。
驗證者可以抽樣檢查，確立安全控制措施的正確使用方式。並整理一份弱點特徵的文件作為軟體基本規則，使開發者可以有信心找出並修復應用程式的問題。而檢測的原則是要盡量收斂，也就是說，來自同樣來源的不同弱點應該視為同一弱點。
詳細的的驗證要求有哪些?
ASVS 驗證要求細項共分為14大項。

V1. 建立安全架構的文件(Security Architecture)
為了滿足基礎安全，你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能追蹤到高階安全架構。Level 2A 應滿足，Level 2B應滿足：

  V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。
  V1.2 能正確辨識不屬於應用程式內但被引用的元件。
  V1.3 針對應用程式的高階架構建立文件。例如: MVC、UML、企業流程等。

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

  V2.1 除了公開資源以外，所有頁面和資源都須經過身分鑑別，才能存取。
  V2.2 所有密碼不能以任何方式顯示在網頁上。
  V2.3 當身分鑑別的失敗次數過多，應用程式需自動將該帳號鎖定，而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。
  V2.4 所有的身分鑑別控制措施都實作在 Server 端。
  V2.5 身分鑑別的控制措施即使失效，也應安全的失效( Fail Securely )。
  V2.6 身分鑑別的使用者憑證( Credential、Password )應具有一定強度，能抵抗開發環境的一般攻擊。
  V2.7 使用者帳戶的管理功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。
  V2.8 使用者修改憑證的功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。
  V2.9 執行特別敏感的操作之前，須要再次進行身分鑑別。
  V2.10 使用者的憑證應定期失效。
  V2.11 為了維持身分鑑別的真確性，身分鑑別控制措施應集中化建置，跟鑑別有關的功能都應使用相同的控制措施。
  V2.12 所有身分鑑別的結果都應記錄( Logging )。
  V2.13 所有密碼都應加入獨一無二的鹽，再進行雜湊。( Hash and Salt )
  V2.14 應用程式用以存取外部服務的身分憑證，應加密後妥善保存，不能 Hard Code 在程式碼中。

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

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

  V4.1 使用者須經過授權才能存取受保護的功能。
  V4.2 使用者須經過授權才能存取受保護的URL。
  V4.3 使用者須經過授權才能存取受保護的檔案。
  V4.4 物件或檔案的直接連結只有經過授權的使用者才能存取。
V4.5 網站目錄不能被直接瀏覽，除非特別設計過。
  V4.6 使用者存取特定服務時，需要經過特定授權。
  V4.7 使用者存取特定資料時，需要經過特定授權。
  V4.8 存取控制措施即使失效，也應安全的失效。
  V4.9 展示層(例如 MVC 的 View )的存取控制，應實作在 Server 端。
  V4.10 關於存取控制的政策、使用者屬性和資料屬性，非經授權不能被使用者修改。
  V4.11 存取控制應在Server 端執行。
  V4.12 企業中有關輸入資料和讀取資料的限制不能被略過。(例：每日交易次數上限、佇列中的任務上限)
  V4.13 無論保護何種資源的存取，都應以集中管理的技巧實作，任何存取行為都使用同樣控制措施。
  V4.14 有關存取控制的決策，無論成功或失敗都應記錄( Logging )，以備稽核。

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

  V5.1 應用程式的執行環境不能有緩衝區溢位問題，即使有也能避免影響到應用程式。
  V5.2 所有輸入資料都使用正向驗證規則(Positive Validation、又稱白名單規則)。
  V5.3 當輸入資料驗證失敗後，應該退回、或消毒(過濾特殊字元)此筆資料。
  V5.4 任何來源的輸入資料都應使用相同的字元集。(例 utf-8)
  V5.5 驗證輸入資料的功能應實作在Server端。
  V5.6 不同類型的資料應使用同樣的驗證控制。
  V5.7 輸入資料的驗證失敗應紀錄( Logging )。

V6.輸出內容編碼(Output Encoding/Escaping)
本項目要求，所有輸出資料應該適當的編碼再輸出到瀏覽器。Level 2A 應滿足，Level 2B應滿足：

  V6.1 所有不受信任的資料(包含HTML元素、HTML屬性、Javascript、CSS和 URI 屬性)輸出到HTML網頁前，必須轉譯敏感字元(例如<> 轉換成&lt;&gt;)。
  V6.2 輸出資料的編碼(Encode)和跳脫(Escape)應實作在Server端。
  V6.3 不確定是否安全的字元都應經過編碼或跳脫，再傳給直譯器。(例 javascript Interpreter)
  V6.4 不受信任的資料輸出到 SQL 直譯器之前，應使用參數化界面(Parameterized Interface)、預查詢(Prepare Statement)。
  V6.5 不受信任的資料輸出到 XML 直譯器之前，應使用參數化界面(Parameterized Interface)。
  V6.6 不受信任的資料輸出到 LDAP 查詢句之前，應適當的跳脫特殊字元。
  V6.7 不受信任的資料被引用到作業系統命令的參數之前，應適當的跳脫特殊字元。
  V6.8 不受信任的資料輸出到其他直譯器之前，應適當的跳脫特殊字元。

V7.密碼學(Cryptography)
本項目要求包含：應用程式的加密方法、金鑰管理、亂數、雜湊運算。你可以參考 FIPS 140-2 標準，採取符合美國國家標準的密碼模組。Level 2A 應滿足，Level 2B應滿足：

  V7.1 用以保護秘密的加密功能應實作在 Server 端。
  V7.2 加密的模組即使失效，也應安全的失效。
  V7.3 任何主密鑰都應保護，避免未經授權的存取。(Master Secret用以產生次密鑰的依據)
  V7.4 產生密碼的雜湊值都應加鹽 ( Hash and Salt ) 。
  V7.5 加密模組的失敗也應記錄。
  V7.6 使用政府認可的亂數產生器。

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

  V8.1 所有錯誤訊息不能包含敏感資料，例如：Session ID 或 使用者個人資訊。
  V8.2 Server端的錯誤應由Server端處理。
  V8.3 記錄( Logging )的控制應實作在Server 端。
  V8.4 安全控制措施中的錯誤訊息處理邏輯應預設為拒絕存取。
  V8.5 記錄控制措施應能記錄關於安全的所有成功和失敗的事件。
  V8.6 記錄檔的格式應包含，可靠的時間紀錄、事件嚴重性、是否跟安全有關、引起事件的使用者id、來源ip、成功或失敗的事件、事件描述。
  V8.7 所有事件紀錄包含不受信任的資料，都不會被記錄檢視的軟體當作程式碼執行。
  V8.8 安全事件紀錄未經授權不得存取和修改。
  V8.9 應用程式的事件紀錄功能應實作在單一元件上。
  V8.10 事件紀錄不能包含敏感資料，例如：Session ID 或 使用者個人資訊。
  V8.11 應使用事件紀錄的分析工具，能以複合條件分析、查詢紀錄。

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

  V9.1 機敏資料不得存放在客戶端的快取，也不能啟用自動完成功能。
  V9.2 敏感資料應建檔管理，並建立明確政策，規定存取限制。
  V9.3 敏感資料應存放在 HTTP 訊息的 Body，而非URL。
  V9.4 送至 Client 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。
  V9.5 存放在 Server 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。

V10. 通訊安全(Communication Security)
本項目包含，確保應用程式的通訊過程是安全的。Level 2A 應滿足，Level 2B應滿足：
  V10.1 確保可信任憑證中心(Trusted CA)和 TLS 憑證之間的路徑暢通，且憑證是有效的。
  V10.2 失敗的TLS連線，不能還原成未加密的連線。
  V10.3 身分驗證或存取敏感資料的功能都應使用 TLS 。
  V10.4 TLS 連線失敗應記錄。
  V10.5 確認憑證路徑的正確性、確認所有客戶端的憑證都包含可信任的根中心(Trusted Anchor)和到期資訊。
  V10.6 與外部系統的連線若包含敏感資料和功能，應先經過驗證。
  V10.7 與外部系統的連線若包含敏感資料和功能，應使用最小權限的帳號。

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

  V11.1 網頁重新轉向(Redirect)不應包含未驗證的資料。
  V11.2 應用程式的POST、GET應制訂規則，定義使用的方法。
  V11.3 HTTP response 的 header 應包含一種安全字元集，例如UTF-8。
  V11.4 不需要被客戶端以 Javascript 存取的 Cookies 應加上 HTTPOnly 的屬性。
  V11.5 包含敏感資訊的 Cookies 應加上 Secure Flag 。
  V11.6 Request 和 Response 的 HTTP Header 應只包含 可顯示的 ASII 字元。

V12. 環境設定(Security Configeration)
本項目包含：應用程式環境中的所有和安全有關的設定檔應存放在安全的位置。保護設定檔資訊對於應用程式的安全是很重要的。Level 2A 應滿足，Level 2B應滿足：

  V12.1 與安全相關的設定檔，未經授權不能存取。
  V12.2 當應用程式無法讀取本身的安全設定檔，應拒絕所有連線。

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

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

下次我們將介紹 Level 3 系統設計驗證的要求。

參考資料
----

留言

張貼留言

這個網誌中的熱門文章

資安JAVA(四)：Session Cookie HTTPOnly Flag

圖片
來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 4 – SESSION COOKIE HTTPONLY FLAG 作者：John Melton 內文： What is it and why do I care? Session cookies(或是包含 JSESSIONID 的 cookie)用來管理WEB應用程式的 Session。這些 Cookies 包含特定使用者的 Session ID 的參考值，而同樣的 ID 也放在伺服器端並可識別該使用者其他的 Session 資料。這是最常用的管理方式，因為 cookies 會隨著每次 request 送出。 HttpOnly flag 作用是預防攻擊者透過 XSS 弱點獲得 session cookie。一旦 XSS 攻擊者成功，攻擊者便可以挾持受害者的 session 以合法身分登入。HttpOnly flag 對於這種攻擊十分有效。
更多詳細 »

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

有個需求是收聽網站的流量，檢查是否有包含特定格式資訊的封包。從幾天前開始思考相關實作的問題。 如何檢查有人透過 Http 方式連線到網站? 側錄本機或同網段的封包才能滿足收聽的需求。Http協定送出的封包，到了底層是走tcp/ip，只要能夠抓取tcp/ip封包，並轉換成可處理的格式，就能檢查是否有人送出資訊。 今天的情境是要監聽同網段的網站流量，於是開始搜尋可用工具。其中，在Windows環境最有名的就是 WinPcap ，網路上已經有熱心人士提供包裹在 C# 的元件，只要先安裝好WinPcap，然後下載元件到自己的應用程式，即可收聽封包。該元件就是 SharpPcap ，2004年，美國的 Tamir Gal 為了完成大學的專案，在.NET 應用程式中使用 WinPcap 的功能，因此順便開發了SharpPcap 。他甚至寫了範例，使得開發人員可以更快學習如何利用他的元件，詳細資料請到  他的網站 。 如何使用SharpPcap ? 第一，下載 WinPcap，並妥善安裝完畢。( 下載連結 ) 第二，下載 SharpPcap 。( 下載連結 ) 第三，將 PacketDotNet.dll 和 SharpPcap.dll 加入到應用程式的參考中。 using SharpPcap; using SharpPcap.LibPcap; using PacketDotNet;
更多詳細 »

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

圖片
來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 8 – HTTP STRICT TRANSPORT SECURITY 作者：John Melton 內文： Safe path. What is it and why should I care? HTTP強制安全傳輸技術，強制所有瀏覽器只能透過SSL或TLS連線到網站。 只要在HTTP網頁標頭加上特殊的HSTS，支援HSTS的瀏覽器就會限定只能經由HTTPS連線。以下是流程： 第一步，使用者造訪網站，不論透過HTTP或HTTPS。通常大部分是HTTP。 第二步，網站輸出網頁，內容包含HSTS標頭。90天內都只能透過HTTPS連線。 第三步，支援HSTS的瀏覽器90天內都不會送出 "非SSL" 的要求給網站。
更多詳細 »