Aaron Guzman	Anthony Weems	Barbara Schachner	Christopher Loessl	Clément Notin
Dan Cornell	Daniël Geerts	David Clarke	David Johansson	David Quisenberry
Erlend Oftedal	Fatih Ersinadim	Filip van Laenen	Geoff Baskwill	Glenn ten Cate
Grant Ongers	hello7s	Jacob Salassi	James Sulinski	Jason Axley
Jason Morrow	Javier Dominguez	Jet Anderson	Jim Newman	Jonathan Schnittger
Joseph Kerby	Kelby Ludwig	Lars Haulin	Lewis Ardern	lyz-code
Marc Aubry	Marco Schnüriger	Philippe De Ryck	Ralph Andalis	Ravi Balla
Rick Mitchell	Riotaro Okada	Robin Wood	Rogan Dawes	Ryan Goltry
Sajjad Pourali	Serg Belkommen	Siim Puustusmaa	Ståle Pettersen	Stuart Gunter
Tal Argoni	Tomasz Wrobel	Vincent De Schutter

應用程序安全驗證標準建立在 2008 年 ASVS 1.0 到 2016 年 3.0 的涉及人員的肩膀上。今天仍然在 ASVS 中的許多結構和驗證項目最初是由邁克·博伯斯基、傑夫·威廉姆斯和戴夫·威奇斯編寫的，以及更多的貢獻者。感謝所有以前參與的人。有關所有爲早期版本做出貢獻的項名的完整列表，請參閱每個早期版本。

前言

歡迎使用應用程序安全驗證標準（ASVS）版本 4.0。ASVS 是一項由社區推動的工作，用於建立安全要求和控制框架，該框架側重於定義設計、開發和測試現代 Web 應用程序和 Web 服務時所需的功能和非功能安全控制。

版本 4.0.2 是 v4.0 的第二個小修補版本，旨在修復拼寫錯誤，以使要求更清晰，而無需做出重大更改（如更改要求或添加/刪除要求）的重大變化。

ASVS v4.0 是過去十年來社區努力和行業反饋的高潮。我們試圖使在任何安全軟件開發生命週期中爲各種不同的用例更容易地採用 ASVS。

我們預計，對於任何 Web 應用程序標準（包括 ASVS）的內容，很可能永遠不會達成 100% 的一致意見。風險分析在某種程度上總是主觀的，這在嘗試以一刀切的標準進行概括時會產生挑戰。但是，我們希望此版本中的最新更新是朝着正確方向邁出的一步，並增強這一關鍵行業標準中引入的概念。

4.0中的新內容

這個版本中最重要的變化是採用了NIST 800-63-3數字身份識別指南，引入了現代的、基於證據的高級認證控制。雖然我們預計在與高級認證標準保持一致方面會遇到一些阻力，但我們認爲標準保持一致是非常必要的，主要是在另一個廣受好評的應用安全標準是基於證據的情況下。

信息安全標準應儘量減少獨特要求的數量，這樣合規組織就不必在競爭或不兼容的控制措施上做決定。OWASP 2017年十大標準以及現在的OWASP應用安全驗證標準現在已經與NIST 800-63在認證和會話管理方面保持一致。我們鼓勵其他標準制定機構與我們、NIST和其他機構合作，以達成一套普遍接受的應用安全控制措施，從而最大限度地提高安全性，並最大限度地降低合規成本。

ASVS 4.0從頭到尾全部重新編號。新的編號方案使我們能夠填補長期消失的章節的空白，並使我們能夠分割較長的章節，以儘量減少開發人員或團隊必須遵守的控制數量。例如，如果一個應用程序沒有使用JWT，那麼關於會話管理中JWT的整個章節就不適用。

4.0中的新功能是對通用弱點列舉（CWE）的全面映射，這是我們在過去十年中最常見的功能要求之一。CWE映射允許工具製造商和那些使用漏洞管理軟件的人將其他工具和以前的ASVS版本的結果與4.0及以後的版本相匹配。爲了給CWE條目騰出空間，我們不得不取消了 "Since"欄，因爲我們完全重新編號了，這一欄的意義不如以前版本的ASVS。並非ASVS中的每個項目都有相關的CWE，由於CWE有大量的重複，我們試圖使用最常用的而不是最接近的匹配。覈查控制並不總是可以映射到相應的弱點。我們歡迎與CWE社區和更廣泛的信息安全領域就縮小這一差距進行持續討論。

我們努力全面滿足並超越解決OWASP Top 10 2017和OWASP主動控制2018的要求。由於OWASP Top 10 2017是避免疏忽的最低要求，我們特意將除特定日誌Top 10要求外的所有要求都定爲1級控制，使OWASP Top 10採用者更容易步入實際安全標準。

我們努力全面滿足並超越解決OWASP Top 10 2017和OWASP主動控制2018的要求。由於OWASP Top 10 2017是避免疏忽的最低要求，我們特意將除特定日誌Top 10要求外的所有要求都定爲1級控制，使OWASP Top 10採用者更容易步入實際安全標準。。

我們已經完成了ASVS從只對服務器端進行單體控制，到爲所有現代應用和API提供安全控制的轉變。在功能編程、無服務器API、移動、雲、容器、CI/CD和DevSecOps、聯盟等時代，我們不能繼續忽視現代應用架構。現代應用的設計與2009年發佈原始ASVS時構建的應用有很大不同。ASVS必須始終着眼於未來，這樣我們才能爲我們的主要受衆--開發人員提供合理的建議。我們已經澄清或刪除了任何假設應用程序是在單一組織擁有的系統上執行的要求。

由於ASVS 4.0的規模，以及我們希望成爲所有其他ASVS工作的基線ASVS，我們已經停用了移動部分，轉而採用移動應用安全驗證標準（MASVS）。物聯網附錄將出現在未來的物聯網ASVS中，由OWASP物聯網項目負責。我們已經在附錄C中包含了物聯網ASVS的早期預覽。我們感謝OWASP移動團隊和OWASP物聯網項目組對ASVS的支持，並期待未來與他們合作，提供互補的標準。

最後，我們刪除了影響較小的控件，並使其退役。隨着時間的推移，ASVS開始成爲一套全面的控制措施，但並非所有的控制措施都能產生安全的軟件。這種消除低影響項目的努力可以更進一步。在ASVS的未來版本中，共同弱點評分系統(CWSS)將有助於進一步確定那些真正重要的控制措施和那些應予淘汰的控制措施的優先次序。

從4.0版本開始，ASVS將只專注於成爲領先的網絡應用和服務標準，涵蓋傳統和現代應用架構，以及敏捷安全實踐和DevSecOps文化

使用 ASVS

ASVS 有兩個主要目標:

幫助組織開發和維護安全的應用程序。
以使安全服務廠商、安全工具廠商和消費者能夠統一其要求和產品。

應用程序安全驗證級別

應用程序安全驗證標準定義了三個安全驗證級別，每個級別的深度都不斷增加.

ASVS 級別 1 用於低保證級別，完全可穿透測試
ASVS 級別 2 適用於包含敏感數據的應用程序，這需要保護，是大多數應用的推薦級別
ASVS 級別 3 適用於最關鍵的應用程序 - 執行高價值事務、包含敏感醫療數據的應用程序或任何需要最高信任級別的應用程序。

每個 ASVS 級別都包含安全要求列表。這些要求中的每一個也可以映射到開發人員必須內置到軟件中的安全特定特性和功能。

圖 1 - OWASP 應用程序安全驗證標準 4.0 級別

第1級是唯一可以使用人類進行完全滲透測試的級別。所有其他級別的測試都需要訪問文檔、源代碼、配置以及參與開發過程的人員。然而，即使L1允許發生 "黑盒"（沒有文檔和源碼）測試，它也不是一種有效的保證活動，應該積極勸阻。惡意攻擊者有大量的時間，大多數滲透測試在幾周內就結束了。防禦者需要建立安全控制，保護、發現和解決所有的弱點，並在合理的時間內檢測和響應惡意行爲者。惡意行爲者的時間基本上是無限的，只需要一個漏洞的防禦、一個弱點或遺漏的檢測就可以成功。黑盒測試往往在開發結束後迅速進行，或者根本不進行測試，完全無法應對這種不對稱性。

在過去的30多年裏，黑盒測試一次又一次地被證明忽略了關鍵的安全問題，直接導致了越來越多的大規模漏洞。我們強烈鼓勵使用廣泛的安全保證和驗證，包括用源代碼主導的（混合）1級滲透測試取代滲透測試，並在整個開發過程中對開發人員和文檔進行全面訪問。金融監管機構不能容忍在無法訪問賬簿、交易樣本或執行控制的人員的情況下進行外部財務審計。行業和政府必須在軟件工程領域要求同樣的透明度標準。

我們強烈鼓勵在開發過程本身使用安全工具。DAST和SAST工具可以被構建流水線持續使用，以輕鬆發現本不該出現的安全問題。

在沒有人工協助的情況下，自動工具和在線掃描無法完成一半以上的ASVS。如果需要對每個構建進行全面的自動化測試，那麼結合自定義單元和集成測試，以及構建發起的在線掃描。業務邏輯缺陷和訪問控制測試只能使用人工輔助。這些應該變成單元和集成測試。

如何使用此標準

使用應用程序安全驗證標準的最佳方法之一是將其作爲藍圖，創建一個特定於您的應用程序、平臺或組織的安全編碼檢查表。根據您的用例對ASVS進行定製，將增加對您的項目和環境最重要的安全要求的關注。

Level 1 – 最低限度

如果一個應用程序能夠充分防禦容易發現的應用程序安全漏洞，幷包括在OWASP前10名和其他類似的檢查清單中，則該應用程序達到了ASVS 1級。1級是所有應用程序應該努力達到的最低限度。它也可以作爲多階段工作的第一步，或者當應用程序不存儲或處理敏感數據，因此不需要2級或3級更嚴格的控制時，它也很有用。1級控制可以通過工具自動檢查，也可以在不訪問源代碼的情況下手動檢查。我們認爲1級是所有應用程序的最低要求。

對應用程序的威脅很可能來自於攻擊者，他們使用簡單和低工作量的技術來識別容易發現和容易利用的漏洞。這與堅定的攻擊者形成鮮明對比，後者會花費集中精力專門針對應用程序。如果你的應用程序所處理的數據具有很高的價值，你很少會想停留在1級審查上。

Level 2 - 大多數應用程序

如果應用程序能夠充分抵禦與當今軟件相關的大多數風險，它就達到 ASVS 級別2（或標準）。

級別 2 可確保安全控制到位、有效並在應用程序中使用。級別 2通常適用於處理重大企業對業務交易的應用程序，包括那些處理醫療保健信息、實現業務關鍵或敏感功能或處理其他敏感資產的應用程序，或完整性是保護其業務的關鍵方面（如遊戲行業）阻止騙子和遊戲黑客的行業。

對 2級應用程序的威脅通常是熟練且有積極性的攻擊者，他們使用工具和技術專注於特定目標，這些工具和技術在發現和利用應用程序中的弱點方面非常有效。

Level 3 - 高價值、高保證或高安全性

ASVS第3級是ASVS內最高級別的核查。這一級別通常保留給需要大量安全覈查的應用程序，如軍事、衛生和安全、關鍵基礎設施等領域的應用程序。

各組織可能會要求執行關鍵功能的應用程序達到ASVS級別3，因爲這些應用程序的失敗可能會嚴重影響組織的業務，甚至影響其生存能力。下文提供了關於ASVS 3級應用的示例指導。如果一個應用程序能夠充分防禦高級應用程序安全漏洞，並展示了良好安全設計的原則，則該應用程序達到了ASVS第3級（或高級）。

達到 ASVS 第 3級的應用程序比所有其他級別的應用程序需要對架構、編碼和測試進行更深入的分析。一個安全的應用程序以有意義的方式模塊化（以促進彈性、可擴展性，最重要的是，安全層），每個模塊（通過網絡連接和/或物理實例分離）都需要照顧自己的安全責任（深度防禦），這些責任需要適當地記錄下來。職責包括確保保密性（如加密）、完整性（如交易、輸入驗證）、可用性（如從容處理負載）、認證（包括系統之間）、不可抵賴性、授權和審計（日誌）的控制。

在實踐中應用 ASVS

不同的威脅有不同的動機。一些行業有獨特的信息和技術資產以及特定領域的監管合規要求。

強烈鼓勵各組織根據其業務性質深入研究其獨特的風險特徵，並根據該風險和業務要求確定適當的ASVS級別

如何參考 ASVS 要求

每個要求都有一個格式的標識符，格式爲 <chapter><節><要求>其中每個元素都是一個數字，例如：1.11.3。

<章節> 值對應於需求來自的章節，例如：所有 1.#.# 要求都來自體系結構章節。
<節> 值對應於該章節中出現需求的部分，例如：所有 1.11.# 要求都位於體系結構章節的"業務邏輯體系結構要求"部分中。
<要求> 值標識章節和部分中的具體要求，例如：1.11.3，自本標準 4.0.2 版本起，該要求爲:

驗證所有高價值業務邏輯流（包括身份驗證、會話管理和訪問控制）是否都是安全的線程，並且能夠抵抗檢查時間和時間競爭條件。

標識符可能會在標準版本之間更改，因此最好使用其他文檔、報表或工具的格式：v<version>-<chapter>.<section>。<requirement>，其中："版本"是 ASVS 版本標記。例如：v4.0.2-1.11.3 被理解爲在版本 4.0.2 的"體系結構"章節的"業務邏輯體系結構要求"部分中具體指的是第 3 個要求。（這可以概括爲 v<version>-<requirement_identifier>。

注意：版本部分前面的 v 是小寫。

如果標識符在未包含 v<version> 元素的情況下使用，則應假定它們引用最新的應用程序安全驗證標準內容。顯然，隨着標準的增長和更改，這將成爲問題，這就是爲什麼編寫者或開發人員應該包括版本元素.

ASVS 要求列表以 CSV、JSON 和其他格式提供，這些格式可能有助於參考或編程使用。

評估和認證

OWASP 對 ASVS 認證和信任標誌的立場

OWASP作爲一個供應商中立的非營利組織，目前不對任何供應商、驗證器或軟件進行認證。

所有這些保證聲明、信任標記或認證都沒有經過OWASP的正式審查、註冊或認證，因此，依賴這種觀點的組織需要謹慎對待對任何聲稱ASVS認證的第三方或信任標記的信任。

這不應該阻止組織提供這種保證服務，只要它們不聲稱OWASP的官方認證。

認證組織指南

應用程序安全驗證標準可用作應用程序的開放帳簿驗證，包括對關鍵資源（如架構師和開發人員、項目文檔、源代碼、對測試系統的身份驗證訪問（包括訪問每個角色中的一個或多個帳戶）的開放和不受限制的訪問，特別是對於 L2 和 L3 驗證。

從歷史上看，滲透測試和安全代碼審查包括"例外"問題，即只有失敗的測試纔出現在最終報告中。認證組織必須在任何報告中包括驗證的範圍（特別是當關鍵組件超出了範圍（如SSO身份驗證）時），驗證結果的摘要（包括通過測試和失敗測試），並明確指示如何解決失敗的測試。

某些驗證要求可能不適用於正在測試的應用程序。例如，如果您向客戶提供無狀態服務層 API，則 V3會話管理中的許多要求並不直接適用。在這種情況下，認證組織仍可要求完全遵守 ASVS，但必須在任何報告中明確說明不適用此類排除的驗證要求的原因。

保留詳細的工作文件、截圖或視頻、可靠和反覆利用某個問題的腳本，以及測試的電子記錄，如截取代理日誌和相關的筆記（如清理清單），被認爲是標準的行業慣例，對於最值得懷疑的開發人員來說，作爲調查結果的證明確實有用。僅僅運行一個工具並報告故障是不夠的，這並不能（完全）提供足夠的證據來證明認證層面的所有問題都經過了徹底的測試和檢驗。在有爭議的情況下，應該有足夠的保證證據來證明每一個被驗證的需求確實已經被測試過。

測試方法

認證組織可以自由選擇適當的測試方法，但應在報告中註明。

根據所測試的應用程序和核查要求，可以使用不同的測試方法來獲得類似的結果。例如，驗證一個應用程序的輸入覈查機制的有效性，可以通過人工滲透測試或通過源代碼分析來進行分析。

自動安全測試工具的作用

鼓勵使用自動滲透測試工具提供儘可能多的覆蓋範圍。

無法僅使用自動滲透測試工具完全完成 ASVS 驗證。雖然 L1 中的大多數要求都可以使用自動測試執行，但總體大多數要求都無法用於自動滲透測試。

請注意，隨着應用安全行業的成熟，自動測試和手動測試之間的界限已經模糊。自動工具通常由專家手動調整，手動測試人員通常利用各種自動化工具。

滲透測試的作用

在4.0版本中，我們決定使L1完全可以進行滲透測試，而無需訪問源代碼、文檔或開發人員。兩個日誌項目，需要符合OWASP Top 10 2017 A10的要求，將需要訪談、截圖或其他證據收集，就像在OWASP Top 10 2017中一樣。然而，在沒有獲得必要信息的情況下進行測試並不是一種理想的安全驗證方法，因爲它錯過了審查源頭、識別威脅和缺失控制的可能性，並在更短的時間內執行更徹底的測試。

在執行 L2 或 L3 評估時，需要儘可能地訪問開發人員、文檔、代碼，並訪問具有非生產數據的測試應用程序。在這些級別進行的滲透測試需要這種級別的訪問權限，我們稱之爲 "混合審查 "或 "混合滲透測試"。

ASVS 的其他用途

除了用於評估應用程序的安全性外，我們還確定了 ASVS 的許多其他潛在用途。

作爲詳細的安全架構指南

應用安全驗證標準比較常見的用途之一是作爲安全架構師的資源。Sherwood應用業務安全架構(SABSA)缺少大量的信息，而這些信息是完成一個徹底的應用安全架構審查所必需的。ASVS可以用來填補這些空白，允許安全架構師針對常見問題選擇更好的控制措施，例如數據保護模式和輸入驗證策略。

作爲現成的安全編碼清單的替代品

許多組織可以通過採用 ASVS、選擇三個級別之一或分叉 ASVS 以及以特定域方式更改每個應用程序風險級別所需的內容而受益。只要保持可追溯性，我們鼓勵這種類型的分叉，這樣，如果應用通過了要求 4.1，這意味着分叉副本與標準副本在不斷髮展時相同。

作爲自動化單元和集成測試指南

ASVS設計爲高度可測試，只有體系結構和惡意代碼要求除外。通過構建單元和集成測試來測試特定且相關的模糊和濫用案例，應用程序幾乎會針對每個生成進行自我驗證。例如，可以爲登錄控制器的測試套件編寫其他測試，測試常見默認用戶名、帳戶枚舉、暴力破解、LDAP 和 SQL 注入以及 XSS的用戶名參數。同樣，對密碼參數的測試應包括通用密碼、密碼長度、空字節注入、刪除參數、XSS等。

用於安全開發培訓

ASVS還可用於定義安全軟件的特性。許多"安全編碼"課程只是道德黑客課程與編碼技巧的輕描淡寫。這不一定幫助開發人員編寫更安全的代碼。相反，安全開發課程可以使用ASVS，重點關注 ASVS 中的主動控制，而不是不做的事情的十大負面內容。

作爲敏捷應用程序安全性的驅動程序

在敏捷開發過程中，ASVS可以作爲一個框架來定義團隊爲獲得安全產品而需要執行的具體任務。一種方法可能是：從第1級開始，根據ASVS對指定級別的要求覈查具體的應用程序或系統，找出缺少的控制措施，並在積壓中提出具體的任務。這有助於特定任務的優先級排序（或梳理），並使敏捷過程中的安全可見。這也可以用來確定組織中審計和審查任務的優先級，特定的ASVS需求可以成爲特定團隊成員審查、重構或審計的驅動力，並作爲最終目標。

作爲指導安全軟件採購的框架

ASVS是一個偉大的框架，可幫助安全軟件採購或自定義開發服務的採購。買方可以簡單地設定一個要求，即他們想要採購的軟件必須在 ASVS 級別 X 開發，並要求賣方證明該軟件滿足 ASVS 級別 X。與 OWASP安全軟件合同附件結合使用時，這效果很好

V1：架構、設計和威脅建模要求

控制目標

安全架構在許多組織中幾乎已經成爲一門失傳的手藝。在DevSecOps時代，企業架構師的時代已經過去。應用安全領域必須迎頭趕上，採用敏捷安全原則，同時將領先的安全架構原則重新介紹給軟件從業者。架構不是一種實現，而是一種思考問題的方式，它有可能有很多不同的答案，沒有一個單一的"正確"答案。很多時候，安全問題被認爲是不靈活的，要求開發人員以特定的方式修復代碼，而開發人員可能知道更好的解決問題的方法。對於架構來說，沒有單一的、簡單的解決方案，假裝不這樣做是對軟件工程領域的一種傷害。

一個網絡應用的具體實現很可能在整個生命週期中不斷地被修改，但整體架構可能很少改變，而是緩慢地發展。安全架構是相同的--今天我們需要認證，明天我們需要認證，五年後我們也需要認證。如果我們今天做出正確的決定，如果我們選擇和重複使用符合架構的解決方案，我們可以節省大量的精力、時間和金錢。例如，十年前，多因素身份驗證很少被實施。

如果開發人員選擇了單一的安全身份提供商模式，如SAML聯合身份，那麼身份提供商可以進行更新，以納入新的要求，如NIST 800-63的合規性，同時不改變原有應用的接口。如果許多應用程序共享相同的安全架構，從而共享該相同的組件，那麼它們都可以一次從這種升級中受益。然而，SAML不會一直作爲最佳或最合適的認證解決方案--隨着需求的變化，它可能需要換成其他解決方案。這樣的改變要麼很複雜，成本太高，以至於需要徹底重寫，要麼在沒有安全架構的情況下完全不可能。

在本章中，ASVS涵蓋了任何健全安全架構的主要方面：可用性、保密性、處理完整性、不可抵賴性和隱私性。這些安全原則中的每一項都必須內置在所有應用程序中，並且是與生俱來的。至關重要的是 "向左移動"，從開發人員啓用安全編碼檢查清單、指導和培訓、編碼和測試、構建、部署、配置和操作開始，到後續的獨立測試結束，以確保所有的安全控制都存在併發揮作用。最後一步曾經是我們作爲一個行業所做的一切，但當開發人員每天將代碼推送到生產中幾十次或幾百次時，這已經不夠了。應用安全專業人員必須跟上敏捷技術的步伐，這意味着採用開發人員工具，學習代碼，與開發人員一起工作，而不是在其他人都離開幾個月後批評項目（鞭屍）。

V1.1 安全軟件開發生命週期要求 #	描述	L2	L3	CWE
1.1.1	驗證安全軟件開發生命週期的使用，該生命週期解決了所有開發階段的安全性問題	✓	✓
1.1.2	驗證每個設計更改或規劃使用威脅建模，以識別威脅、規劃對策、促進適當的風險響應並指導安全測試。	✓	✓	1053
1.1.3	驗證所有用戶情景和功能是否都包含功能性安全約束，例如"作爲用戶，我應該能夠查看和編輯我的個人資料。我不應查看或編輯其他人的個人資料"	✓	✓	1110
1.1.4	驗證應用程序的所有信任邊界、組件和重要數據流的文檔以及原由。	✓	✓	1059
1.1.5	驗證應用程序高級體系結構和所有連接的遠程服務的定義和安全分析。	✓	✓	1059
1.1.6	驗證集中、簡單（設計經濟）、經過審查、安全和可重用的安全控制的實施，以避免重複、缺失、無效或不安全的控制。	✓	✓	637
1.1.7	驗證所有開發人員和測試人員的安全編碼清單、安全要求、指南或策略的可用性。	✓	✓	637

V1.2 身份驗證體系結構要求

在設計身份驗證時，如果攻擊者可以通過調用呼叫中心並回答常見問題來重置帳戶，則是否具有啓用強硬件的多重身份驗證並不重要。校對身份時，所有認證路徑必須具有相同的強度。

#	描述	L2	L3	CWE
1.2.1	驗證所有應用程序組件、服務和服務器的唯一或特殊低特權操作系統帳戶的使用。	✓	✓	250
1.2.2	驗證應用程序組件（包括 API、中間件和數據層）之間的通信是否經過身份驗證。組件應具有所需的最低限度的特權。	✓	✓	306
1.2.3	驗證應用程序是否使用已知安全的單個經過審查的身份驗證機制，可以擴展爲包括強身份驗證，並有足夠的日誌記錄和監視來檢測帳戶濫用或違規。	✓	✓	306
1.2.4	驗證所有身份驗證路徑和身份管理 API 都實現一致的身份驗證安全控制強度。	✓	✓	306

V1.3 會話管理體系結構要求

這是未來體系結構要求的佔位符。

V1.4 訪問控制架構要求 #	描述	L2	L3	CWE
1.4.1	驗證訪問控制網關、服務器和無服務器功能等受信任的執行點是否實施了訪問控制。切勿在客戶端實施訪問控制。	✓	✓	602
1.4.2	驗證所選的訪問控制解決方案是否足夠靈活，足以滿足應用程序的需求。	✓	✓	284
1.4.3	覈查函數、數據文件、URL、控制器、服務和其他資源中的最低特權原則的執行情況。這意味着防止欺騙和提高特權。	✓	✓	272
1.4.4	驗證應用程序使用單一且經過良好審查的訪問控制機制來訪問受保護的數據和資源。所有請求必須通過此單一機制，以避免複製和粘貼或不安全的替代路徑。	✓	✓	284
1.4.5	驗證是否使用了屬性或基於功能的訪問控制，代碼檢查用戶對功能/數據項的授權，而不僅僅是他們的角色。	✓	✓	275

V1.5 輸入和輸出架構要求

在 4.0 中，我們已將"服務器端"一詞作爲加載的信任邊界術語。信任邊界仍然令人擔心 - 在不受信任的瀏覽器或客戶端設備上做出決策是可繞過的。但是，在當今的主流體系結構部署中，信任強制點發生了巨大變化。因此，在 ASVS 中使用術語"受信任服務層"時，我們指的是任何受信任的實施點，無論位置如何，例如微服務、無服務器 API、服務器端、具有安全引導、合作伙伴或外部 API 的客戶端設備上的受信任 API 等。

此處的"不受信任的客戶端"術語是指呈現表示層的客戶端技術，通常稱爲"前端"技術。此處的術語"序列化"不僅指像值數組一樣通過線發送數據，或者接收和讀取 JSON 結構，還指傳遞可以包含邏輯的複雜對象

#	描述	L2	L3	CWE
1.5.1	驗證輸入和輸出要求是否清楚地定義如何根據類型、內容和適用的法律、法規和其他策略合規性處理和處理數據。	✓	✓	1029
1.5.2	在與不受信任的客戶機通信時，驗證是否沒有使用序列化。如果無法做到這一點，確保實施適當的完整性控制（如果發送敏感數據，則可能進行加密），以防止反序列化攻擊，包括對象注入。	✓	✓	502
1.5.3	驗證輸入驗證是否在受信任的服務層上強制實施。	✓	✓	602
1.5.4	驗證輸出編碼是否發生在預期要執行的解釋器附近或由解釋器進行。	✓	✓	116

V1.6 加密體系結構要求

應用程序需要使用強大的加密體系結構進行設計，以根據其分類保護數據資產。加密一切是浪費，不加密任何東西在法律上都是疏忽大意。必須取得平衡，通常在體系結構或高級設計、趕進度設計或體系結構峯值期間。在進行加密或改造時設計密碼，安全實施成本必然比從一開始構建成本高得多。

體系結構要求是整個代碼庫固有的，因此很難單元或集成測試。在整個編碼階段，在編碼標準中需要考慮體系結構要求，並且應在安全體系結構、同行或代碼評審或回顧期間進行審查。

#	描述	L2	L3	CWE
1.6.1	驗證是否有用於管理加密密鑰的明確策略，並且加密密鑰生命週期是否遵循密鑰管理標準（如 NIST SP 800-57）。	✓	✓	320
1.6.2	驗證加密服務的使用者是否使用密鑰保管庫或基於 API的替代方案來保護密鑰材料和其他機密。	✓	✓	320
1.6.3	驗證所有密鑰和密碼是否可替換，並且是重新加密敏感數據定義良好的過程的一部分。	✓	✓	320
1.6.4	驗證體系結構是否將客戶端機密（如對稱密鑰、密碼或 API令牌）視爲不安全，並且從不使用它們來保護或訪問敏感數據.	✓	✓	320

V1.7 錯誤、日誌記錄和審覈體系結構要求

#	描述	L1	L2	L3	CWE
1.7.1	驗證系統中是否使用了通用日誌記錄格式和方法。		✓	✓	1009
1.7.2	驗證日誌是否安全地傳輸到優選的遠程系統，以便進行分析、檢測、警報和上報。		✓	✓

V1.8 數據保護和隱私體系結構要求

#	描述	L1	L2	L3	CWE
1.8.1	驗證所有敏感數據是否已識別並分爲保護級別。		✓	✓
1.8.2	驗證所有保護級別是否都有一組關聯的保護要求，例如加密要求、完整性要求、保留、隱私和其他機密性要求，以及這些要求是否應用於體系結構中。		✓	✓

V1.9 通信體系結構要求

#	描述	L1	L2	L3	CWE
1.9.1	驗證應用程序加密組件之間的通信，特別是當這些組件在不同的容器、系統、站點或雲提供商中時。		✓	✓	319
1.9.2	驗證應用程序組件是否驗證通信鏈路中每一方的真實性，以防止中間人攻擊。例如，應用程序組件應驗證<br/>TLS 證書和鏈。		✓	✓	295

V1.10 惡意軟件體系結構要求

#	描述	L1	L2	L3	CWE
1.10.1	覈實是否使用了源代碼控制系統，並有程序確保簽到時附有問題或變更單。源碼控制系統應具有訪問控制和可識別的用戶，以便對任何更改進行跟蹤。		✓	✓	284

V1.11 業務邏輯架構要求

#	描述	L2	L3	CWE
1.11.1	根據所有應用程序組件提供的業務或安全功能，驗證它們的定義和文檔。	✓	✓	1059
1.11.2	驗證所有高價值業務邏輯流（包括身份驗證、會話管理和訪問控制）不共享不同步狀態。	✓	✓	362
1.11.3	驗證所有高價值業務邏輯流（包括身份驗證、會話管理和訪問控制）是否都是安全的線程，並且能夠抵抗檢查時間和時間競爭條件。		✓	367

V1.12 安全文件上傳體系結構要求

#	描述	L1	L2	L3	CWE
1.12.1	驗證用戶上傳的文件是否存儲在 Web 根目錄之外。		✓	✓	552
1.12.2	驗證用戶上傳的文件（如果需要從應用程序顯示或下載）是否由八位組流下載或從不相關的域（如雲文件存儲桶）提供。實施合適的內容安全策略（CSP）以降低來自 XSS 矢量或上載文件的其他攻擊的風險。		✓	✓	646

V1.13 API 架構要求

這是未來體系結構要求的佔位符。 V1.14 配置架構要求 #	描述	L2	L3	CWE
1.14.1	通過定義良好的安全控制、防火牆規則、API 網關、反向代理、基於雲的安全組或類似機制，驗證不同信任級別的組件的隔離。	✓	✓	923
1.14.2	驗證二進制簽名、受信任連接和經過驗證的終結點是否用於將二進制文件部署到遠程設備。	✓	✓	494
1.14.3	驗證構建流水線是否警告過期或不安全的組件，並採取適當的操作。	✓	✓	1104
1.14.4	驗證構建流水線是否包含自動生成和驗證應用程序的安全部署的生成步驟，尤其是在應用程序基礎結構是軟件定義的（如雲環境生成腳本）時。	✓	✓
1.14.5	驗證應用程序部署是否足夠沙盒、容器化和/或隔離在網絡級別，以延遲和阻止攻擊者攻擊其他應用程序，尤其是當他們執行敏感或危險的操作（如反序列化）時。	✓	✓	265
1.14.6	驗證應用程序不使用不受支持、不安全或棄用的客戶端技術，如 NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.	✓	✓	477

參考文獻

有關詳細信息，請參閱:

V2：身份驗證驗證要求

控制目標

身份驗證是指確定或確認某人（或某物）是真實的，並且某人或某設備所做的主張是正確的，能夠抵禦冒充，防止密碼被恢復或攔截的行爲。

ASVS剛發佈時，用戶名+密碼是高安全系統之外最常見的認證方式。多因素認證(MFA)在安全圈內被普遍接受，但在其他地方很少被要求。隨着密碼泄露事件的增多，認爲用戶名在某種程度上是保密的，而密碼則是未知的，這種想法使得許多安全控制措施無法成立。例如，NIST 800-63認爲用戶名和基於知識的身份驗證（KBA）是公共信息，短信和電子郵件通知是 "受限 "的身份驗證器類型，而密碼是預先破解的。這種現實使得基於知識的身份驗證器、短信和電子郵件恢復、密碼歷史、複雜性和輪換控制毫無用處。這些控制總是不那麼有用，經常迫使用戶每隔幾個月就拿出弱密碼，但隨着超過50億次用戶名和密碼泄露事件的發佈，是時候繼續前進了。

在ASVS的所有章節中，身份驗證和會話管理章節變化最大。採用有效的、基於證據的領先實踐對許多人來說將是一個挑戰，這完全沒有問題。我們現在就必須開始向後密碼的未來過渡。

NIST 800-63 - 現代的循證認證標準

NIST 800-63b 是一種現代的循證標準，代表最好的建議，無論適用性如何。該標準對全世界所有組織都很有幫助，但尤其適用於美國機構和與美機構打交道的組織。

NIST 800-63 術語一開始可能會有點混亂，尤其是如果您只使用用戶名 + 密碼身份驗證。現代身份驗證的進步是必要的，因此我們必須引入將來將變得司空見慣的術語，但我們確實理解在行業確定這些新術語之前理解的困難。我們在本章末尾提供了一個詞彙表來提供幫助。我們重新表述了許多要求，以滿足要求的意圖，而不是要求的字母。例如，當 NIST 在整個本標準中使用"記住的祕密"時，ASVS 使用術語"密碼"。

ASVS V2 身份驗證、V3 會話管理以及較小程度上，V4 訪問控制已調整爲所選 NIST 800-63b 控件的合規子集，側重於常見威脅和通常利用的身份驗證弱點。如果需要完全 NIST 800-63 合規性，請查看 NIST 800-63。

選擇適當的 NIST AAL 級別

應用程序安全驗證標準已嘗試將 ASVS L1 映射到 NIST AAL1 要求，L2 映射到 AAL2，將 L3 映射到 AAL3。但是，ASVS 級別 1 作爲"基本"控件的方法不一定是驗證應用程序或 API 的正確 AAL 級別。例如，如果應用程序是 3 級應用程序或具有 AAL3 的法規要求，則應在 V2 節和 V3 會話管理中選擇級別 3。選擇符合 NIST 的身份驗證斷言級別（AAL）應根據 NIST 800-63b 準則執行，如 NIST 800-63b Section6.2. 第 6.2 節中選擇AAL 中所述

V2.1 密碼安全要求

密碼，稱爲"記憶的祕密"由NIST 800-63，包括密碼，PIN，解鎖模式，選擇正確的小貓或其他圖像元素，和密碼。它們通常被認爲是"您知道的東西"，並經常用作單因素驗證器。繼續使用單因素身份驗證面臨重大挑戰，包括Internet上披露的數十億有效用戶名和密碼、默認或弱密碼、彩虹表和最常見的密碼的有序字典。

應用程序應強烈鼓勵用戶註冊多重身份驗證，並且應允許用戶重新使用已擁有令牌（如 FIDO 或 U2F 令牌）或鏈接到提供多重身份驗證的憑據服務提供商。

憑據服務提供商（CSP）爲用戶提供聯合標識。用戶通常具有多個具有多個 CSP的標識，例如使用 Azure AD、Okta、Ping 標識或 Google 的企業標識，或使用Facebook、Twitter、Google或微信的用戶標識來命名幾個常見替代方法。此列表不是對這些公司或服務的認可，而只是鼓勵開發人員考慮許多用戶具有許多已確立的身份的現實。組織應考慮根據CSP的身份證明強度的風險簡介與現有用戶身份集成。例如，政府機構不太可能接受社交媒體標識作爲敏感系統的登錄，因爲創建虛假身份或扔掉身份很容易，而移動遊戲公司很可能需要與主要社交媒體平臺集成，以擴大其活躍玩家基礎。

#	描述	L1	L2	L3	CWE	NIST §
2.1.1	驗證用戶設置的密碼長度至少爲 12 個字符（在合併多個空格後）。	✓	✓	✓	521	5.1.1.2
2.1.2	驗證密碼允許 64 個字符或更長時間，但可能不超過 128 個字符。	✓	✓	✓	521	5.1.1.2
2.1.3	驗證未執行密碼截斷。但是，連續的多個空格可以替換爲單個空格。	✓	✓	✓	521	5.1.1.2
2.1.4	驗證密碼中是否允許任何可打印的 Unicode 字符，包括語言中性字符（如空格和表情符號）。	✓	✓	✓	521	5.1.1.2
2.1.5	驗證用戶可以更改其密碼。	✓	✓	✓	620	5.1.1.2
2.1.6	驗證密碼更改功能是否需要用戶的當前密碼和新密碼。	✓	✓	✓	620	5.1.1.2
2.1.7	驗證在帳戶註冊、登錄和密碼更改期間提交的密碼是否針對一組違反密碼（例如與系統密碼策略匹配的前 1，000 或 10，000 個最常用密碼）或使用外部 API 進行檢查。如果使用 API，應使用零知識證明或其他機制來確保不發送或使用純文本密碼來驗證密碼的泄露狀態。如果密碼被違反，應用程序必須要求用戶設置新的未違反密碼。	✓	✓	✓	521	5.1.1.2
2.1.8	驗證是否提供了密碼強度規則來幫助用戶設置更強的密碼。	✓	✓	✓	521	5.1.1.2
2.1.9	驗證沒有限制允許的字符類型的密碼組合規則。不應對大寫或小寫或數字或特殊字符是必需的。	✓	✓	✓	521	5.1.1.2
2.1.10	驗證沒有定期憑據輪換或密碼歷史記錄要求。	✓	✓	✓	263	5.1.1.2
2.1.11	驗證是否允許"粘貼"功能、瀏覽器密碼幫助程序以及外部密碼管理器。	✓	✓	✓	521	5.1.1.2
2.1.12	驗證用戶可以選擇暫時查看整個掩蔽密碼，或暫時查看沒有內置功能的平臺上密碼的最後一個鍵入字符。	✓	✓	✓	521	5.1.1.2

注意: 允許用戶查看其密碼或暫時查看最後一個字符的目標是提高憑據輸入的可用性，特別是圍繞使用較長的密碼、密碼短語和密碼管理器。包括此要求的另一個原因是阻止或防止測試報告不必要地要求組織重寫內置平臺密碼字段行爲，以刪除這種現代用戶友好的安全體驗。

V2.2 一般身份驗證器要求

身份驗證器敏捷性對於面向未來的應用程序至關重要。重構應用程序驗證器，允許根據用戶首選項設置其他身份驗證器，並允許有條不紊地停用棄用或不安全的身份驗證器。

NIST 認爲電子郵件和 SMS 是"受限"的身份驗證器類型，它們可能會從 NIST 800-63 中刪除，因此 ASVS將來會在某個時候被刪除。應用程序應規劃不需要使用電子郵件或短信的路線圖。

#	描述	L1	L2	L3	CWE	NIST §
2.2.1	驗證反自動化控制是否有效可緩解違反的憑據測試、暴力攻擊和帳戶鎖定攻擊。此類控制包括阻止最常見的密碼、軟鎖定、速率限制、CAPTCHA、嘗試之間的不斷增加延遲、IP 地址限制或基於風險的限制，如位置、首次登錄設備、最近解鎖帳戶的嘗試或類似。驗證單個帳戶每小時失敗次數不超過 100 次。	✓	✓	✓	307	5.2.2 / 5.1.1.2 / 5.1.4.2 / 5.1.5.2
2.2.2	驗證弱身份驗證器（如 SMS 和電子郵件）的使用是否僅限於輔助驗證和事務審批，而不是替代更安全的身份驗證方法。驗證在弱方法之前是否提供了更強大的方法，用戶是否意識到了風險，或者是否採取了適當的措施來限制帳戶泄露的風險。	✓	✓	✓	304	5.2.10
2.2.3	驗證在更新身份驗證詳細信息（如憑據重置、電子郵件或地址更改、從未知或危險位置登錄）後是否向用戶發送安全通知。首選使用推送通知（而不是短信或電子郵件），但在沒有推送通知的情況下，只要通知中未披露敏感信息，短信或電子郵件是可以接受的。	✓	✓	✓	620
2.2.4	驗證抗冒充性，防止網絡釣魚，如使用多因素認證、帶有意圖的加密設備（如帶有推送認證的連接密鑰），或在更高的AAL級別，使用客戶端證書。			✓	308	5.2.5
2.2.5	驗證證書服務提供商（CSP）和驗證身份驗證的應用程序是否分開，兩個終結點之間是否具有相互身份驗證的 TLS。			✓	319	5.2.6
2.2.6	通過強制使用一次密碼（OTP）設備、加密身份驗證器或查找代碼來驗證重播阻力。			✓	308	5.2.8
2.2.7	通過要求輸入 OTP 令牌或用戶啓動的操作（如在 FIDO 硬件密鑰上按下按鈕）驗證身份驗證意圖。			✓	308	5.2.9

V2.3 身份驗證器生命週期要求

身份驗證器是密碼、軟令牌、硬件令牌和生物識別設備。身份驗證器的生命週期對應用程序的安全性至關重要。如果有人可以在沒有身份證據的帳戶自行註冊帳戶，則對標識斷言的信任就很少了。對於像Reddit 這樣的社交媒體網站，這完全沒問題。對於銀行系統來說，更加註重憑據和設備的註冊和頒發對於應用程序的安全性至關重要。

注意：密碼不得有最長使用期限，不得進行密碼輪換。密碼應檢查是否被破解，而不是定期更換。

#	描述	L1	L2	L3	CWE	NIST §
2.3.1	驗證系統生成的初始密碼或激活代碼應安全地隨機生成，應至少 6 個字符長，並且可能包含字母和數字，並在短時間內過期。不得允許這些初始機密成爲長期密碼。	✓	✓	✓	330	5.1.1.2 / A.3
2.3.2	驗證是否支持註冊和使用訂閱者提供的身份驗證設備，如 U2F 或 FIDO 令牌。		✓	✓	308	6.1.3
2.3.3	驗證續訂說明是否發送時間足夠，以續訂有時限的身份驗證器。		✓	✓	287	6.1.4

V2.4 憑據存儲要求

架構師和開發人員在構建或重構代碼時應遵守此部分。本節只能通過源代碼審查或通過安全單元或集成測試進行完全驗證。滲透測試無法識別這些問題中的任何一個。

NIST 800-63 B 節 5.1.1.2 和BSI Kryptgraphische Verfahren： Empfehlungen 和 Schlussellngen （2018）中詳細介紹了批准的雙向鍵派生函數列表。可以選擇最新的國家或區域算法和密鑰長度標準，以代替這些選擇.

此部分無法進行滲透測試，因此控件不會標記爲L1。但是，如果憑據被盜，此部分對憑據的安全性至關重要，因此，如果爲體系結構或編碼準則或源代碼審查清單編寫ASVS，請將這些控件放回您的私有版本中的 L1。

#	描述	L2	L3	CWE	NIST §
2.4.1	驗證密碼是否以抗脫機攻擊的形式存儲。應使用經批准的單向密鑰派生或密碼哈希函數對密碼進行salt和哈希處理。密鑰派生和密碼哈希函數在生成密碼哈希時將密碼、salt和成本系數作爲輸入。	✓	✓	916	5.1.1.2
2.4.2	驗證salt的長度至少爲 32 位，並任意選擇以最大限度地減少存儲哈希之間的salt值衝突。對於每個憑據，應存儲唯一的salt值和生成的哈希。	✓	✓	916	5.1.1.2
2.4.3	驗證如果使用 PBKDF2，迭代計數應與驗證服務器性能允許的一樣大，通常至少 100，000 次迭代。	✓	✓	916	5.1.1.2
2.4.4	驗證是否使用 bcrypt，工作因子應與驗證服務器性能允許的一樣大，通常至少爲 13。	✓	✓	916	5.1.1.2
2.4.5	驗證是否使用機密且僅對驗證者已知的 salt 值執行密鑰派生函數的附加迭代。使用經批准的隨機位生成器 [SP 800-90Ar1] 生成salt值，並提供 SP 800-131A 最新修訂版中指定的最小安全強度。祕密salt值應與哈希密碼分開存儲（例如，在硬件安全模塊等專用設備中）。	✓	✓	916	5.1.1.2

如果提到美國標準，可以根據要求使用區域或當地標準來代替或補充美國標準。

V2.5 憑據恢復要求 #	描述	L1	L2	L3	CWE	NIST §
2.5.1	驗證系統生成的初始激活或恢復密鑰未以明文發送給用戶。	✓	✓	✓	640	5.1.1.2
2.5.2	驗證不存在密碼提示或基於知識的身份驗證（所謂的"機密問題"）。	✓	✓	✓	640	5.1.1.2
2.5.3	驗證密碼憑據恢復不會以任何方式顯示當前密碼。	✓	✓	✓	640	5.1.1.2
2.5.4	驗證共享或默認帳戶不存在 (e.g. "root", "admin", or "sa").	✓	✓	✓	16	5.1.1.2 / A.3
2.5.5	驗證是否更改或替換了身份驗證因子，是否通知用戶此事件。	✓	✓	✓	304	6.1.2.3
2.5.6	驗證忘記的密碼和其他恢復路徑使用安全恢復機制，例如基於時間的 OTP （TOTP）或其他軟令牌、移動推送或其他脫機恢復機制。	✓	✓	✓	640	5.1.1.2
2.5.7	覈實如果OTP或多因素認證因子丟失，身份證明的證據是否與註冊時相同。		✓	✓	308	6.1.2.3

V2.6 查找祕密驗證人要求

查找祕密是預先生成的祕密代碼列表，類似於交易授權號（TAN）、社交媒體恢復代碼或包含一組隨機值的網格。這些被安全地分發到用戶手中。這些查找碼只使用一次，一旦全部使用完畢，查找祕密列表就會被丟棄。這種類型的驗證器被認爲是 "你使用過的東西"。

#	描述	L2	L3	CWE	NIST §
2.6.1	驗證查機密只能使用一次	✓	✓	308	5.1.2.2
2.6.2	驗證查找機密是否具有足夠的隨機性（112位），如果小於112位，則用唯一的隨機32位進行salt，並用批准的單向哈希進行哈希	✓	✓	330	5.1.2.2
2.6.3	驗證查找機密是否可抵抗脫機攻擊，如可預測值.	✓	✓	310	5.1.2.2

V2.7 帶外驗證器要求

過去，帶外驗證器的常見是包含密碼重置鏈接的電子郵件或短信。攻擊者使用此弱機制重置他們尚無法控制的帳戶，例如接管此人的電子郵件帳戶以及重新使用任何發現的重置鏈接。有更好的方法來處理帶外驗證。

帶外安全身份驗證器是可以通過安全的輔助通道與驗證器通信的物理設備。示例包括向移動設備推送通知。這種類型的驗證器被視爲"您擁有的東西"。當用戶希望進行身份驗證時，驗證應用程序通過第三方服務直接或間接連接到驗證器，向帶外驗證器發送消息。該消息包含身份驗證代碼（通常是隨機的六位數字或模式審批對話框）。驗證應用程序等待通過主通道接收身份驗證代碼，並將接收值的哈希值與原始身份驗證代碼的哈希值進行比較。如果它們匹配，則帶外驗證器可以假定用戶已過身份驗證。

ASVS 假定只有少數開發人員將開發新的帶外身份驗證器（如推送通知），因此以下 ASVS 控件適用於驗證器，如身份驗證API、應用程序和單點登錄實現。如果開發新的帶外驗證器，請參閱 NIST 800-63B § 5.1.3.1.

不允許不安全的帶外身份驗證器（如電子郵件和 VOIP）。PSTN 和 SMS 身份驗證目前受NIST 的"限制"，應棄用推送通知或類似通知。

#	描述	L1	L2	L3	CWE	NIST §
2.7.1	驗證默認情況下是否未提供帶外（NIST"受限"）的明文驗證器（如 SMS 或 PSTN），並且首先提供更強大的替代方法（如推送通知）。	✓	✓	✓	287	5.1.3.2
2.7.2	驗證帶外驗證器在 10 分鐘後是否過期帶身份驗證請求、代碼或令牌。	✓	✓	✓	287	5.1.3.2
2.7.3	驗證帶外驗證器身份驗證請求、代碼或令牌是否僅對原始身份驗證請求可用一次，且僅對原始身份驗證請求可用。	✓	✓	✓	287	5.1.3.2
2.7.4	驗證帶外驗證器和驗證器是否通過安全的獨立通道進行通信。	✓	✓	✓	523	5.1.3.2
2.7.5	驗證帶外驗證器是否僅保留身份驗證代碼的哈希版本。		✓	✓	256	5.1.3.2
2.7.6	驗證初始身份驗證代碼是否由包含至少 20 位的安全隨機數生成器生成（通常爲 6 個數字隨機數就足夠了）。		✓	✓	310	5.1.3.2

V2.8 單因素或多因素一次驗證器要求

單因素一次密碼（OTP）是物理或軟令牌，顯示不斷變化的僞隨機一次質詢。這些設備使網絡釣魚（模擬）變得困難，但不是不可能。這種類型的驗證器被視爲"您擁有的東西"。多因素令牌類似於單因素OTP，但需要有效的 PIN 碼、生物識別解鎖、USB 插入或 NFC 配對或一些附加值（如交易簽名計算器）才能輸入以創建最終 OTP。

#	描述	L1	L2	L3	CWE	NIST §
2.8.1	驗證基於時間的 OTP 在到期前是否具有定義的生存期。	✓	✓	✓	613	5.1.4.2 / 5.1.5.2
2.8.2	驗證用於驗證提交的 OTP 的對稱密鑰是否受到高度保護，例如使用硬件安全模塊或基於操作系統的安全密鑰存儲。		✓	✓	320	5.1.4.2 / 5.1.5.2
2.8.3	驗證在 OTP 的生成、種子設定和驗證中是否使用了經批准的加密算法。		✓	✓	326	5.1.4.2 / 5.1.5.2
2.8.4	驗證基於時間的 OTP 在有效期內只能使用一次。		✓	✓	287	5.1.4.2 / 5.1.5.2
2.8.5	驗證如果在有效期內重新使用基於時間的多因素 OTP 令牌，則記錄並拒絕該令牌，併發送安全通知到設備的持有者。		✓	✓	287	5.1.5.2
2.8.6	驗證物理單因素 OTP 生成器在發生盜竊或其他損失時可被撤銷。確保無論位於什麼位置，在已登錄會話中立即執行吊銷。		✓	✓	613	5.2.1
2.8.7	驗證生物識別身份驗證器是否僅限於作爲次要因素，結合您擁有的東西和您知道的東西。		o	✓	308	5.2.3

V2.9 加密軟件和設備驗證程序要求

加密安全密鑰是智能卡或 FIDO密鑰，用戶必須插入加密設備或將加密設備配對到計算機才能完成身份驗證。驗證程序向加密設備或軟件發送質詢 nonce，並且設備或軟件根據安全存儲的加密密鑰計算響應。

單因素加密設備和軟件以及多因素加密設備和軟件的要求是相同的，因爲對加密驗證器的驗證證明了對身份驗證因素的佔有。

#	描述	L2	L3	CWE	NIST §
2.9.1	驗證中使用的加密密鑰是否安全存儲並受到保護，防止泄露，例如使用受信任的平臺模塊（TPM）或硬件安全模塊（HSM）或可使用此安全存儲的 OS 服務。	✓	✓	320	5.1.7.2
2.9.2	驗證質詢 nonce 的長度至少爲 64 位，並且在加密設備的生命週期內具有統計上唯一或唯一。	✓	✓	330	5.1.7.2
2.9.3	驗證在生成、種子設定和驗證中使用了已批准的加密算法。	✓	✓	327	5.1.7.2

V2.10 服務身份驗證要求

此部分不可穿透測試，因此沒有任何 L1要求。但是，如果在體系結構、編碼或安全代碼評審中使用，請假定軟件（就像 Java 密鑰存儲一樣）是 L1 的最低要求。在任何情況下都不能接受明文存儲機密。

#	描述	L2	L3	CWE	NIST §
2.10.1	驗證服務內機密不依賴於不變的憑據，如密碼、API 密鑰或具有特權訪問權限的共享帳戶。	OS assisted	HSM	287	5.1.1.1
2.10.2	驗證服務身份驗證是否需要密碼，且使用的服務帳戶不是默認憑據。 (e.g. root/root or admin/admin 某些服務在安裝過程中爲默認值).	OS assisted	HSM	255	5.1.1.1
2.10.3	驗證密碼是否具有足夠的保護，以防止脫機恢復攻擊，包括本地系統訪問。	OS assisted	HSM	522	5.1.1.1
2.10.4	驗證密碼、與數據庫和第三方系統的集成、種子和內部機密以及 API 密鑰都得到安全管理，不包括在源代碼中或存儲在源代碼存儲庫中。此類存儲應抵禦脫機攻擊。建議使用安全軟件密鑰存儲（L1）、硬件 TPM 或 HSM （L3）進行密碼存儲。	OS assisted	HSM	798
術語表術語	意義
CSP	憑據服務提供商也稱爲標識提供程序
Authenticator	對密碼、令牌、MFA、聯合斷言等進行身份驗證的代碼。
Verifier	覈實用戶身份的實體，利用認證協議覈實用戶身分擁有和控制一個或兩個認證器。爲此，覈查者可能還需要驗證將驗證器與用戶身份識別器聯繫起來的憑證，並檢查其狀態。
OTP	一次性密碼
SFA	單因素身份驗證器，例如您知道的東西（記住的祕密、密碼、密碼、PIN）、您擁有的東西（生物識別、指紋、面部掃描）或您擁有的東西（OTP 令牌、加密設備（如智能卡））、
MFA	多重身份驗證，包括兩個或多個單個因素

參考文獻

有關詳細信息，請參閱：

V3: 會話管理驗證要求

控制目標

任何基於 Web 的應用程序或有狀態 API的核心組件之一是它控制和維護用戶或設備與它交互的狀態的機制。會話管理將無狀態協議更改爲"有狀態"，這對於區分不同的用戶或設備至關重要。

確保經過驗證的應用程序滿足以下高級會話管理要求：

會話對每個人是唯一的，無法猜測或共享。
當不再需要會話時，會話將失效，並在不活動期間超時。

如前所述，這些要求已作了調整，以符合選定的NIST 800-63b控制措施的子集，重點是常見的威脅和常被利用的認證弱點。以前的核查要求已被淘汰、取消，或在大多數情況下進行了調整，以便與NIST 800-63b強制性要求的意圖緊密結合。

安全驗證要求

V3.1 基本會話管理要求 #	描述	L1	L2	L3	CWE	NIST §
3.1.1	驗證應用程序從不在 URL 參數中顯示會話令牌。	✓	✓	✓	598
V3.2 會話綁定要求 #	描述	L1	L2	L3	CWE	NIST §
3.2.1	驗證應用程序在用戶身份驗證時生成新的會話令牌。	✓	✓	✓	384	7.1
3.2.2	驗證會話令牌是否至少具有 64 位。	✓	✓	✓	331	7.1
3.2.3	驗證應用程序僅使用安全方法（如適當的安全 Cookie（請參閱第 3.4 節）或 HTML 5 會話存儲等在瀏覽器中存儲會話令牌。	✓	✓	✓	539	7.1
3.2.4	驗證會話令牌是使用批准的加密算法生成的。		✓	✓	331	7.1

對於會話管理，TLS 或其他安全傳輸通道是必需的。這一部分在"通信安全"章節中介紹。

V3.3 會話註銷和超時要求

會話超時與 NIST 800-63保持一致，它允許比安全標準通常允許的會話超時時間長得多。組織應查看下錶，如果根據應用程序的風險需要較長的超時時間，則 NIST 值應是會話空閒超時的上限。

在此背景下，L1 爲 IAL1/AAL1，L2 爲 IAL2/AAL3，L3 爲 IAL3/AAL3。對於 IAL2/AAL2 和 IAL3/AAL3，較短的空閒超時是註銷或重新驗證以恢復會話的空閒時間的下限。

#	描述	L1	L2	L3	CWE	NIST §
3.3.1	驗證註銷和過期會使會話令牌無效，以便後退按鈕或下游依賴方不會恢復經過身份驗證的會話，包括跨依賴方。	✓	✓	✓	613	7.1
3.3.2	如果身份驗證器允許用戶保持登錄狀態，請驗證在主動使用時或空閒期間之後定期進行重新身份驗證。	30 days	12 hours or 30 minutes of inactivity, 2FA optional	12 hours or 15 minutes of inactivity, with 2FA	613	7.2
3.3.3	驗證應用程序是否提供在成功更改密碼後終止所有其他活動會話的選項（包括通過密碼重置/恢復進行更改），以及這在應用程序、聯合登錄（如果存在）以及任何依賴方中有效。		✓	✓	613
3.3.4	驗證用戶是否能夠查看並重新輸入登錄憑據，註銷任何或所有當前活動會話和設備。		✓	✓	613	7.1

V3.4 基於 Cookie 的會話管理

#	描述	L1	L2	L3	CWE	NIST §
3.4.1	驗證基於 Cookie 的會話令牌是否具有 'Secure' 屬性集。	✓	✓	✓	614	7.1.1
3.4.2	驗證基於 Cookie 的會話令牌是否具有"HttpOnly"屬性集。	✓	✓	✓	1004	7.1.1
3.4.3	驗證基於 Cookie 的會話令牌是否使用"Samesite"屬性來限制跨站點請求僞造攻擊的風險。	✓	✓	✓	16	7.1.1
3.4.4	驗證基於 Cookie 的會話令牌是否使用"__Host-"前綴（請參閱引用）來提供會話 Cookie 的機密性。	✓	✓	✓	16	7.1.1
3.4.5	驗證如果應用程序在域名下發布，以及設置或使用可能覆蓋或披露會話 Cookie 的會話 Cookie 的其他應用程序，請使用盡可能精確的路徑在基於 Cookie 的會話令牌中設置路徑屬性。	✓	✓	✓	16	7.1.1

V3.5 基於令牌的會話管理

基於令牌的會話管理包括 JWT、OAuth、SAML 和 API 密鑰。其中，API 密鑰已知較弱，不應用於新代碼。

#	描述	L2	L3	CWE	NIST §
3.5.1	驗證應用程序允許用戶撤銷與鏈接的應用程序建立信任關係的 OAuth 令牌。	✓	✓	290	7.1.2
3.5.2	驗證應用程序使用會話令牌而不是靜態 API 機密和密鑰，但舊實現除外。	✓	✓	798
3.5.3	驗證無狀態會話令牌是否使用數字簽名、加密和其他對策來防止篡改、包圍、重播、空密碼和密鑰替換攻擊。	✓	✓	345

V3.6 重新認證聯合身份驗證或斷言

本節涉及編寫依賴方（RP）或憑據服務提供商（CSP）代碼的那些。如果依賴於實現這些功能的代碼，請確保這些問題得到正確處理。

#	描述	L1	L2	L3	CWE	NIST §
3.6.1	驗證依賴方是否指定憑據服務提供商（CSP）的最大身份驗證時間，以及如果訂閱者在該期間內沒有使用會話，則 CSP 是否重新對訂閱者進行身份驗證。			✓	613	7.2.1
3.6.2	驗證憑據服務提供商（CSP）是否將上次身份驗證事件通知依賴方（RP），以允許 RP 確定是否需要重新驗證用戶。			✓	613	7.2.1

V3.7 防禦會話管理漏洞

會話管理攻擊很少，有些與會話的用戶體驗（UX）相關。以前，根據 ISO 27002 要求，ASVS需要同時阻塞多個會話。阻止同時進行會話不再合適，不僅因爲現代用戶擁有許多設備或應用是一個沒有瀏覽器會話的 API，而且在大多數這些實現中，最後一個身份驗證器獲勝，這通常是攻擊者。本節提供有關使用代碼阻止、延遲和檢測會話管理攻擊的主要指導。

半開攻擊的描述

2018年初，一些金融機構使用攻擊者所謂的"半開放式攻擊"遭到破壞。這個詞一直停留在這個行業。攻擊者襲擊了具有不同專有代碼庫的多個機構，而且在同一機構中似乎有不同的代碼庫。半開放攻擊利用了許多現有身份驗證、會話管理和訪問控制系統中常見的設計模式缺陷。

攻擊者通過嘗試鎖定、重置或恢復憑據來啓動半開放攻擊。一種流行的會話管理設計模式，在未經身份驗證、半經過半身份驗證（密碼重置、忘記用戶名）和完全經過身份驗證的代碼之間重新使用用戶配置文件會話對象/模型。此設計模式填充包含受害者配置文件的有效會話對象或令牌，包括密碼哈希和角色。如果控制器或路由器中的訪問控制檢查無法正確驗證用戶是否已完全登錄，則攻擊者將能夠充當用戶。攻擊可能包括將用戶的密碼更改爲已知值、更新電子郵件地址以執行有效的密碼重置、禁用多重身份驗證或註冊新的 MFA 設備、顯示或更改 API 密鑰等。

#	描述	L1	L2	L3	CWE	NIST §
3.7.1	在允許任何敏感事務或帳戶修改之前，驗證應用程序可確保完整、有效的登錄會話或需要重新身份驗證或輔助驗證。	✓	✓	✓	306

參考文獻

有關詳細信息，請參閱:

V4：訪問控制驗證要求

控制目標

授權是隻允許那些允許使用這些資源的人訪問資源的概念。確保經過驗證的應用程序滿足以下高級要求:

訪問資源的用戶持有有效的憑據。.
用戶與一組定義良好的角色和特權關聯.
角色和權限元數據受到保護，防止重播或篡改.

安全驗證要求

V4.1 通用訪問控制設計

#	描述	L1	L2	L3	CWE
4.1.1	驗證應用程序是否對受信任的服務層強制實施訪問控制規則，尤其是在存在客戶端訪問控制且可以繞過時。	✓	✓	✓	602
4.1.2	驗證訪問控制使用的所有用戶和數據屬性以及策略信息不能由最終用戶操作，除非特別授權。	✓	✓	✓	639
4.1.3	驗證存在最特權原則 - 用戶只能訪問具有特定權限的功能、數據文件、URL、控制器、服務和其他資源。這意味着防止欺騙和提升特權。	✓	✓	✓	285
4.1.4	驗證默認存在拒絕原則，即新用戶/角色以最小或無權限啓動，並且用戶/角色在明確分配訪問權限之前不會收到對新功能的訪問權限。	✓	✓	✓	276
4.1.5	驗證訪問控制是否安全失效，包括髮生異常時。	✓	✓	✓	285

V4.2 操作級訪問控制

#	描述	L1	L2	L3	CWE
4.2.1	驗證敏感數據和 API 是否受到保護，防止針對創建、讀取、更新和刪除記錄的不安全直接對象引用（IDOR）攻擊，例如創建或更新其他人的記錄、查看每個人的記錄或刪除所有記錄。	✓	✓	✓	639
4.2.2	驗證應用程序或框架是否強制實施強大的反 CSRF 機制來保護經過身份驗證的功能，並且有效的反自動化或反 CSRF 可保護未經身份驗證的功能。	✓	✓	✓	352

V4.3 其他訪問控制注意事項

#	描述	L1	L2	L3	CWE
4.3.1	驗證管理接口使用適當的多重身份驗證以防止未經授權的使用。	✓	✓	✓	419
4.3.2	驗證目錄瀏覽是否禁用，除非有意需要。此外，應用程序不應允許發現或披露文件或目錄元數據，如 Thumbs.db, .DS_Store, .git or .svn folders.	✓	✓	✓	548
4.3.3	覈實應用程序對價值較低的系統有額外的授權(如升級或自適應認證)，對價值較高的應用程序有額外的授權(如升級或自適應認證)，對價值較高的應用程序有額外的授權(如升級或自適應認證)，以根據應用程序的風險和過去的欺詐行爲實施反欺詐控制。		✓	✓	732

參考文獻

有關詳細信息，請參閱:

V5：編碼驗證要求

控制目標

最常見的 Web應用程序安全漏洞是，在直接使用來自客戶端或環境的輸入時，在沒有任何輸出編碼的情況下，無法正確驗證輸入。此弱點導致 Web 應用程序中幾乎所有重大漏洞，例如跨站點腳本（XSS）、SQL注入、解釋器注入、locale/Unicode 攻擊、系統文件攻擊和緩衝區溢出。

確保經過驗證的應用程序滿足以下高級要求：

輸入驗證和輸出編碼體系結構具有一個商定的管道，以防止注入攻擊。
輸入數據經過強類型、驗證、範圍或長度檢查，或在最壞的情況下進行禁止或篩選。
輸出數據根據儘可能靠近解釋器的數據上下文進行編碼或轉義。

在現代 Web應用程序體系結構中，輸出編碼比以往任何時候都重要。在某些情況下很難提供健壯的輸入驗證，因此使用更安全的 API（如參數化查詢、自動轉義模板框架或精心挑選的輸出編碼）對應用程序的安全性至關重要。

V5.1 輸入驗證要求

正確實現的輸入驗證控制，使用允許列表和強數據類型，可以消除超過 90% 的所有注入攻擊。長度和範圍檢查可以進一步減少這種情況。在應用程序體系結構、設計、編碼以及單元和集成測試期間，需要構建安全輸入驗證。儘管許多這些項目在滲透測試中找不到，但未實現它們的結果通常存在於 V5.3 -輸出編碼和注入防護要求中。建議開發人員和安全代碼審閱者將本節視爲所有項目所需的L1 以防止注入。

#	描述	L1	L2	L3	CWE
5.1.1	驗證應用程序是否具有針對 HTTP 參數污染攻擊的防禦能力，特別是當應用程序框架對請求參數的來源（GET、POST、cookie、headers或環境變量）沒有區別時。	✓	✓	✓	235
5.1.2	驗證框架是否防止大規模參數分配攻擊，或者應用程序是否具有防止不安全參數分配（如標記private或類似字段）的對策。	✓	✓	✓	915
5.1.3	驗證所有輸入（HTML 表單字段、REST 請求、URL 參數、HTTP 標頭、Cookie、批處理文件、RSS 源等）是否都使用正驗證（允許列表）進行驗證。	✓	✓	✓	20
5.1.4	驗證結構化數據是否針對定義的架構（包括允許的字符、長度和模式）進行強類型化和驗證（例如信用卡號或電話），或驗證兩個相關字段是否合理，例如檢查郊區和郵政編碼是否匹配）。	✓	✓	✓	20
5.1.5	驗證 URL 重定向和轉發只允許顯示在允許列表中的目標，或在重定向到可能不受信任的內容時顯示警告。	✓	✓	✓	601

V5.2 沙盒要求

#	描述	L1	L2	L3	CWE
5.2.1	驗證所有來自WYSIWYG編輯器或類似的不受信任的HTML輸入都已經用HTML sanitizer庫或框架功能進行了適當的安全檢查。	✓	✓	✓	116
5.2.2	驗證非結構化數據是否經過安全檢查，以執行允許字符和長度等安全措施。	✓	✓	✓	138
5.2.3	在傳遞到郵件系統之前，請驗證應用程序是否對用戶輸入進行安全檢查，以防止 SMTP 或 IMAP 注入。	✓	✓	✓	147
5.2.4	驗證應用程序是否避免使用 eval（）或其他動態代碼執行功能。如果沒有替代方案，則在執行之前必須對包含的任何用戶輸入進行安全檢查或沙盒處理。	✓	✓	✓	95
5.2.5	通過確保包含的任何用戶輸入已安全檢查或沙盒，驗證應用程序是否防止模板注入攻擊。	✓	✓	✓	94
5.2.6	通過驗證或隔離不受信任的數據或 HTTP 文件元數據（如文件名和 URL 輸入等字段）來驗證應用程序是否防止 SSRF 攻擊。	✓	✓	✓	918
5.2.7	驗證應用程序是否對用戶提供的可擴展矢量圖形（SVG）腳本內容進行安全檢查、禁用或沙盒，特別是它們與內聯腳本和異用對象生成的 XSS 相關內容。	✓	✓	✓	159
5.2.8	驗證應用程序是否對用戶提供的可執行腳本或表達式模板語言內容進行安全檢查、禁用或沙盒，如Markdown, CSS or XSL stylesheets, BBCode, or similar.	✓	✓	✓	94

V5.3 輸出編碼和注入防護要求

與使用中的解釋器接近或相鄰的輸出編碼對任何應用程序的安全性都至關重要。通常，輸出編碼不會持久化，而是用於在適當的輸出上下文中使輸出安全，供立即使用。輸出編碼失敗將導致應用程序不安全、可注入和不安全。

#	描述	L1	L2	L3	CWE
5.3.1	驗證輸出編碼是否與所需的解釋器和上下文相關。例如，根據上下文要求，專門使用 HTML 值、HTML 屬性、JavaScript、URL 參數、HTTP 標頭、SMTP 和其他其他編碼器，尤其是來自不受信任的輸入 (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara).	✓	✓	✓	116
5.3.2	驗證輸出編碼是否保留用戶選擇的字符集和區域設置，以便任何 Unicode 字符點都有效且安全處理.	✓	✓	✓	176
5.3.3	驗證上下文聯繫（最好是自動的，或者最壞的情況是手動的）輸出轉義可防止反射、存儲和基於 DOM 的 XSS。	✓	✓	✓	79
5.3.4	驗證數據選擇或數據庫查詢（例如 .SQL、HQL、ORM、NoSQL）是否使用參數化查詢、ORM、實體框架，或以其他方式受到保護，免受數據庫注入攻擊。	✓	✓	✓	89
5.3.5	驗證不存在參數化或更安全的機制的地方，使用特定於上下文的輸出編碼來防止注入攻擊，例如使用 SQL 轉義來防止 SQL 注入。	✓	✓	✓	89
5.3.6	驗證應用程序是否防止 JavaScript 或 JSON 注入攻擊，包括 eval 攻擊、遠程 JavaScript 包括、內容安全策略（CSP）繞過、DOM XSS 和 JavaScript 表達式評估。	✓	✓	✓	830
5.3.7	驗證應用程序是否防止 LDAP 注入漏洞，或者是否實施了防止 LDAP 注入的特定安全控制。	✓	✓	✓	90
5.3.8	驗證應用程序是否防止 OS 命令注入，以及操作系統調用是否使用參數化的 OS 查詢或使用上下文命令行輸出編碼。	✓	✓	✓	78
5.3.9	驗證應用程序是否防止本地文件包含（LFI）或遠程文件包含（RFI）攻擊。	✓	✓	✓	829
5.3.10	驗證應用程序是否防止 XPath 注入或 XML 注入攻擊。	✓	✓	✓	643

注意：使用參數化查詢或轉義 SQL 並不總是足夠的;表和列名稱、ORDER BY 等無法轉義。在這些字段中包含轉義用戶提供的數據會導致查詢失敗或 SQL 注入。

注意：SVG 格式顯式允許幾乎所有上下文中的 ECMA 腳本，因此可能無法完全阻止所有 SVG XSS 向量。如果需要 SVG 上傳，我們強烈建議將這些上傳的文件作爲text/plain提供，或者使用其他用戶提供的內容域，以防止 XSS 成功接管應用程序。

V5.4 內存、字符串和非託管代碼要求

以下要求僅在應用程序使用系統語言或非託管代碼時適用。

#	描述	L2	L3	CWE
5.4.1	驗證應用程序是否使用內存安全字符串、更安全的內存副本和指針算術來檢測或防止堆棧、緩衝區溢出。	✓	✓	120
5.4.2	驗證格式字符串不會接受潛在的惡意輸入，並且是恆定的。	✓	✓	134
5.4.3	驗證符號、範圍和輸入驗證技術是否用於防止整數溢出。	✓	✓	190

V5.5 反序列化預防要求

#	描述	L1	L2	L3	CWE
5.5.1	驗證序列化對象是否使用完整性檢查或加密以防止惡意對象創建或數據篡改。	✓	✓	✓	502
5.5.2	驗證應用程序是否正確地將 XML 解析器限制爲僅使用盡可能限制最嚴格的配置，並確保禁用不安全功能（如解析外部實體）以防止 XML eXternal 實體（XXE）攻擊。	✓	✓	✓	611
5.5.3	驗證在自定義代碼和第三方庫（如 JSON、XML 和 YAML 解析器）中是否避免或保護不受信任的數據的反序列化。	✓	✓	✓	502
5.5.4	驗證在瀏覽器或基於 JavaScript 的後端中分析 JSON 時，JSON.parse 是否用於分析 JSON 文檔。不要使用 eval（）來分析 JSON。	✓	✓	✓	95

參考文獻

有關詳細信息，請參閱:

For more information on auto-escaping, please see:

For more information on deserialization, please see:

V6：存儲的加密驗證要求

控制目標

確保經過驗證的應用程序滿足以下高級要求：

所有加密模塊都以安全的方式失效，並且錯誤得到正確處理。
使用合適的隨機數生成器。
對密鑰的訪問得到安全管理。

V6.1 數據分類

最重要的資產是應用程序處理、存儲或傳輸的數據。始終執行隱私影響評估，以正確分類任何存儲數據的數據保護需求。

#	描述	L2	L3	CWE
6.1.1	驗證受監管的私人數據在靜止狀態下是否加密存儲，例如個人身份信息（PII）、敏感個人信息或評估可能受歐盟 GDPR 影響的數據。	✓	✓	311
6.1.2	驗證受監管的健康數據在靜止狀態是否加密存儲，例如醫療記錄、醫療設備詳細信息或非匿名研究記錄。	✓	✓	311
6.1.3	驗證受監管的財務數據在靜止狀態下是否加密存儲，如財務賬戶、違約或信用記錄、稅務記錄、支付歷史記錄、受益人或非匿名市場或研究記錄。	✓	✓	311

V6.2 算法

最近加密技術的進步意味着以前安全的算法和密鑰長度不再安全或足以保護數據。因此，應該可以更改算法。

儘管此部分不容易進行滲透測試，但開發人員應該將整個部分視爲必填項，即使大多數項目都缺少L1

#	描述	L1	L2	L3	CWE
6.2.1	驗證所有加密模塊是否安全失效，並且錯誤的處理方式不會啓用填充攻擊。	✓	✓	✓	310
6.2.2	驗證是否使用經過行業驗證或政府批准的加密算法、模式和庫，而不是自定義編碼加密。		✓	✓	327
6.2.3	驗證加密初始化矢量、密碼配置和塊模式是否使用最新建議安全配置。		✓	✓	326
6.2.4	驗證隨機數、加密或散列算法、密鑰長度、圓段、密碼或模式可隨時重新配置、升級或交換，以防止加密中斷。		✓	✓	326
6.2.5	驗證已知不安全的塊模式 (i.e. ECB, etc.), 填充模式 (i.e. PKCS#1 v1.5, etc.), 區塊加密(i.e. Triple-DES, Blowfish, etc.), 和弱散列算法 (i.e. MD5, SHA1, etc.) 除非向後兼容性需要，否則不使用.		✓	✓	326
6.2.6	驗證非密碼、初始化矢量和其他單一使用編號不得與給定的加密密鑰一次使用。生成方法必須適用於使用的算法。		✓	✓	326
6.2.7	驗證加密數據是否通過簽名、經過身份驗證的密碼模式或 HMAC 進行身份驗證，以確保未授權方不會更改密碼文本。			✓	326
6.2.8	驗證所有加密操作都是恆定的，在比較、計算或返回時沒有"短路"操作，以避免信息泄露。			✓	385

V6.3 隨機值

真正的僞隨機數生成(PRNG)是非常難搞好的。一般來說，如果過度使用，系統內cpu會很快耗盡，但隨機性較低的cpu消耗會導致可預測的密鑰和祕密。

#	描述	L2	L3	CWE
6.3.1	驗證當攻擊者預期這些隨機值不可猜測時，是否使用加密模塊批准的加密安全隨機數生成器生成所有隨機數、隨機文件名、隨機 GUID 和隨機字符串。	✓	✓	338
6.3.2	驗證使用 GUID v4 算法和加密安全的僞隨機數生成器（CSPRNG）創建隨機 GUID。使用其他僞隨機數生成器創建的 GUID 可能是可預測的。	✓	✓	338
6.3.3	驗證即使應用程序負載很重，也要使用適當的位創建隨機數，或者應用程序在這種情況下會正常降級。		✓	338

V6.4 密鑰管理

儘管此部分不容易進行滲透測試，但開發人員應該將整個部分視爲必填項，即使大多數項目都缺少L1。

#	描述	L1	L2	L3	CWE
6.4.1	驗證密鑰保管庫等機密管理解決方案是否用於安全地創建、存儲、控制對機密的訪問和銷燬。		✓	✓	798
6.4.2	驗證密鑰材料是否未嚮應用程序公開，而是使用隔離的安全模塊（如保管庫）進行加密操作。		✓	✓	320

參考文獻

有關詳細信息，請參閱:

V7：錯誤處理和日誌記錄驗證要求

控制目標

錯誤處理和日誌記錄的主要目標是爲用戶、管理員和事件響應團隊提供有用的信息。目標不是創建大量的日誌，而是高質量的日誌。

高質量的日誌通常包含敏感數據，必須根據當地數據隱私法律或指令進行保護。這應包括：

除非特別需要，否則不收集或記錄敏感信息。
確保所有記錄的信息都按照其數據分類得到安全處理和保護。
確保日誌不會永遠存儲，但絕對的生存期儘可能短。

如果日誌包含私有或敏感數據，其定義因國家/地區而異，則日誌將成爲應用程序持有的一些最敏感信息，因此對攻擊者本身非常有吸引力。

同樣重要的是確保應用程序安全失效，並且錯誤不會泄露不必要的信息。

V7.1 日誌內容要求

記錄敏感信息是危險的--日誌本身就會成爲機密，這意味着它們需要加密，成爲保留政策的對象，並且必須在安全審計中披露。確保日誌中只保留必要的信息，當然不能保留付款、憑證（包括會話令牌）、敏感或個人身份信息。

V7.1 涵蓋 OWASP 前 10 名 2017：A10.由於 2017：A10 和本節不可滲透測試，因此對以下內容非常重要：

開發人員確保完全遵守本節，就像所有項目都標記爲 L1 一樣
滲透測試人員通過訪談、屏幕截圖或斷言驗證 V7.1 中所有項目的完全合規性

#	描述	L1	L2	L3	CWE
7.1.1	驗證應用程序未記錄憑據或付款詳細信息。會話令牌應僅存儲在不可逆的哈希窗體中的日誌中。	✓	✓	✓	532
7.1.2	驗證應用程序是否未記錄當地隱私法或相關安全策略定義的其他敏感數據。	✓	✓	✓	532
7.1.3	驗證應用程序是否記錄安全相關事件，包括成功和失敗的身份驗證事件、訪問控制失敗、反序列化失敗和輸入驗證失敗。		✓	✓	778
7.1.4	驗證每個日誌事件是否包含必要的信息，這些信息允許在發生事件時詳細調查時間線。		✓	✓	778

V7.2 日誌處理要求

及時日誌記錄對於審覈事件、會審和上報至關重要。確保應用程序的日誌清晰，並且可以輕鬆地在本地監視和分析或將日誌傳輸到遠程監控系統。

V7.2 涵蓋 OWASP 前 10 名 2017：A10.由於 2017：A10 和本節不可滲透測試，這對於:

開發人員確保完全遵守本節，就像所有項目都標記爲 L1 一樣
滲透測試人員通過訪談、屏幕截圖或斷言驗證 V7.2 中所有項目的完全合規性

#	描述	L1	L2	L3	CWE
7.2.1	驗證是否記錄了所有身份驗證決策，而不存儲敏感的會話令牌或密碼。這應包括具有安全調查所需的相關元數據的請求。		✓	✓	778
7.2.2	驗證是否可以記錄所有訪問控制決策並記錄所有失敗的決策。這應包括具有安全調查所需的相關元數據的請求。		✓	✓	285

V7.3 日誌保護要求

可以簡單修改或刪除的日誌對調查和起訴毫無用處。日誌的披露可以公開有關應用程序或它包含的數據的內部詳細信息。保護日誌免遭未經授權的披露、修改或刪除時，必須小心。

#	描述	L2	L3	CWE
7.3.1	驗證應用程序是否對用戶提供的數據進行適當編碼，以防止日誌注入。	✓	✓	117
7.3.2	在日誌查看軟件中查看所有事件時，請驗證所有事件是否受到保護，防止其注入。	✓	✓	117
7.3.3	驗證安全日誌是否受到保護，防止未經授權的訪問和修改。	✓	✓	200
7.3.4	驗證時間源是否同步到正確的時間和時區。如果系統是全局的，以幫助進行事件後取證分析，請考慮僅在 UTC 中進行日誌記錄。	✓	✓

注意：使用自動動態工具和滲透測試很難測試和審查日誌編碼（7.3.1），但架構師、開發人員和源代碼審閱者應認爲這是 L1 要求。

V7.4 錯誤處理

錯誤處理的目的是允許應用程序提供安全相關事件，以便監視、會審和上報。目的不是創建日誌。在記錄與安全相關的事件時，請確保日誌具有目的，並且可以通過 SIEM 或分析軟件來區分它。

#	描述	L1	L2	L3	CWE
7.4.1	驗證在發生意外或安全敏感錯誤時是否顯示通用消息，可能具有支持人員可用於調查的唯一 ID。	✓	✓	✓	210
7.4.2	驗證異常處理（或功能等效項）是否用於整個代碼庫，以考慮預期和意外的錯誤條件。		✓	✓	544
7.4.3	驗證是否定義了"最後一個方法"錯誤處理程序，該處理程序將捕獲所有未處理的異常。		✓	✓	431

注意：某些語言（如 Swift 和Go）以及通過常見的設計實踐-許多功能語言不支持異常或最後一個命令事件處理程序。在這種情況下，架構師和開發人員應使用模式、語言或框架友好的方式，以確保應用程序能夠安全地處理異常、意外或與安全相關的事件。

參考文獻

有關詳細信息，請參閱:

V8：數據保護驗證要求

控制目標

健全數據保護有三個關鍵要素：機密性、完整性和可用性（CIA）。此標準假定數據保護在受信任的系統（如服務器）上實施，該系統已過硬，並有足夠的保護。

應用程序必須假定所有用戶設備都受到某種影響。如果應用程序在不安全的設備（如共享計算機、手機和平板電腦）上傳輸或存儲敏感信息，則應用程序負責確保這些設備上存儲的數據經過加密，並且不會輕易非法獲取、更改或披露。

確保經過驗證的應用程序滿足以下高級別數據保護要求：

保密性：在傳輸過程中和存儲時，應保護數據免受未經授權的觀察或披露。
完整性：應保護數據不被未經授權的攻擊者惡意創建、更改或刪除。
可用性：數據應可根據要求提供給授權用戶。

V8.1 一般數據保護

#	描述	L2	L3	CWE
8.1.1	驗證應用程序可防止敏感數據緩存在服務器組件（如負載均衡器和應用程序緩存）中。	✓	✓	524
8.1.2	驗證服務器上存儲的敏感數據的所有緩存或臨時副本在授權用戶訪問敏感數據後是否受到保護，防止未經授權的訪問或清除/失效。	✓	✓	524
8.1.3	驗證應用程序最小化請求中的參數數，如隱藏字段、Ajax 變量、cookie 和標頭值。	✓	✓	233
8.1.4	驗證應用程序能否檢測和提醒異常請求數，例如 IP、用戶、每小時或每天的總數，或者任何對應用程序有意義的請求。	✓	✓	770
8.1.5	驗證是否執行了重要數據的定期備份，以及是否執行了數據測試還原。		✓	19
8.1.6	驗證備份是否安全存儲，以防止數據被盜或損壞。		✓	19

V8.2 客戶端數據保護

#	描述	L1	L2	L3	CWE
8.2.1	驗證應用程序設置足夠的反緩存標頭，以便敏感數據不會緩存在現代瀏覽器中。	✓	✓	✓	525
8.2.2	驗證存儲在瀏覽器存儲中的數據（如 HTML5 本地存儲、會話存儲、IndexedDB 或 Cookie）不包含敏感數據或 PII。	✓	✓	✓	922
8.2.3	驗證在客戶端或會話終止後，是否從客戶端存儲（如瀏覽器 DOM）清除了經過身份驗證的數據。	✓	✓	✓	922

V8.3 敏感私有數據

本節有助於保護敏感數據不被創建、讀取、更新或刪除，尤其是批量數據。

遵守本節意味着符合 V4 訪問控制，特別是V4.2。例如，要防止未經授權的更新或泄露敏感的個人信息，需要遵守 V4.2.1。請遵守本節和 V4 的全覆蓋。

注意：隱私法規和法律（如澳大利亞隱私原則 APP-11 或GDPR）直接影響應用程序必須如何實施敏感個人信息的存儲、使用和傳輸。這從嚴厲的懲罰到簡單的建議。請諮詢您當地的法律和法規，並可根據要求諮詢合格的隱私專家或律師。

#	描述	L1	L2	L3	CWE
8.3.1	驗證敏感數據是否發送到 HTTP 消息正文或標頭中的服務器，以及來自任何 HTTP 謂詞的查詢字符串參數不包含敏感數據。	✓	✓	✓	319
8.3.2	驗證用戶是否具有按需刪除或導出數據的方法。	✓	✓	✓	212
8.3.3	驗證用戶是否獲得有關收集和使用所提供的個人信息的清晰語言，以及用戶在以任何方式使用這些數據之前已提供選擇加入同意使用這些數據。	✓	✓	✓	285
8.3.4	驗證應用程序創建和處理的所有敏感數據都已識別，並確保已制定有關如何處理敏感數據的政策。	✓	✓	✓	200
8.3.5	如果數據是根據相關數據保護指令收集的，或者需要記錄訪問情況，則驗證訪問敏感數據是否進行審覈（而不記錄敏感數據本身）。		✓	✓	532
8.3.6	使用零或隨機數據，驗證內存中包含的敏感信息在不再需要緩解內存轉儲攻擊時是否被覆蓋。		✓	✓	226
8.3.7	驗證加密所需的敏感或私人信息是否使用具有保密性和完整性的已批准算法進行加密。		✓	✓	327
8.3.8	驗證敏感個人信息是否受數據保留分類，以便自動刪除舊數據或過期數據，按計劃刪除，或根據情況需要刪除。		✓	✓	285

在考慮數據保護時，首要考慮的應該是批量提取、修改或過度使用。例如，許多社交媒體系統僅允許用戶每天添加100 個新朋友，但這些請求來自哪個系統並不重要。銀行平臺可能希望阻止每小時超過5筆交易，將1000元以上的資金轉移到外部機構。每個系統的要求可能大不相同，因此決定"異常"必須考慮威脅模型和業務風險。重要的標準是能夠檢測、阻止或最好阻止此類異常批量操作。

參考文獻

有關詳細信息，請參閱:

V9：通信驗證要求

控制目標

確保經過驗證的應用程序滿足以下高級別要求：

無論傳輸的數據是否敏感，始終使用 TLS 或強加密
最新的、領先的配置，建議用於採用首選算法和密碼。
弱或即將被棄用的算法和密碼作爲最後手段被採用。
已棄用或已知的不安全算法和密碼將被禁用。

關於安全TLS配置的領先行業建議經常變化，通常是由於現有算法和密碼的災難性突破。始終使用最新版本的TLS配置審查工具（如SSLyze或其他TLS掃描器）來配置首選順序和算法選擇。應定期檢查配置，以確保安全通信配置始終存在並有效。

V9.1 客戶端通信安全要求

所有客戶端通信應僅通過加密通信路徑進行。特別是，使用TLS1.2或更晚基本上是所有，但要求現代瀏覽器和搜索引擎。應使用在線工具定期審查配置，以確保採用最新的領先做法。

#	描述	L1	L2	L3	CWE
9.1.1	驗證安全 TLS 是否用於所有客戶端連接，並且不會回退到不安全或未加密的協議。	✓	✓	✓	319
9.1.2	使用聯機或最新的 TLS 測試工具驗證是否啓用了強算法、密碼和協議，並設置了最強的算法和密碼作爲首選算法。	✓	✓	✓	326
9.1.3	驗證舊版本的 SSL 和 TLS 協議、算法、密碼和配置是否已禁用，例如 SSLv2、SSLv3 或 TLS 1.0 和 TLS 1.1。最新版本的 TLS 應該是首選的密碼套件。	✓	✓	✓	326

V9.2 服務器通信安全要求

服務器通信不僅僅是HTTP。與其他系統之間的安全連接，如監控系統、管理工具、遠程訪問和ssh、中間件、數據庫、主機、合作伙伴或外部源系統--必須到位。所有這些都必須進行加密，以免出現"日防夜防，家賊難防"的情形。

#	描述	L2	L3	CWE
9.2.1	驗證與服務器的連接是否使用受信任的 TLS 證書。在使用內部生成或自簽名證書時，必須將服務器配置爲僅信任特定的內部 CA 和特定的自簽名證書。所有其他應被拒絕。	✓	✓	295
9.2.2	驗證加密通信（如 TLS）是否用於所有入站和出站連接，包括管理端口、監視、身份驗證、API 或 Web 服務調用、數據庫、雲、無服務器、大型機、外部連接和合作夥伴連接。服務器不得回退到不安全或未加密的協議。	✓	✓	319
9.2.3	驗證與涉及敏感信息或功能的外部系統的所有加密連接都經過身份驗證。	✓	✓	287
9.2.4	驗證是否已啓用並配置正確的認證吊銷，如聯機證書狀態協議（OCSP）。	✓	✓	299
9.2.5	驗證是否已記錄後端 TLS 連接故障.		✓	544

參考文獻

有關詳細信息，請參閱:

關於"TLS 的已批准模式"的注意事項。過去，ASVS 指的是美國標準 FIPS 140-2，但作爲一個全球標準，應用美國標準可能很難、矛盾或令人困惑。實現 9.1.3 的更好方法是查看指南（如 Mozilla 的服務器端 TLS） or generate known good configurations或生成已知良好的配置，並使用已知的 TLS 評估工具（如 sslyze、各種漏洞掃描器或受信任的 TLS在線評估服務）獲得所需的安全級別。一般來說，我們認爲本節的不合規是使用過時或不安全的密碼和算法、缺乏完美的正向保密、過時或不安全的 SSL 協議、弱的首選密碼等等。

V10：惡意代碼驗證要求

控制目標

確保代碼滿足以下高級別要求：

惡意活動得到安全、妥善的處理，不會影響應用程序的其餘部分.
沒有定時炸彈或其他基於時間的攻擊.
不請求到惡意或未經授權的目的地.
沒有後門, Easter eggs, salami attacks, rootkits, 或攻擊者可以控制的未經授權的代碼。

查找惡意代碼的行爲是徒勞的，這是不可能完全驗證的。應盡最大努力確保代碼沒有固有的惡意代碼或不需要的功能。

V10.1 代碼完整性控制

對抗惡意代碼的最佳防禦是"信任，但驗證"。在許多司法管轄區，將未經授權的或惡意代碼引入代碼通常是刑事犯罪。政策和程序應明確有關惡意代碼的制裁。

首席開發人員應定期查看代碼簽入，尤其是那些可能訪問時間、I/O 或網絡功能的代碼簽入。

#	描述	L1	L2	L3	CWE
10.1.1	驗證正在使用的代碼分析工具，該工具可以檢測潛在的惡意代碼，如時間函數、不安全的文件操作和網絡連接。			✓	749

V10.2 惡意代碼搜索

惡意代碼極爲罕見，難以檢測。手動行代碼審查可以幫助尋找邏輯炸彈，但即使是最有經驗的代碼審閱者將很難找到惡意代碼，即使他們知道它的存在。

如果沒有對源代碼（包括第三方庫）的完全訪問，則無需遵守本節。

#	描述	L2	L3	CWE
10.2.1	驗證應用程序源代碼和第三方庫不包含未經授權的電話家庭或數據收集功能。如果存在此類功能，則在收集任何數據之前獲取用戶操作的權限。	✓	✓	359
10.2.2	驗證應用程序是否對隱私相關功能或傳感器（如聯繫人、攝像機、麥克風或位置）不要求不必要的或過多的權限。	✓	✓	272
10.2.3	驗證應用程序源代碼和第三方庫不包含後門，例如硬編碼或其他未記錄的帳戶或密鑰、代碼混淆、未記錄的二進制 Blob、rootkit 或反調試、不安全的調試功能，或者發現可能惡意使用的過時、不安全或隱藏功能。		✓	507
10.2.4	通過搜索日期和時間相關功能，驗證應用程序源代碼和第三方庫不包含定時炸彈。		✓	511
10.2.5	驗證應用程序源代碼和第三方庫不包含惡意代碼，如salami attacks, logic bypasses, or logic bombs.		✓	511
10.2.6	驗證應用程序源代碼和第三方庫不包含彩蛋或任何其他可能不需要的功能。		✓	507

V10.3 部署的應用程序完整性控制

部署應用程序後，仍然可以插入惡意代碼。應用程序需要保護自己免受常見攻擊，例如從不受信任的源執行未簽名的代碼和子域接管。遵守本部分可能是可操作且連續的。

#	描述	L1	L2	L3	CWE
10.3.1	驗證如果應用程序具有客戶端或服務器自動更新功能，應通過安全通道獲取更新並進行數字簽名。在安裝或執行更新之前，更新代碼必須驗證更新的數字簽名。	✓	✓	✓	16
10.3.2	驗證應用程序是否使用完整性保護，如代碼簽名或子資源完整性。應用程序不得從不受信任的源加載或執行代碼，例如從不受信任的源或 Internet 加載包括、模塊、插件、代碼或庫。	✓	✓	✓	353
10.3.3	如果應用程序依賴於 DNS 條目或 DNS 子域（如過期的域名、過期的 DNS 指針或 CNAMEs、公共源代碼存儲庫中的過期項目，或者臨時雲 API、無服務器函數或存儲存儲桶（自動存儲桶autogen-bucket-idid.cloud.example.com）或類似文件，則驗證應用程序是否具有從子域接管中免受保護。保護可以包括確保定期檢查應用程序使用的 DNS 名稱是否過期或更改。	✓	✓	✓	350

參考文獻

V11：業務邏輯驗證要求

控制目標

確保經過驗證的應用程序滿足以下高級別要求：

業務邏輯流是按順序處理的，不能繞過。
業務邏輯包括檢測和防止自動攻擊的限制，例如連續小額資金轉移，或一次添加一百萬個好友，等等。
高價值業務邏輯流考慮了濫用案例和惡意參與者，並具有防止欺騙、篡改、拒絕、信息泄露和特權提升攻擊的保護。

V11.1 業務邏輯安全要求

業務邏輯安全性對於每個應用程序都是個性化的，因此沒有一個清單會全面符合要求。業務邏輯安全性必須設計爲可防止可能的外部威脅 - 無法使用 Web 應用程序防火牆或安全通信添加業務邏輯安全性。我們建議在設計期間使用威脅建模，例如使用 OWASP Cornucopia 或類似工具。

#	描述	L1	L2	L3	CWE
11.1.1	驗證應用程序將僅按順序處理同一用戶的業務邏輯流，而不跳過步驟。	✓	✓	✓	841
11.1.2	驗證應用程序將只處理業務邏輯流，所有步驟都在現實的人類提交時間內處理，即交易不會太快提交。	✓	✓	✓	799
11.1.3	驗證應用程序對特定業務操作或事務具有適當的限制，這些操作或事務是根據每個用戶正確執行的。	✓	✓	✓	770
11.1.4	驗證應用程序是否有足夠的反自動化控制，以檢測和防止數據泄露、業務邏輯請求過多、文件上傳過多或拒絕服務攻擊。	✓	✓	✓	770
11.1.5	驗證應用程序是否具有業務邏輯限制或驗證，以防止可能的業務風險或威脅，使用威脅建模或類似方法進行識別。	✓	✓	✓	841
11.1.6	驗證應用程序是否受到"檢查到使用時間"（TOCTOU）問題或其他敏感操作的競賽條件的影響。		✓	✓	367
11.1.7	驗證應用程序從業務邏輯的角度監控異常事件或活動。例如，嘗試執行不按順序的行動或正常用戶絕不會嘗試的行動		✓	✓	754
11.1.8	在檢測到自動攻擊或異常活動時，驗證應用程序是否具有可配置的警報。		✓	✓	390

參考文獻

有關詳細信息，請參閱:

OWASP Web Security Testing Guide 4.1: Business Logic Testing
Anti-automation can be achieved in many ways, including the use of OWASP AppSensor and OWASP Automated Threats to Web Applications
OWASP AppSensor can also help with Attack Detection and Response.
OWASP Cornucopia

V12：文件和資源驗證要求

控制目標

確保經過驗證的應用程序滿足以下高級別要求：

應以安全的方式相應地處理不受信任的文件數據。
從不受信任的源獲取的不受信任的文件數據存儲在 Web 根目錄之外，並且權限有限。

V12.1 文件上傳要求

雖然zip炸彈顯然可以使用滲透測試技術進行測試，但它們被認爲是L2及以上級別的，以鼓勵設計和開發考慮與仔細的手動測試，並避免拒絕服務條件的自動或不熟練的手動滲透測試。

#	描述	L1	L2	L3	CWE
12.1.1	驗證應用程序不會接受可能填滿存儲或導致拒絕服務的大型文件。	✓	✓	✓	400
12.1.2	驗證壓縮文件是否檢查"zip 炸彈" - 小型輸入文件，將解壓縮成巨大的文件，從而耗盡文件存儲限制。		✓	✓	409
12.1.3	驗證每個用戶的文件大小配額和最大文件數是否強制實施，以確保單個用戶無法用過多的文件或過大的文件填滿存儲。		✓	✓	770

V12.2 文件完整性要求

#	描述	L1	L2	L3	CWE
12.2.1	驗證從不受信任的源獲取的文件是否根據文件的內容驗證爲預期類型。		✓	✓	434

V12.3 文件執行要求

#	描述	L1	L2	L3	CWE
12.3.1	驗證系統或框架文件系統不直接使用用戶提交的文件名元數據，以及 URL API 是否用於防止路徑遍歷。	✓	✓	✓	22
12.3.2	驗證用戶提交的文件名元數據是否經過驗證或忽略，以防止披露、創建、更新或刪除本地文件（LFI）.	✓	✓	✓	73
12.3.3	驗證用戶提交的文件名元數據是否經過驗證或忽略，以防止通過遠程文件包含（RFI）或服務器端請求僞造（SSRF）攻擊披露或執行遠程文件。	✓	✓	✓	98
12.3.4	通過驗證或忽略 JSON、JSONP 或 URL 參數中的用戶提交的文件名來驗證應用程序是否防止反射文件下載（RFD），響應內容類型標頭應設置爲text/plain，並且內容處置標頭應具有固定的文件名。	✓	✓	✓	641
12.3.5	驗證不受信任的文件元數據是否直接用於系統 API 或庫，以防止 OS 命令注入。	✓	✓	✓	78
12.3.6	驗證應用程序是否包含並執行來自不受信任來源的功能，例如未經驗證的內容發佈網絡、JavaScript庫、node npm庫或服務器端DLL。		✓	✓	829

V12.4 文件存儲要求

#	描述	L1	L2	L3	CWE
12.4.1	驗證從不受信任的源獲取的文件是否存儲在 Web 根目錄之外，權限有限，最好具有強驗證功能。	✓	✓	✓	922
12.4.2	驗證防病毒掃描程序是否掃描從不受信任的源獲取的文件，以防止上載已知的惡意內容。	✓	✓	✓	509

V12.5 文件下載要求

#	描述	L1	L2	L3	CWE
12.5.1	驗證 Web 層是否配置爲僅提供具有特定文件擴展名的文件，以防止意外信息和源代碼泄漏。例如，備份文件（例如 .bak）、臨時工作文件（例如.swp）、壓縮文件（.zip、.tar.gz 等）和編輯人員常用的其他擴展名應被阻止，除非需要。	✓	✓	✓	552
12.5.2	驗證對上載文件的直接請求永遠不會作爲 HTML/JavaScript 內容執行.	✓	✓	✓	434

V12.6 SSRF 保護要求

#	描述	L1	L2	L3	CWE
12.6.1	驗證網絡或應用程序服務器，是否配置了允許服務器向其發送請求或加載數據/文件的資源或系統列表	✓	✓	✓	918

參考文獻

有關詳細信息，請參閱:

V13: API 和 Web 服務驗證要求

控制目標

確保使用受信任的服務層 API（通常使用 JSON 或 XML 或 GraphQL）的經過驗證的應用程序具有：

充分身份驗證、會話管理和授權所有 Web 服務。
輸入從較低信任級別傳遞到更高信任級別的所有參數的輸入驗證。
所有 API 類型（包括雲和無服務器 API）的有效安全控制

請結合同一級別的所有其他章節閱讀本章;我們不再重複身份驗證或 API 會話管理問題。

V13.1 通用Web服務安全驗證要求

#	描述	L1	L2	L3	CWE
13.1.1	驗證所有應用程序組件是否使用相同的編碼和解析器，以避免分析利用 SSRF 和 RFI 攻擊中可能使用的不同 URI 或文件分析行爲的攻擊。	✓	✓	✓	116
13.1.2	驗證對管理和管理功能的訪問是否僅限於授權的管理員。	✓	✓	✓	419
13.1.3	驗證 API URL 不會公開敏感信息，如 API 密鑰、會話令牌等。	✓	✓	✓	598
13.1.4	驗證授權決策是在 URI 中做出的，由控制器或路由器的編程或聲明性安全性強制實施，並在資源級別通過基於模型的權限強制實施。		✓	✓	285
13.1.5	驗證包含意外或缺少內容類型的請求是否被拒絕了相應的標頭（HTTP 響應狀態 406 不可接受或 415 不支持的媒體類型）。		✓	✓	434

V13.2 REST 的 Web 服務驗證要求

JSON 架構驗證處於標準化的草稿階段（請參閱參考）。在考慮使用 JSON 架構驗證（這是 RESTful Web 服務的最佳做法）時，請考慮將以下附加數據驗證策略與 JSON 架構驗證結合使用：

分析 JSON 對象的驗證，例如是否缺少或額外的元素。
使用標準輸入驗證方法（如數據類型、數據格式、長度等）驗證 JSON 對象值。
和正式的 JSON 架構驗證。

一旦 JSON 架構驗證標準正式化，ASVS將更新其在此領域的建議。仔細監視任何正在使用的 JSON 架構驗證庫，因爲它們需要定期更新，直到標準正式化，並且錯誤被修復爲引用實現。

#	描述	L1	L2	L3	CWE
13.2.1	驗證啓用的 RESTful HTTP 方法是否爲用戶或操作的有效選擇，例如防止正常用戶在受保護的 API 或資源上使用 DELETE 或 PUT。	✓	✓	✓	650
13.2.2	在接受輸入之前，請驗證 JSON 架構驗證是否到位並驗證。	✓	✓	✓	20
13.2.3	驗證使用 Cookie 的 RESTful Web 服務是否通過至少一項或多項以下操作受到保護，防止跨網站請求僞造：雙重提交 Cookie 模式、CSRF 無項或源請求header檢查。	✓	✓	✓	352
13.2.4	驗證REST服務是否具有反自動控制功能，以防止過度調用，特別是在API未被認證的情況下。		✓	✓	770
13.2.5	驗證 REST 服務是否顯式檢查傳入的內容類型是否爲預期內容類型，如 application/xml 或者 application/json.		✓	✓	436
13.2.6	驗證消息頭和有效負載是否可信，且在傳輸過程中未修改。在許多情況下，需要強加密傳輸（僅 TLS）可能就足夠了，因爲它同時提供機密性和完整性保護。每消息數數字簽名可以在高安全性應用程序的傳輸保護之外提供額外的保證，但會帶來額外的複雜性和風險，以權衡其優勢。		✓	✓	345

V13.3 SOAP Web 服務驗證要求

#	描述	L1	L2	L3	CWE
13.3.1	驗證 XSD 架構驗證是否進行，以確保正確格式的 XML 文檔，然後驗證每個輸入字段，然後再對這些數據進行任何處理。	✓	✓	✓	20
13.3.2	驗證是否使用 WS-Security 對消息有效負載進行簽名，以確保客戶端和服務之間的可靠傳輸。		✓	✓	345

注意：由於 XXE 攻擊 DTD 的問題，不應使用 DTD 驗證，並且框架 DTD 評估應根據 V14配置中的要求禁用。

V13.4 GraphQL 和其他 Web 服務數據層安全要求

#	描述	L1	L2	L3	CWE
13.4.1	驗證查詢是否允許列表或深度限制和數量限制的組合用於防止 GraphQL 或數據層表達式拒絕服務（DoS）。爲避免昂貴的嵌套查詢而發生，對於更高級的方案，應使用查詢成本分析。		✓	✓	770
13.4.2	驗證 GraphQL 或其他數據層授權邏輯應在業務邏輯層而不是 GraphQL 層實現。		✓	✓	285

引用

有關詳細信息，請參閱:

V14: 配置驗證要求

控制目標

確保經過驗證的應用程序具有：

安全、可重複、可自動化的構建環境.
強化的第三方庫、依賴項和配置管理，使應用程序不包括過期或不安全的組件。
按默認安全配置，因此管理員和用戶必須削弱默認安全狀態。

配置的應用開箱應該是安全上網的，也就是安全的開箱配置

V14.1 構建

構建流水線是可重複安全性的基礎 - 每次發現不安全的東西時，都可以在源代碼、生成或部署腳本中解析，並自動進行測試。我們強烈建議使用具有自動安全和依賴項檢查的構建流水線，這些流水線會警告或破壞生成，以防止將已知的安全問題部署到生產環境中。不定期執行的手動步驟直接導致可避免的安全錯誤.

隨着行業向 DevSecOps模型發展，確保部署和配置的持續可用性和完整性以實現"已知良好"狀態非常重要。過去，如果系統被黑客攻擊，需要幾天到幾個月的時間才能證明沒有發生進一步的入侵。如今，隨着軟件定義的基礎架構、零停機時間的快速A/B 部署和自動容器化構建的出現，可以自動和持續地構建、強化和部署任何受損系統的"已知良好"替代。

如果傳統模式仍然存在，則必須採取手動步驟來強化和備份該配置，以便及時將受損的系統快速替換爲高完整性、不折不扣的系統。

符合本節需要自動生成系統，並訪問生成和部署腳本。

#	描述	L2	L3	CWE
14.1.1	驗證應用程序生成和部署過程是否以安全和可重複的方式執行，例如 CI/ CD 自動化、自動配置管理和自動部署腳本。	✓	✓
14.1.2	驗證編譯器標誌是否已配置爲啓用所有可用的緩衝區溢出保護和警告，包括堆棧隨機化、數據執行預防，並在找到不安全的指針、內存、格式字符串、整數或字符串操作時中斷生成。	✓	✓	120
14.1.3	驗證服務器配置是否根據使用中的應用程序服務器和框架的建議進行強化。	✓	✓	16
14.1.4	驗證可以使用自動部署腳本（在合理的時間內從記錄和測試的 Runbook 構建）或及時從備份中還原應用程序、配置和所有依賴項進行重新部署。	✓	✓
14.1.5	驗證授權管理員能否驗證所有與安全相關的配置的完整性，以檢測篡改情況。		✓

V14.2 依賴

依賴項管理對任何類型的應用程序的安全操作都至關重要。未能跟上過時或不安全的依賴關係，是迄今爲止規模最大、成本最大的攻擊的根本原因。

注意：在級別 1 中，14.2.1合規性與客戶端和其他庫和組件的觀察或檢測有關，而不是更準確的生成時間靜態代碼分析或依賴項分析。這些更準確的技術可以通過審查來發現。

#	描述	L1	L2	L3	CWE
14.2.1	驗證所有組件都是最新的，最好在生成或編譯期間使用依賴項檢查器。	✓	✓	✓	1026
14.2.2	驗證是否刪除了所有不必要的功能、文檔、示例、配置，例如示例應用程序、平臺文檔以及默認或示例用戶。	✓	✓	✓	1002
14.2.3	如果應用程序資產（如 JavaScript 庫、CSS 或 Web 字體）在內容交付網絡（CDN）或外部提供商上外部託管，則子資源完整性（SRI）是否用於驗證資產的完整性。	✓	✓	✓	829
14.2.4	驗證第三方組件是否來自預定義、受信任和持續維護的存儲庫。		✓	✓	829
14.2.5	驗證是否維護了所有正在使用的第三方庫的清單目錄。		✓	✓
14.2.6	驗證通過沙盒或封裝第三方庫來僅嚮應用程序中公開所需的行爲，可減少攻擊面。		✓	✓	265

V14.3 意外的安全披露要求

生產用的配置應該進行加固，以防止常見的攻擊，如調試控制檯，提高跨站腳本(XSS)和遠程文件包含(RFI)攻擊的標準，並消除瑣碎的信息發現 "漏洞"，這些漏洞是許多滲透測試報告不受歡迎的標誌。這些問題中的許多問題很少被評爲重大風險，因爲它們與其他漏洞鏈在一起。如果這些問題在默認情況下不存在，就會在大多數攻擊成功之前提高門檻。

#	描述	L1	L2	L3	CWE
14.3.1	驗證 Web 或應用程序服務器和框架錯誤消息是否已配置爲向用戶提供可操作的自定義響應，以消除任何意外的安全披露。	✓	✓	✓	209
14.3.2	驗證在生產環境中禁用 Web 或應用程序服務器和應用程序框架調試模式，以消除調試功能、開發人員控制檯和意外的安全泄露。	✓	✓	✓	497
14.3.3	驗證 HTTP 標頭或 HTTP 響應的任何部分是否公開系統組件的詳細版本信息。	✓	✓	✓	200

V14.4 HTTP Security Headers Requirements

#	描述	L1	L2	L3	CWE
14.4.1	驗證每個HTTP響應都包含一個Content-Type頭。text/*、/+xml和application/xml內容類型也應該指定一個安全的字符集（如UTF-8、ISO-8859-1）。	✓	✓	✓	173
14.4.2	驗證所有API響應都包含Content-Disposition: attachment; filename="api.json "頭（或內容類型的其他適當文件名）	✓	✓	✓	116
14.4.3	驗證內容安全策略（CSP）響應標頭是否到位，以幫助減輕對 XSS 攻擊（如 HTML、DOM、JSON 和 JavaScript 注入漏洞）的影響。	✓	✓	✓	1021
14.4.4	驗證所有響應都包含 X-Content-Type-Options: nosniff 標頭。	✓	✓	✓	116
14.4.5	驗證所有響應和所有子域都包含Strict-Transport-Security頭，例如Strict-Transport-Security: max-age=15724800; includeSubdomains	✓	✓	✓	523
14.4.6	驗證是否包含了合適的 "Referrer-Policy "頭，如 "no-Referrer "或 " same-origin"。	✓	✓	✓	116
14.4.7	通過使用合適的Content-Security-Policy：frame-ancestors和X-Frame-Options響應頭，驗證Web應用程序的內容默認不能嵌入第三方網站，只有在必要時才允許嵌入確切的資源	✓	✓	✓	346

V14.5 驗證HTTP請求標頭要求

#	描述	L1	L2	L3	CWE
14.5.1	驗證應用程序服務器是否只接受應用程序/API 使用的 HTTP 方法，包括預檢前選項，以及記錄/警報對應用程序上下文無效的任何請求。	✓	✓	✓	749
14.5.2	驗證提供的源標頭是否未用於身份驗證或訪問控制決策，因爲攻擊者可以很容易地更改源標頭。	✓	✓	✓	346
14.5.3	驗證跨源資源共享(CORS)Access-Control-Allow-Origin頭使用嚴格的受信任域和子域的允許列表進行匹配，不支持 "null "origin。	✓	✓	✓	346
14.5.4	驗證受信任代理或 SSO 設備（如承載令牌）添加的 HTTP 標頭是否由應用程序進行身份驗證。		✓	✓	306

參考文獻

有關詳細信息，請參閱:

OWASP Web Security Testing Guide 4.1: Testing for HTTP Verb Tampering
Adding Content-Disposition to API responses helps prevent many attacks based on misunderstanding on the MIME type between client and server, and the "filename" option specifically helps prevent Reflected File Download attacks.
Content Security Policy Cheat Sheet
Exploiting CORS misconfiguration for BitCoins and Bounties
OWASP Web Security Testing Guide 4.1: Configuration and Deployment Management Testing
Sandboxing third party components

附錄 A：詞彙表

Address Space Layout Randomization (ASLR) – 一種提高利用內存損壞漏洞難度的技術。
Allow list – 允許的數據或操作的列表，例如允許執行輸入驗證的字符列表.
Application Security – 應用層安全的重點是分析構成開放系統互連參考模型（OSI模型）應用層的組件，而不是關注底層操作系統或連接網絡等。
Application Security Verification – 參照OWASP ASVS對程序進行技術評估。
Application Security Verification Report – 記錄覈查人員對某一特定應用的總體結果和輔助分析的報告。
Authentication – 覈實申請用戶所稱的身份；
Automated Verification – 使用自動化工具（可以是動態分析工具，也可以是靜態分析工具，或者兩者兼而有之），利用漏洞簽名來發現問題。
Black box testing – 它是一種軟件測試方法，檢查應用程序的功能，而不窺視其內部結構或工作原理。
Component – 一個自足的代碼單元，帶有與其他組件通信的相關磁盤和網絡接口。
Cross-Site Scripting (XSS) – 通常在網絡應用程序中發現的安全漏洞，允許在內容中注入客戶端腳本。.
Cryptographic module – 實現加密算法和/或生成加密密鑰的硬件、軟件和/或固件。
Common Weakness Enumeration (CWE) -由社區制定的常見軟件安全弱點清單。它是一種共同語言，是軟件安全工具的衡量標準，也是弱點識別、緩解和預防工作的基線。
Design Verification – 對應用程序的安全架構進行技術評估。
Dynamic Application Security Testing (DAST) -技術的目的是檢測表明應用程序在運行狀態下存在安全漏洞的條件。
Dynamic Verification –使用自動化工具，利用漏洞簽名來發現應用程序執行過程中的問題。
Fast IDentity Online (FIDO) - 一套認證標準，允許使用各種不同的認證方法，包括生物識別技術、可信平臺模塊（TPM）、USB安全令牌等。
Globally Unique Identifier (GUID) – 軟件中作爲標識符的唯一參考號
Hyper Text Transfer Protocol (HTTPS) –一種分佈式、協作式、超媒體信息系統的應用協議。它是萬維網數據通信的基礎。
Hardcoded keys – 存儲在文件系統中的加密密鑰，無論是代碼、註釋還是文件。
Hardware Security Module (HSM) - 能夠以受保護的方式存儲加密密鑰和其他祕密的硬件組件。Hibernate Query Language (HQL) - 一種查詢語言，其外觀與Hibernate ORM庫使用的SQL類似。
Input Validation – 不受信任的用戶輸入的規範化和驗證。
Malicious Code – 在應用程序的開發過程中，在應用程序所有者不知情的情況下引入應用程序的代碼，從而規避了應用程序的預期安全策略。與病毒或蠕蟲等惡意軟件不同!
Malware – 在應用程序用戶或管理員不知情的情況下，在運行時被引入應用程序的可執行代碼
Open Web Application Security Project (OWASP) –開放式網絡應用安全項目（OWASP）是一個全球性的免費開放社區，專注於提高應用軟件的安全性。我們的使命是讓應用程序的安全性 "可見"，以便人們和組織可以對應用程序的安全風險做出明智的決定。參見：https://www.owasp.org/
One-time Password (OTP) - 獨一生成的密碼，一次性使用。
Object-relational Mapping (ORM) - 用於允許在應用程序中使用與應用程序兼容的對象模型來引用和查詢基於關係/表格的數據庫的系統。
Password-Based Key Derivation Function 2 (PBKDF2) - 一種特殊的單向算法，用於從輸入文本（如密碼）和一個額外的隨機鹽值創建一個強密碼密鑰，因此，如果存儲結果值而不是原始密碼，可以用來使密碼更難離線破解。
Personally Identifiable Information (PII) -是指可以單獨使用或與其他信息一起使用的信息，以識別、聯繫或確定一個人的位置，或在背景下識別一個人
Position-independent executable (PIE) - 一段機器代碼，放在主存儲器的某處，無論其絕對地址如何，都能正常執行。
Public Key Infrastructure (PKI) - 將公用鑰匙與各實體的身份聯繫起來的安排。這種約束是通過在證書頒發機構登記和頒發證書的過程建立起來的。
Public Switched Telephone Network (PSTN) - 傳統的電話網包括固定電話和移動電話
Relying Party (RP) - 一般來說，一個應用程序依賴於用戶與一個單獨的認證提供者進行的認證。該應用程序依賴該認證提供者提供的某種標記或一組簽名的斷言，以相信用戶是他們所說的那個人
Static application security testing (SAST) - 一套旨在分析應用程序源代碼、字節碼和二進制文件的技術，以發現表明安全漏洞的編碼和設計條件。SAST解決方案在非運行狀態下從 "內到外 "分析應用程序。
Software development lifecycle (SDLC) - 軟件從最初的需求到部署和維護的一步步開發過程。
Security Architecture –應用程序設計的抽象，它確定並描述了安全控制的使用地點和方式，還確定並描述了用戶和應用程序數據的位置和敏感性。
Security Configuration – 應用程序的運行時配置會影響安全控制的使用方式。
Security Control –執行安全檢查（如訪問控制檢查）或在調用時產生安全效果（如生成審計記錄）的功能或組件。
Server-side Request Forgery (SSRF) - 通過提供或修改服務器上運行的代碼將讀取或提交數據的URL，濫用服務器上的功能來讀取或更新內部資源的攻擊。
Single Sign-on Authentication (SSO) - 這種情況發生在用戶登錄一個應用程序，然後自動登錄到其他應用程序，而無需重新認證。例如，當你登錄谷歌時，在訪問YouTube、谷歌文檔和Gmail等其他谷歌服務時，你會自動登錄。
SQL Injection (SQLi) – 一種用於攻擊數據驅動的應用程序的代碼注入技術，其中惡意SQL語句被插入到一個入口點。
SVG - 可縮放矢量圖
Time-based OTP - 一種生成OTP的方法，其中當前時間作爲生成密碼的算法的一部分。
Threat Modeling - 一種由發展日益完善的安全架構組成的技術，以識別威脅因素、安全區域、安全控制以及重要的技術和業務資產
Transport Layer Security (TLS) – 在網絡連接上提供通信安全的加密協議。
Trusted Platform Module (TPM) - HSM的一種類型，通常連接到一個更大的硬件組件，如主板，並作爲該系統的 "信任根"。
Two-factor authentication (2FA) -這爲賬戶登錄增加了第二層認證。
Universal 2nd Factor (U2F) - FIDO專門爲允許USB或NFC安全密鑰作爲第二認證因子而制定的標準之一。
URI/URL/URL fragments –統一資源標識符是用於標識名稱或網絡資源的一串字符。統一資源定位符通常用作資源的參考。
Verifier – 根據OWASP ASVS要求審查申請的人或小組。
What You See Is What You Get (WYSIWYG) -一種豐富的內容編輯器，它顯示內容在渲染時的實際外觀，而不是顯示用於管理渲染的編碼。
X.509 Certificate – X.509證書是一種數字證書，它使用被廣泛接受的國際X.509公鑰基礎設施（PKI）標準來驗證公鑰是否屬於證書中包含的用戶、計算機或服務身份。
XML eXternal Entity (XXE) -一種可以通過聲明的系統標識符訪問本地或遠程內容的XML實體類型。這可能加載到各種注入攻擊

附錄 B：參考文獻

以下OWASP項目最有可能對本標準的用戶/採用者有用:

OWASP 核心項目

OWASP Top 10 項目: https://owasp.org/www-project-top-ten/
OWASP Web安全測試指南: https://owasp.org/www-project-web-security-testing-guide/
OWASP 主動控制: https://owasp.org/www-project-proactive-controls/
OWASP 安全知識框架: https://owasp.org/www-project-security-knowledge-framework/
OWASP 軟件保障成熟度模型(SAMM): https://owasp.org/www-project-samm/

OWASP Cheat Sheet 系列項目

此項目有許多備忘單，這些備忘單與 ASVS 中的不同主題相關。

有一個與ASVS的映射，可以在這裏找到。 https://cheatsheetseries.owasp.org/cheatsheets/IndexASVS.html

移動安全相關項目

OWASP 移動安全項目: https://owasp.org/www-project-mobile-security/
OWASP 移動安全十大風險: https://owasp.org/www-project-mobile-top-10/
OWASP 移動安全測試指南和移動應用程序安全驗證標準: https://owasp.org/www-project-mobile-security-testing-guide/

OWASP 物聯網相關項目

OWASP 物聯網項目: https://owasp.org/www-project-internet-of-things/

OWASP 無服務器項目

OWASP 無服務器項目: https://owasp.org/www-project-serverless-top-10/

其他

同樣，以下網站最有可能對本標準的用戶/採用者有用

安全列表 Github: https://github.com/danielmiessler/SecLists
MITRE常見弱點枚舉: https://cwe.mitre.org/
PCI 安全標準理事會: https://www.pcisecuritystandards.org
PCI 數據安全標準（DSS） v3.2.1 要求和安全評估程序: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
PCI 軟件安全框架 - 安全軟件要求和評估程序: https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf
PCI 安全軟件生命週期（安全 SLC）要求和評估程序: https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf

附錄 C：物聯網驗證要求

本節最初在主分支中，但隨着 OWASP IoT 團隊完成的工作，維護有關主題的兩個不同的線程沒有意義。對於 4.0 版本，我們將此版本移動到附錄中，並敦促所有需要此版本的人使用主 OWASP IoT 項目

控制目標

嵌入式/IoT 設備應當:

通過在受信任的環境中強制實施安全控制，在設備內具有與服務器中的相同級別的安全控制.
存儲在設備上的敏感數據應使用硬件支持的存儲方式（如安全元素）以安全的方式進行。
所有從設備傳輸的敏感數據都應保證傳輸層安全。.

安全驗證要求

#	描述	L1	L2	L3	Since
C.1	驗證應用程序層調試接口（如 USB、UART 和其他串行變體）是否被禁用或受複雜密碼保護。	✓	✓	✓	4.0
C.2	驗證加密密鑰和證書是否對每個設備都是唯一的。	✓	✓	✓	4.0
C.3	驗證嵌入式/IoT 操作系統（如果適用）是否啓用了內存保護控制（如 ASLR 和 DEP）。	✓	✓	✓	4.0
C.4	驗證芯片上調試接口（如 JTAG 或 SWD）是否已禁用，或者是否已正確啓用和配置可用的保護機制。	✓	✓	✓	4.0
C.5	如果在設備SoC或CPU上可用，請驗證是否實施並啓用了可信執行。	✓	✓	✓	4.0
C.6	驗證敏感數據、私鑰和證書是否安全地存儲在安全元素、TPM、TEE（可信執行環境）中，或使用強加密進行保護。	✓	✓	✓	4.0
C.7	驗證固件應用是否使用傳輸層安全性保護傳輸中的數據。	✓	✓	✓	4.0
C.8	驗證固件應用是否驗證服務器連接的數字簽名。	✓	✓	✓	4.0
C.9	驗證無線通信是否相互驗證。	✓	✓	✓	4.0
C.10	驗證無線通信是否通過加密通道發送。	✓	✓	✓	4.0
C.11	驗證對禁止的 C 函數的任何使用是否替換爲適當的安全等效函數。	✓	✓	✓	4.0
C.12	確認每個固件都有一個軟件材料清單，對第三方組件、版本和已發佈的漏洞進行編目	✓	✓	✓	4.0
C.13	驗證所有代碼（包括第三方二進制文件、庫、框架）是否經過硬編碼憑據（後門）。	✓	✓	✓	4.0
C.14	通過調用 shell 命令解釋器、腳本或安全控制阻止 OS 命令注入，驗證應用程序和固件組件是否易受操作系統命令注入的影響。	✓	✓	✓	4.0
C.15	驗證固件應用是否將數字簽名固定到受信任的服務器。		✓	✓	4.0
C.16	驗證是否存在防篡改和/或篡改檢測功能。		✓	✓	4.0
C.17	驗證芯片製造商提供的任何可用的知識產權保護技術是否已啓用。		✓	✓	4.0
C.18	驗證安全控制是否到位，以阻礙固件逆向工程（例如，刪除冗長的調試符號）。		✓	✓	4.0
C.19	在加載之前驗證設備驗證引導映像簽名。		✓	✓	4.0
C.20	驗證固件更新過程是否容易受到檢查時間與使用時間攻擊的影響。		✓	✓	4.0
C.21	在安裝之前，驗證設備使用代碼簽名並驗證固件升級文件。		✓	✓	4.0
C.22	驗證設備是否無法降級到有效固件的舊版本（反回滾）。		✓	✓	4.0
C.23	驗證嵌入式設備上加密安全的僞隨機數生成器的使用（例如，使用芯片提供的隨機數生成器）。		✓	✓	4.0
C.24	驗證固件能否根據預定義計劃執行自動固件更新。		✓	✓	4.0
C.25	在檢測到篡改或收到無效消息時，驗證設備是否擦除固件和敏感數據。			✓	4.0
C.26	驗證是否僅使用支持禁用調試接口的微型控制器（例如 JTAG、SWD）。			✓	4.0
C.27	驗證是否僅使用提供大量保護的微型控制器，防止除封蓋和側通道攻擊。			✓	4.0
C.28	驗證敏感軌跡是否未暴露在印刷電路板的外層。			✓	4.0
C.29	驗證芯片間通信是否加密（例如主板到子板通信）。			✓	4.0
C.30	驗證設備使用代碼簽名並在執行前驗證代碼。			✓	4.0
C.31	驗證內存中維護的敏感信息在不再需要時是否被零覆蓋。			✓	4.0
C.32	驗證固件應用是否利用內核容器在應用之間進行隔離。			✓	4.0
C.33	驗證安全編譯器標誌，如-fPIE、-fstack-protector-all、-Wl,-z,noexecstack、-Wl,-z,noexecheap是否爲固件構建配置			✓	4.0
C.34	驗證微型控制器是否配置了代碼保護（如果適用）。			✓	4.0

參考文獻

有關詳細信息，請參閱:

程序安全開發規範--（應用程序安全驗證標準）

應用程序安全驗證標準 4.0.2

甘道夫 譯

正面

關於標準

版權和許可

項目負責人

主要貢獻者

其他貢獻者和審閱者

前言

4.0中的新內容

使用 ASVS

應用程序安全驗證級別

如何使用此標準

Level 1 – 最低限度

Level 2 - 大多數應用程序

Level 3 - 高價值、高保證或高安全性

在實踐中應用 ASVS

如何參考 ASVS 要求

評估和認證

OWASP 對 ASVS 認證和信任標誌的立場

認證組織指南

測試方法

自動安全測試工具的作用

滲透測試的作用

ASVS 的其他用途

作爲詳細的安全架構指南

作爲現成的安全編碼清單的替代品

作爲自動化單元和集成測試指南

用於安全開發培訓

作爲敏捷應用程序安全性的驅動程序

作爲指導安全軟件採購的框架

V1：架構、設計和威脅建模要求

控制目標

V1.2 身份驗證體系結構要求

V1.3 會話管理體系結構要求

V1.5 輸入和輸出架構要求

V1.6 加密體系結構要求

V1.7 錯誤、日誌記錄和審覈體系結構要求

V1.8 數據保護和隱私體系結構要求

V1.9 通信體系結構要求

V1.10 惡意軟件體系結構要求

V1.11 業務邏輯架構要求

V1.12 安全文件上傳體系結構要求

V1.13 API 架構要求

參考文獻

V2：身份驗證驗證要求

控制目標

NIST 800-63 - 現代的循證認證標準

選擇適當的 NIST AAL 級別

V2.1 密碼安全要求

V2.2 一般身份驗證器要求

V2.3 身份驗證器生命週期要求

V2.4 憑據存儲要求

V2.6 查找祕密驗證人要求

V2.7 帶外驗證器要求

V2.8 單因素或多因素一次驗證器要求

V2.9 加密軟件和設備驗證程序要求

V2.10 服務身份驗證要求

參考文獻

V3: 會話管理驗證要求

控制目標

安全驗證要求

V3.3 會話註銷和超時要求

V3.4 基於 Cookie 的會話管理

V3.5 基於令牌的會話管理

V3.6 重新認證聯合身份驗證或斷言

V3.7 防禦會話管理漏洞

半開攻擊的描述

參考文獻

V4：訪問控制驗證要求

控制目標

安全驗證要求

V4.1 通用訪問控制設計

V4.2 操作級訪問控制

V4.3 其他訪問控制注意事項

參考文獻

V5：編碼驗證要求

控制目標

V5.1 輸入驗證要求

甘道夫譯