ASVS 應用程式安全驗證標準(九)、Level 3 & 4 要求細項
Level 3 & 4 詳細的的驗證要求有哪些?
ASVS 驗證要求細項共分為14大項。
V1. 建立安全架構的文件(Security Architecture)
為了滿足基礎安全，你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能對應到高階安全架構。Level 3 應滿足
，Level 4 應滿足
：
V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。
V1.2 能正確辨識不屬於應用程式內但被引用的元件。
V1.3 針對應用程式的高階架構建立文件。例如: MVC、UML、企業流程等。
V1.4 不屬於應用程式內但被引用的元件，應對應到企業功能或安全功能。
V1.5 提供威脅模擬資訊( Threat Modeling )。
V2. 身分鑑別(Authentication)
本項目將要求你安全的建立和控管使用者的認證資訊。Level 3 應滿足，Level 4 應滿足：
V2.1 除了公開資源以外，所有頁面和資源都須經過身分鑑別，才能存取。
V2.2 所有密碼不能以任何方式顯示在網頁上。
V2.3 當身分鑑別的失敗次數過多，應用程式需自動將該帳號鎖定，而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。
V2.4 所有的身分鑑別控制措施都實作在 Server 端。
V2.6 身分鑑別的使用者憑證( Credential、Password )應具有一定強度，能抵抗開發環境的一般攻擊。
V2.7 使用者帳戶的管理功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。
V2.8 使用者修改憑證的功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。
V2.9 執行特別敏感的操作之前，須要再次進行身分鑑別。
V2.10 使用者的憑證應定期失效。
V2.11 為了維持身分鑑別的真確性，身分鑑別控制措施應集中化建置，跟鑑別有關的功能都應使用相同的控制措施。
V2.12 所有身分鑑別的結果都應記錄( Logging )。
V2.14 應用程式用以存取外部服務的身分憑證，應加密後妥善保存，不能 Hard Code 在程式碼中。
V2.15 所有身分鑑別控制措施的程式碼，都沒有受到惡意程式碼的影響。
V3. Session 管理機制(Session Management)
本項目包含以下要求： 安全的使用：Http request、response、session、cookies、headers，並適當的紀錄session狀況到log。Level 3 應滿足，Level 4 應滿足：
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 才視為有效。
V3.10 逾時控制措施應採用絕對逾時方式，無論使用者執行多少動作，一定時間後必強制逾時。
V3.11 身分鑑別的會談權杖( Session Token )的長度應夠長且隨機，以抵抗部署環境中的一般攻擊。
V3.12 包含身分鑑別 Session ids/tokens 的 Cookies 應設定限制其網域( Domain )和路徑( Path )一個合理的值。
V3.13 所有 Session 管理控制措施的程式碼，都沒有受到惡意程式碼的影響。
V4. 存取控制(Access Control)
大部分的應用程式都會根據不同類別的使用者提供不同的服務。本項目包含各種資源的存取控制：URL、商業功能、資料、服務和檔案。Level 3 應滿足，Level 4 應滿足：
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 )，以備稽核。
V4.15 所有存取控制措施的程式碼，都沒有受到惡意程式碼的影響。
V5. 輸入資料驗證(Input Validation)
當所有輸入資料都是通過合法驗證的，才能保證安全的使用應用程式。Level 3 應滿足，Level 4 應滿足：
V5.1 應用程式的執行環境不能有緩衝區溢位問題，即使有也能避免影響到應用程式。
V5.2 所有輸入資料都使用正向驗證規則(Positive Validation、又稱白名單規則)。
V5.3 當輸入資料驗證失敗後，應該退回、或消毒(過濾特殊字元)此筆資料。
V5.4 任何來源的輸入資料都應使用相同的字元集。(例 utf-8)
V5.5 驗證輸入資料的功能應實作在Server端。
V5.6 不同類型的資料應使用同樣的驗證控制。
V5.7 輸入資料的驗證失敗應紀錄( Logging )。
V5.8 所有輸入資料都應在驗證之前先正規化( Canonicalization )。
V5.9 所有輸入資料控制措施的程式碼，都沒有受到惡意程式碼的影響。
ASVS 驗證要求細項共分為14大項。
V1. 建立安全架構的文件(Security Architecture)
為了滿足基礎安全，你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能對應到高階安全架構。Level 3 應滿足
，Level 4 應滿足： V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。 V1.2 能正確辨識不屬於應用程式內但被引用的元件。 V1.3 針對應用程式的高階架構建立文件。例如: MVC、UML、企業流程等。 V1.4 不屬於應用程式內但被引用的元件，應對應到企業功能或安全功能。 V1.5 提供威脅模擬資訊( Threat Modeling )。V2. 身分鑑別(Authentication)
本項目將要求你安全的建立和控管使用者的認證資訊。Level 3 應滿足
，Level 4 應滿足： V2.1 除了公開資源以外，所有頁面和資源都須經過身分鑑別，才能存取。 V2.2 所有密碼不能以任何方式顯示在網頁上。 V2.3 當身分鑑別的失敗次數過多，應用程式需自動將該帳號鎖定，而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。 V2.4 所有的身分鑑別控制措施都實作在 Server 端。 V2.6 身分鑑別的使用者憑證( Credential、Password )應具有一定強度，能抵抗開發環境的一般攻擊。 V2.7 使用者帳戶的管理功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。 V2.8 使用者修改憑證的功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。 V2.9 執行特別敏感的操作之前，須要再次進行身分鑑別。 V2.10 使用者的憑證應定期失效。 V2.11 為了維持身分鑑別的真確性，身分鑑別控制措施應集中化建置，跟鑑別有關的功能都應使用相同的控制措施。 V2.12 所有身分鑑別的結果都應記錄( Logging )。 V2.14 應用程式用以存取外部服務的身分憑證，應加密後妥善保存，不能 Hard Code 在程式碼中。 V2.15 所有身分鑑別控制措施的程式碼，都沒有受到惡意程式碼的影響。V3. Session 管理機制(Session Management)
本項目包含以下要求： 安全的使用：Http request、response、session、cookies、headers，並適當的紀錄session狀況到log。Level 3 應滿足
，Level 4 應滿足： 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 才視為有效。 V3.10 逾時控制措施應採用絕對逾時方式，無論使用者執行多少動作，一定時間後必強制逾時。 V3.11 身分鑑別的會談權杖( Session Token )的長度應夠長且隨機，以抵抗部署環境中的一般攻擊。 V3.12 包含身分鑑別 Session ids/tokens 的 Cookies 應設定限制其網域( Domain )和路徑( Path )一個合理的值。 V3.13 所有 Session 管理控制措施的程式碼，都沒有受到惡意程式碼的影響。V4. 存取控制(Access Control)
大部分的應用程式都會根據不同類別的使用者提供不同的服務。本項目包含各種資源的存取控制：URL、商業功能、資料、服務和檔案。Level 3 應滿足
，Level 4 應滿足： 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 )，以備稽核。 V4.15 所有存取控制措施的程式碼，都沒有受到惡意程式碼的影響。V5. 輸入資料驗證(Input Validation)
當所有輸入資料都是通過合法驗證的，才能保證安全的使用應用程式。Level 3 應滿足
，Level 4 應滿足： V5.1 應用程式的執行環境不能有緩衝區溢位問題，即使有也能避免影響到應用程式。 V5.2 所有輸入資料都使用正向驗證規則(Positive Validation、又稱白名單規則)。 V5.3 當輸入資料驗證失敗後，應該退回、或消毒(過濾特殊字元)此筆資料。 V5.4 任何來源的輸入資料都應使用相同的字元集。(例 utf-8) V5.5 驗證輸入資料的功能應實作在Server端。 V5.6 不同類型的資料應使用同樣的驗證控制。 V5.7 輸入資料的驗證失敗應紀錄( Logging )。 V5.8 所有輸入資料都應在驗證之前先正規化( Canonicalization )。 V5.9 所有輸入資料控制措施的程式碼，都沒有受到惡意程式碼的影響。
V6.輸出內容編碼(Output Encoding/Escaping)
本項目要求，所有輸出資料應該適當的編碼再輸出到瀏覽器。Level 3 應滿足，Level 4 應滿足：
V6.1 所有不受信任的資料(包含HTML元素、HTML屬性、Javascript、CSS和 URI 屬性)輸出到HTML網頁前，必須轉譯敏感字元(例如<> 轉換成<>)。
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 不受信任的資料輸出到其他直譯器之前，應適當的跳脫特殊字元。
V6.9 所有經過應用程式編碼或跳脫的輸出資料，都應有對應的安全控制措施。
V6.10 所有輸入驗證控制措施的程式碼，都沒有受到惡意程式碼的影響。
V7.密碼學(Cryptography)
本項目要求包含：應用程式的加密方法、金鑰管理、亂數、雜湊運算。你可以參考 FIPS 140-2 標準，採取符合美國國家標準的密碼模組。Level 3 應滿足，Level 4 應滿足：
V7.1 用以保護秘密的加密功能應實作在 Server 端。
V7.2 加密的模組即使失效，也應安全的失效。
V7.3 任何主密鑰都應保護，避免未經授權的存取。(Master Secret用以產生次密鑰的依據)
V7.4 產生密碼的雜湊值都應加鹽 ( Hash and Salt ) 。
V7.5 加密模組的失敗也應記錄。
V7.6 使用政府認可的亂數產生器。
V7.7 使用 FIPS-140-2 或相等標準驗證通過的加密模組。(可參考 MODULE VALIDATION LISTS )
V7.8 加密模組應以通過驗證的模式運作，並遵守安全政策。(可參考 MODULE VALIDATION LISTS )
V7.9 制定明確政策，規定加密金鑰的管理規範。
V7.10 所有加密模組的程式碼，都沒有受到惡意程式碼的影響。
V8. 錯誤訊息管理和紀錄(Error Handling and Logging)
本項目包含，追蹤相關資安事件和攻擊行為的特徵。Level 3 應滿足，Level 4 應滿足：
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 應使用事件紀錄的分析工具，能以複合條件分析、查詢紀錄。
V8.12 所有錯誤管理和紀錄控制措施的程式碼，都沒有受到惡意程式碼的影響。
V9. 資料保護(Date Protection)
保護機敏資料保括信用卡號、護照號碼、個人ID，是本項目的主要要求。Level 3 應滿足，Level 4 應滿足：
V9.1 機敏資料不得存放在客戶端的快取，也不能啟用自動完成功能。
V9.2 敏感資料應建檔管理，並建立明確政策，規定存取限制。
V9.3 敏感資料應存放在 HTTP 訊息的 Body，而非URL。
V9.4 送至 Client 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。
V9.5 存放在 Server 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。
V9.6 當敏感資料的有效取的時間到期之後，應有刪除資料的做法。
V10. 通訊安全(Communication Security)
本項目包含，確保應用程式的通訊過程是安全的。Level 3 應滿足，Level 4 應滿足：
V10.1 確保可信任憑證中心(Trusted CA)和 TLS 憑證之間的路徑暢通，且憑證是有效的。
V10.2 失敗的TLS連線，不能還原成未加密的連線。
V10.3 身分驗證或存取敏感資料的功能都應使用 TLS 。
V10.4 TLS 連線失敗應記錄。
V10.5 確認憑證路徑的正確性、確認所有客戶端的憑證都包含可信任的根中心(Trusted Anchor)和到期資訊。
V10.6 與外部系統的連線若包含敏感資料和功能，應先經過驗證。
V10.7 與外部系統的連線若包含敏感資料和功能，應使用最小權限的帳號。
V10.8 應用程式應使用經過驗證的標準 TLS 。
V10.9 所有連線都已規定使用特定的字元集，例如：UTF-8。
V11. HTTP 安全(HTTP Security)
本項目包含，所有HTTP相關的安全要求，包括request、response、session、cookies、headers、logging。Level 3 應滿足，Level 4 應滿足：
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 字元。
V11.7 所有交易與敏感資料處理的連結和表單都應加上有效的亂數權杖( Random Token )，而且應用程式應檢查 Server 端使用者權杖和 Client 端送來 Request 的權杖是否相同。
V12. 環境設定(Security Configeration)
本項目包含：應用程式環境中的所有和安全有關的設定檔應存放在安全的位置。保護設定檔資訊對於應用程式的安全是很重要的。Level 3 應滿足，Level 4 應滿足：
V12.1 與安全相關的設定檔，未經授權不能存取。
V12.2 當應用程式無法讀取本身的安全設定檔，應拒絕所有連線。
V12.3 應用程式更動安全設定檔的行為，應記錄在安全事件紀錄檔。
V12.4 所有設定檔能輸出易於稽核、可人工閱讀的格式。
V13. 惡意程式碼的搜尋(Malicious Code Search)
本項目包含：確保應用程式中完全不包含惡意程式碼(被掛馬)。Level 3 應滿足，Level 4 應滿足：
V13.1 建立應用程式前，驗證任何惡意程式碼都不存在。
V13.2 利用檢查碼或 Hash 值，驗證程式碼、函式庫、執行檔、設定檔的真確性。
V14. 內部安全(Internal Security)
本項目包含：確保應用程式中擁有自我驗證保護，避免內部開發人員的實作缺失或是邏輯炸彈。Level 3 應滿足，Level 4 應滿足：
V14.1 應用程式保護使用者和資料的屬性，且制定存取控制措施的政策，以防止未授權存取或修改。
V14.2 安全控制措施應設計的簡單、正確，讓開發者樂於使用。
V14.3 應用程式應保護共享變數和資源，以防止不當的非同步存取。
下次我們將介紹驗證報表的格式。此報表應包含簡介、應用程式描述、應用程式架構、驗證結果等。善用此報表可以了解不同的檢測服務能為你做到甚麼，並進一步減少組織內開發人員和管理者之間的代溝。
參考資料
本項目要求，所有輸出資料應該適當的編碼再輸出到瀏覽器。Level 3 應滿足
，Level 4 應滿足： V6.1 所有不受信任的資料(包含HTML元素、HTML屬性、Javascript、CSS和 URI 屬性)輸出到HTML網頁前，必須轉譯敏感字元(例如<> 轉換成<>)。 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 不受信任的資料輸出到其他直譯器之前，應適當的跳脫特殊字元。 V6.9 所有經過應用程式編碼或跳脫的輸出資料，都應有對應的安全控制措施。 V6.10 所有輸入驗證控制措施的程式碼，都沒有受到惡意程式碼的影響。V7.密碼學(Cryptography)
本項目要求包含：應用程式的加密方法、金鑰管理、亂數、雜湊運算。你可以參考 FIPS 140-2 標準，採取符合美國國家標準的密碼模組。Level 3 應滿足
，Level 4 應滿足： V7.1 用以保護秘密的加密功能應實作在 Server 端。 V7.2 加密的模組即使失效，也應安全的失效。 V7.3 任何主密鑰都應保護，避免未經授權的存取。(Master Secret用以產生次密鑰的依據) V7.4 產生密碼的雜湊值都應加鹽 ( Hash and Salt ) 。 V7.5 加密模組的失敗也應記錄。 V7.6 使用政府認可的亂數產生器。 V7.7 使用 FIPS-140-2 或相等標準驗證通過的加密模組。(可參考 MODULE VALIDATION LISTS ) V7.8 加密模組應以通過驗證的模式運作，並遵守安全政策。(可參考 MODULE VALIDATION LISTS ) V7.9 制定明確政策，規定加密金鑰的管理規範。 V7.10 所有加密模組的程式碼，都沒有受到惡意程式碼的影響。V8. 錯誤訊息管理和紀錄(Error Handling and Logging)
本項目包含，追蹤相關資安事件和攻擊行為的特徵。Level 3 應滿足
，Level 4 應滿足： 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 應使用事件紀錄的分析工具，能以複合條件分析、查詢紀錄。 V8.12 所有錯誤管理和紀錄控制措施的程式碼，都沒有受到惡意程式碼的影響。V9. 資料保護(Date Protection)
保護機敏資料保括信用卡號、護照號碼、個人ID，是本項目的主要要求。Level 3 應滿足
，Level 4 應滿足： V9.1 機敏資料不得存放在客戶端的快取，也不能啟用自動完成功能。 V9.2 敏感資料應建檔管理，並建立明確政策，規定存取限制。 V9.3 敏感資料應存放在 HTTP 訊息的 Body，而非URL。 V9.4 送至 Client 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。 V9.5 存放在 Server 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。 V9.6 當敏感資料的有效取的時間到期之後，應有刪除資料的做法。V10. 通訊安全(Communication Security)
本項目包含，確保應用程式的通訊過程是安全的。Level 3 應滿足
，Level 4 應滿足： V10.1 確保可信任憑證中心(Trusted CA)和 TLS 憑證之間的路徑暢通，且憑證是有效的。 V10.2 失敗的TLS連線，不能還原成未加密的連線。 V10.3 身分驗證或存取敏感資料的功能都應使用 TLS 。 V10.4 TLS 連線失敗應記錄。 V10.5 確認憑證路徑的正確性、確認所有客戶端的憑證都包含可信任的根中心(Trusted Anchor)和到期資訊。 V10.6 與外部系統的連線若包含敏感資料和功能，應先經過驗證。 V10.7 與外部系統的連線若包含敏感資料和功能，應使用最小權限的帳號。 V10.8 應用程式應使用經過驗證的標準 TLS 。 V10.9 所有連線都已規定使用特定的字元集，例如：UTF-8。V11. HTTP 安全(HTTP Security)
本項目包含，所有HTTP相關的安全要求，包括request、response、session、cookies、headers、logging。Level 3 應滿足
，Level 4 應滿足： 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 字元。 V11.7 所有交易與敏感資料處理的連結和表單都應加上有效的亂數權杖( Random Token )，而且應用程式應檢查 Server 端使用者權杖和 Client 端送來 Request 的權杖是否相同。V12. 環境設定(Security Configeration)
本項目包含：應用程式環境中的所有和安全有關的設定檔應存放在安全的位置。保護設定檔資訊對於應用程式的安全是很重要的。Level 3 應滿足
，Level 4 應滿足： V12.1 與安全相關的設定檔，未經授權不能存取。 V12.2 當應用程式無法讀取本身的安全設定檔，應拒絕所有連線。 V12.3 應用程式更動安全設定檔的行為，應記錄在安全事件紀錄檔。 V12.4 所有設定檔能輸出易於稽核、可人工閱讀的格式。V13. 惡意程式碼的搜尋(Malicious Code Search)
本項目包含：確保應用程式中完全不包含惡意程式碼(被掛馬)。Level 3 應滿足
，Level 4 應滿足： V13.1 建立應用程式前，驗證任何惡意程式碼都不存在。 V13.2 利用檢查碼或 Hash 值，驗證程式碼、函式庫、執行檔、設定檔的真確性。V14. 內部安全(Internal Security)
本項目包含：確保應用程式中擁有自我驗證保護，避免內部開發人員的實作缺失或是邏輯炸彈。Level 3 應滿足
，Level 4 應滿足： V14.1 應用程式保護使用者和資料的屬性，且制定存取控制措施的政策，以防止未授權存取或修改。 V14.2 安全控制措施應設計的簡單、正確，讓開發者樂於使用。 V14.3 應用程式應保護共享變數和資源，以防止不當的非同步存取。下次我們將介紹驗證報表的格式。此報表應包含簡介、應用程式描述、應用程式架構、驗證結果等。善用此報表可以了解不同的檢測服務能為你做到甚麼，並進一步減少組織內開發人員和管理者之間的代溝。
參考資料
----
註1：惡意程式碼( Malicious Code )─開發階段時，擁有者未發現的情況下被注入到應用程式中的程式碼，作用是避開應用程式的安全政策，與惡意程式( Malware、Virus、Worm )不同。
註1：惡意程式碼( Malicious Code )─開發階段時，擁有者未發現的情況下被注入到應用程式中的程式碼，作用是避開應用程式的安全政策，與惡意程式( Malware、Virus、Worm )不同。
http://zh.wikipedia.org/zh-tw/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80
http://wiki.mbalib.com/zh-tw/%E4%BC%81%E4%B8%9A%E6%B5%81%E7%A8%8B%E5%9B%BE
https://www.owasp.org/index.php/Fail_securely
http://www.cnblogs.com/ryowu/archive/2010/12/29/1920687.html
http://php.net/manual/en/pdo.prepared-statements.php
http://likewaylai.blogspot.com/2012/02/javasession-cookie-httponly-flag.html
http://likewaylai.blogspot.com/2012/02/javasession-cookie-secure-flag.html
http://amath.colorado.edu/computing/unix/ascii.html
http://en.wikipedia.org/wiki/Threat_model
http://wiki.mbalib.com/zh-tw/%E4%BC%81%E4%B8%9A%E6%B5%81%E7%A8%8B%E5%9B%BE
https://www.owasp.org/index.php/Fail_securely
http://www.cnblogs.com/ryowu/archive/2010/12/29/1920687.html
http://php.net/manual/en/pdo.prepared-statements.php
http://likewaylai.blogspot.com/2012/02/javasession-cookie-httponly-flag.html
http://likewaylai.blogspot.com/2012/02/javasession-cookie-secure-flag.html
http://amath.colorado.edu/computing/unix/ascii.html
http://en.wikipedia.org/wiki/Threat_model
留言
張貼留言