A01:2021 – 失效的訪問控制 概述
從第五位上升，94% 的應用程序都經過了某種形式的訪問控制損壞測試。值得注意的CWE包括CWE-200：將敏感信息暴露給未經授權的參與者、CWE-201：通過發送的數據暴露敏感信息和CWE-352：跨站點請求僞造。
失效的訪問控制 - 描述
訪問控制強制執行策略，使用戶不能在其預期權限之外採取行動。故障通常會導致未經授權的信息泄露、修改或破壞所有數據或執行超出用戶限制的業務功能。常見的訪問控制漏洞包括：
通過修改 URL、內部應用程序狀態或 HTML 頁面，或僅使用自定義 API 攻擊工具來繞過訪問控制檢查。
允許將主鍵更改爲其他用戶的記錄，允許查看或編輯其他人的帳戶。
特權提升。在未登錄的情況下充當用戶或以用戶身份登錄時充當管理員。
元數據操作，例如重放或篡改 JSON Web 令牌 (JWT) 訪問控制令牌，或用於提升權限或濫用 JWT 失效的 cookie 或隱藏字段。
CORS 錯誤配置允許未經授權的 API 訪問。
強制以未經身份驗證的用戶身份瀏覽經過身份驗證的頁面或以標準用戶身份瀏覽特權頁面。訪問 API 時缺少對 POST、PUT 和 DELETE 的訪問控制。
失效的訪問控制 - 如何預防
訪問控制僅在受信任的服務器端代碼或無服務器 API 中有效，攻擊者無法修改訪問控制檢查或元數據。
除公共資源外，默認拒絕。
實施一次訪問控制機制並在整個應用程序中重複使用它們，包括最大限度地減少 CORS 的使用。
模型訪問控制應該強制記錄所有權，而不是接受用戶可以創建、讀取、更新或刪除任何記錄。
獨特的應用程序業務限制要求應由領域模型強制執行。
禁用 Web 服務器目錄列表並確保文件元數據（例如 .git）和備份文件不在 Web 根目錄中。
記錄訪問控制失敗，在適當時提醒管理員（例如，重複失敗）。
速率限制 API 和控制器訪問，以最大限度地減少自動攻擊工具的危害。
註銷後，JWT 令牌應在服務器上失效。
失效的訪問控制 - 攻擊場景示例
場景 #1：應用程序在訪問帳戶信息的 SQL 調用中使用未經驗證的數據：
pstmt.setString(1, request.getParameter("acct"));
結果集結果 = pstmt.executeQuery();
攻擊者只需修改瀏覽器的“acct”參數即可發送他們想要的任何帳號。如果沒有正確驗證，攻擊者可以訪問任何用戶的帳戶。
https://example.com/app/accountInfo?acct=notmyacct
場景#2：攻擊者只是強制瀏覽到目標 URL。訪問管理頁面需要管理員權限。
如果未經身份驗證的用戶可以訪問任一頁面，則這是一個缺陷。如果非管理員可以訪問管理頁面，這是一個缺陷。
A02:2021 – 加密失敗 概述
上移一個位置到#2，以前稱爲敏感數據暴露，這更像是一個廣泛的症狀而不是根本原因，重點是與密碼學相關的失敗（或缺乏密碼學）。這往往會導致敏感數據的暴露。值得注意的CWE包括CWE-259：使用硬編碼密碼、CWE-327：損壞或風險的加密算法和CWE-331 熵不足。
加密失敗 - 描述
首先是確定傳輸中和靜止數據的保護需求。例如，密碼、信用卡號、健康記錄、個人信息和商業祕密需要額外保護，主要是如果該數據屬於隱私法（例如歐盟的通用數據保護條例 (GDPR)）或法規（例如金融數據保護）例如 PCI 數據安全標準 (PCI DSS)。對於所有此類數據：
是否有任何數據以明文形式傳輸？這涉及 HTTP、SMTP 和 FTP 等協議。外部互聯網流量是危險的。驗證所有內部流量，例如，負載平衡器、Web 服務器或後端系統之間的流量。
默認情況下或在較舊的代碼中是否使用任何舊的或弱的加密算法？
是否正在使用默認加密密鑰、生成或重複使用弱加密密鑰，或者是否缺少適當的密鑰管理或輪換？
是否未強制執行加密，例如，是否缺少任何用戶代理（瀏覽器）安全指令或標頭？
用戶代理（例如，應用程序、郵件客戶端）是否不驗證收到的服務器證書是否有效？
加密失敗 - 如何預防
至少執行以下操作，並查閱參考資料：
對應用程序處理、存儲或傳輸的數據進行分類。根據隱私法、監管要求或業務需求確定哪些數據是敏感的。
根據分類應用控制。
不要不必要地存儲敏感數據。儘快丟棄它或使用符合 PCI DSS 的標記化甚至截斷。未保留的數據不能被竊取。
確保加密所有靜態敏感數據。
確保擁有最新且強大的標準算法、協議和密鑰；使用適當的密鑰管理。
使用安全協議（例如具有完美前向保密 (PFS) 密碼的 TLS、服務器的密碼優先級和安全參數）加密所有傳輸中的數據。使用 HTTP 嚴格傳輸安全 (HSTS) 等指令強制加密。
對包含敏感數據的響應禁用緩存。
使用具有工作因子（延遲因子）的強自適應和加鹽散列函數存儲密碼，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
獨立驗證配置和設置的有效性。
加密失敗 - 攻擊場景示例
場景#1：應用程序使用自動數據庫加密對數據庫中的信用卡號進行加密。但是，此數據在檢索時會自動解密，從而允許 SQL 注入缺陷以明文形式檢索信用卡號。
場景#2：站點不使用或對所有頁面強制執行 TLS 或支持弱加密。攻擊者監視網絡流量（例如，在不安全的無線網絡中），將連接從 HTTPS 降級爲 HTTP，攔截請求並竊取用戶的會話 cookie。然後攻擊者重放這個 cookie 並劫持用戶的（經過身份驗證的）會話，訪問或修改用戶的私人數據。除了上述之外，他們還可以更改所有傳輸的數據，例如，匯款的接收者。
場景#3：密碼數據庫使用未加鹽或簡單的哈希來存儲每個人的密碼。文件上傳缺陷允許攻擊者檢索密碼數據庫。所有未加鹽的哈希值都可以通過預先計算的哈希值彩虹表公開。由簡單或快速散列函數生成的散列可能會被 GPU 破解，即使它們被加鹽。
A03:2021 – 注入 概述
注射向下滑動到第三個位置。94% 的應用程序都針對某種形式的注入進行了測試。值得注意的CWE包括 CWE-79：跨站點腳本、CWE-89：SQL 注入和CWE-73：文件名或路徑的外部控制。
注入 - 描述
應用程序在以下情況下容易受到攻擊：
應用程序不會驗證、過濾或清理用戶提供的數據。
沒有上下文感知轉義的動態查詢或非參數化調用直接在解釋器中使用。
在對象關係映射 (ORM) 搜索參數中使用惡意數據來提取額外的敏感記錄。
直接使用或連接惡意數據。SQL 或命令包含動態查詢、命令或存儲過程中的結構和惡意數據。
一些更常見的注入是 SQL、NoSQL、OS 命令、對象關係映射 (ORM)、LDAP 和表達式語言 (EL) 或對象圖導航庫 (OGNL) 注入。這個概念在所有口譯員中都是相同的。源代碼審查是檢測應用程序是否容易受到注入攻擊的最佳方法。強烈建議對所有參數、標頭、URL、cookie、JSON、SOAP 和 XML 數據輸入進行自動化測試。組織可以將靜態源 (SAST) 和動態應用程序測試 (DAST) 工具包含到 CI/CD 管道中，以在生產部署之前識別引入的注入缺陷。
注入 - 如何預防
防止注入需要將數據與命令和查詢分開。
首選選項是使用安全的 API，它完全避免使用解釋器，提供參數化接口，或遷移到對象關係映射工具 (ORM)。
注意：即使在參數化時，如果 PL/SQL 或 T-SQL 連接查詢和數據或使用 EXECUTE IMMEDIATE 或 exec() 執行惡意數據，則存儲過程仍然會引入 SQL 注入。
使用正面或“白名單”服務器端輸入驗證。這不是一個完整的防禦，因爲許多應用程序需要特殊字符，例如文本區域或移動應用程序的 API。
對於任何殘留的動態查詢，使用該解釋器的特定轉義語法轉義特殊字符。
注意：表名、列名等 SQL 結構不能轉義，因此用戶提供的結構名是危險的。這是報告編寫軟件中的常見問題。
在查詢中使用 LIMIT 和其他 SQL 控件以防止在 SQL 注入的情況下大量披露記錄。
注入 - 攻擊場景示例
場景 #1：應用程序在構建以下易受攻擊的 SQL 調用時使用不受信任的數據：
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
場景#2：類似地，應用程序對框架的盲目信任可能會導致查詢仍然存在漏洞（例如，Hibernate 查詢語言 (HQL)）：
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
在這兩種情況下，攻擊者都會修改瀏覽器中的 'id' 參數值以發送：' 或 '1'='1。例如：
http://example.com/app/accountView?id=' 或 '1'='1
這將更改兩個查詢的含義以返回帳戶表中的所有記錄。更危險的攻擊可能會修改或刪除數據，甚至調用存儲過程。
A04:2021 – 不安全的設計 概述
2021 年的新類別側重於與設計和架構缺陷相關的風險，並呼籲更多地使用威脅建模、安全設計模式和參考架構。值得注意的CWE包括 CWE-209：生成包含敏感信息的錯誤消息、 CWE-256：未受保護的憑證存儲、CWE-501：信任邊界違規和CWE-522：受保護的憑證不足。
不安全的設計 - 描述
不安全設計是一個廣泛的類別，代表許多不同的弱點，表現爲“缺失或無效的控制設計”。缺少不安全的設計是缺少控制的地方。例如，想象一下應該加密敏感數據的代碼，但沒有方法。無效的不安全設計是可以實現威脅的地方，但域（業務）邏輯驗證不足會阻止該操作。例如，假設域邏輯應該根據收入等級處理流行病稅收減免，但不驗證所有輸入都已正確簽名並提供比應授予的更重要的減免收益。
安全設計是一種文化和方法，它不斷評估威脅並確保代碼經過穩健設計和測試，以防止已知的攻擊方法。安全設計需要安全的開發生命週期、某種形式的安全設計模式或鋪砌道路組件庫或工具，以及威脅建模。
不安全的設計 - 如何預防
與 AppSec 專業人員建立並使用安全的開發生命週期，以幫助評估和設計與安全和隱私相關的控制
建立和使用安全設計模式庫或準備使用組件的鋪好的道路
將威脅建模用於關鍵身份驗證、訪問控制、業務邏輯和關鍵流
編寫單元和集成測試以驗證所有關鍵流都能抵抗威脅模型
不安全的設計 - 攻擊場景示例
場景 #1：憑證恢復工作流程可能包括“問答”，這是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。不能將問答作爲多個人身份的證據可以知道答案，這就是爲什麼它們被禁止。此類代碼應刪除並替換爲更安全的設計。
場景#2：連鎖影院允許團體預訂折扣，並且在要求押金之前最多有 15 名參與者。攻擊者可以對該流程進行威脅建模，並測試他們是否可以在幾次請求中一次預訂 600 個座位和所有電影院，從而造成巨大的收入損失。
場景 #3：零售連鎖店的電子商務網站沒有針對由黃牛運行的機器人提供保護，這些機器人購買高端顯卡以轉售拍賣網站。這對視頻卡製造商和零售連鎖店主造成了可怕的宣傳，並與無法以任何價格獲得這些卡的愛好者之間產生了仇恨。仔細的反機器人設計和域邏輯規則，例如在可用性的幾秒鐘內進行的購買，可能會識別出不真實的購買並拒絕此類交易。
A05:2021 – 安全配置錯誤 概述
從上一版的第 6 位開始，90% 的應用程序都經過了某種形式的錯誤配置測試。隨着更多轉向高度可配置的軟件，看到這一類別上升也就不足爲奇了。值得注意的CWE包括CWE-16 Configuration和CWE-611 Improper Restriction of XML External Entity Reference。
安全配置錯誤 - 描述
如果應用程序是：
在應用程序堆棧的任何部分缺少適當的安全強化或對雲服務的權限配置不正確。
啓用或安裝了不必要的功能（例如，不必要的端口、服務、頁面、帳戶或權限）。
默認帳戶及其密碼仍處於啓用狀態且未更改。
錯誤處理向用戶顯示堆棧跟蹤或其他信息過多的錯誤消息。
對於升級的系統，最新的安全功能被禁用或未安全配置。
應用程序服務器、應用程序框架（例如，Struts、Spring、ASP.NET）、庫、數據庫等中的安全設置未設置爲安全值。
服務器不發送安全標頭或指令，或者它們未設置爲安全值。
軟件已過時或易受攻擊（請參閱 A06:2021-易受攻擊和過時的組件）。
如果沒有協調一致的、可重複的應用程序安全配置過程，系統將面臨更高的風險。
安全配置錯誤 - 如何預防
應實施安全安裝過程，包括：
可重複的強化過程使部署另一個適當鎖定的環境變得快速而輕鬆。開發、QA 和生產環境都應配置相同，在每個環境中使用不同的憑據。這個過程應該是自動化的，以最大限度地減少設置新安全環境所需的工作。
一個沒有任何不必要的功能、組件、文檔和示例的最小平臺。刪除或不安裝未使用的功能和框架。
作爲補丁管理流程的一部分，審查和更新適用於所有安全說明、更新和補丁的配置的任務（請參閱 A06:2021-易受攻擊和過時的組件）。查看雲存儲權限（例如，S3 存儲桶權限）。
分段應用程序架構通過分段、容器化或雲安全組 (ACL) 在組件或租戶之間提供有效且安全的分離。
向客戶端發送安全指令，例如安全標頭。
驗證配置和設置在所有環境中的有效性的自動化過程。
安全配置錯誤 - 攻擊場景示例
場景#1：應用程序服務器帶有未從生產服務器中刪除的示例應用程序。這些示例應用程序具有攻擊者用來破壞服務器的已知安全漏洞。假設這些應用程序之一是管理控制檯，並且默認帳戶未更改。在這種情況下，攻擊者使用默認密碼登錄並接管。
場景#2：服務器上沒有禁用目錄列表。攻擊者發現他們可以簡單地列出目錄。攻擊者找到並下載已編譯的 Java 類，對其進行反編譯和逆向工程以查看代碼。然後攻擊者發現應用程序中存在嚴重的訪問控制缺陷。
場景#3：應用服務器的配置允許將詳細的錯誤消息（例如堆棧跟蹤）返回給用戶。這可能會暴露敏感信息或潛在缺陷，例如已知易受攻擊的組件版本。
場景#4：雲服務提供商擁有其他 CSP 用戶對 Internet 開放的默認共享權限。這允許訪問存儲在雲存儲中的敏感數據。
A06:2021 – 易受攻擊和過時的組件 概述
它在行業調查中排名第二，但也有足夠的數據通過數據進入前 10 名。易受攻擊的組件是我們難以測試和評估風險的已知問題，並且是唯一沒有任何 CVE 映射到包含的 CWE 的類別，因此使用默認的漏洞利用/影響權重 5.0。值得注意的CWE包括CWE-1104：使用未維護的第三方組件和來自 2013 年和 2017 年前 10 名的兩個 CWE。
易受攻擊和過時的組件 - 描述
你可能很脆弱：
如果您不知道您使用的所有組件的版本（客戶端和服務器端）。這包括您直接使用的組件以及嵌套的依賴項。
如果軟件易受攻擊、不受支持或已過期。這包括操作系統、Web/應用程序服務器、數據庫管理系統 (DBMS)、應用程序、API 和所有組件、運行時環境和庫。
如果您不定期掃描漏洞並訂閱與您使用的組件相關的安全公告。
如果您沒有以基於風險的方式及時修復或升級底層平臺、框架和依賴項。這通常發生在修補是變更控制下的每月或每季度任務的環境中，使組織面臨數天或數月不必要地暴露於固定漏洞的風險。
如果軟件開發人員不測試更新、升級或修補的庫的兼容性。
如果您不保護組件的配置（請參閱 A05:2021-安全配置錯誤）。
易受攻擊和過時的組件 - 如何預防
應該有一個補丁管理流程來：
刪除未使用的依賴項、不必要的功能、組件、文件和文檔。
使用版本、OWASP Dependency Check、retire.js 等工具持續清點客戶端和服務器端組件（例如框架、庫）及其依賴項的版本。成分。使用軟件組合分析工具來自動化該過程。訂閱與您使用的組件相關的安全漏洞的電子郵件警報。
僅通過安全鏈接從官方來源獲取組件。首選簽名包以減少包含修改後的惡意組件的機會（請參閱 A08:2021-軟件和數據完整性故障）。
監視未維護或未爲舊版本創建安全補丁的庫和組件。如果無法打補丁，請考慮部署虛擬補丁來監控、檢測或防止發現的問題。
每個組織都必須確保在應用程序或產品組合的生命週期內製定持續的監控、分類和應用更新或配置更改的計劃。
易受攻擊和過時的組件 - 攻擊場景示例
場景#1：組件通常以與應用程序本身相同的權限運行，因此任何組件中的缺陷都可能導致嚴重影響。此類缺陷可能是偶然的（例如，編碼錯誤）或有意的（例如，組件中的後門）。發現的一些可利用組件漏洞的示例是：
CVE-2017-5638 是一個 Struts 2 遠程代碼執行漏洞，可以在服務器上執行任意代碼，已被歸咎於重大漏洞。
雖然物聯網 (IoT) 通常很難或不可能修補，但修補它們的重要性可能很大（例如，生物醫學設備）。
有一些自動化工具可以幫助攻擊者找到未打補丁或配置錯誤的系統。例如，Shodan IoT 搜索引擎可以幫助您找到仍然存在 2014 年 4 月修補的 Heartbleed 漏洞的設備。
A07:2021 – 認證和授權失敗 概述
以前稱爲Broken Authentication，此類別從第二位下滑，現在包括與識別失敗相關的 CWE。包括的值得注意的CWE包括CWE-297：不正確的證書驗證與主機不匹配、CWE-287：不正確的身份驗證和 CWE-384：會話固定。
認證和授權失敗 - 描述
確認用戶的身份、身份驗證和會話管理對於防止與身份驗證相關的攻擊至關重要。如果應用程序存在以下情況，則可能存在身份驗證漏洞：
允許自動攻擊，例如撞庫，其中攻擊者擁有有效用戶名和密碼的列表。
允許蠻力或其他自動攻擊。
允許使用默認密碼、弱密碼或衆所周知的密碼，例如“Password1”或“admin/admin”。
使用弱或無效的憑據恢復和忘記密碼流程，例如無法確保安全的“基於知識的答案”。
使用純文本、加密或弱散列密碼（請參閱 A3:2017-敏感數據暴露）。
缺少或無效的多因素身份驗證。
在 URL 中公開會話 ID（例如，URL 重寫）。
成功登錄後不要輪換會話 ID。
不會正確地使會話 ID 無效。用戶會話或身份驗證令牌（主要是單點登錄 (SSO) 令牌）在註銷或一段時間不活動期間未正確失效。
認證和授權失敗 - 如何預防
在可能的情況下，實施多因素身份驗證以防止自動憑證填充、暴力破解和被盜憑證重用攻擊。
不要使用任何默認憑據進行交付或部署，尤其是對於管理員用戶。
實施弱密碼檢查，例如針對前 10,000 個最差密碼列表測試新密碼或更改的密碼。
將密碼長度、複雜性和輪換策略與 NIST 800-63b 的第 5.1.1 節中關於記憶祕密的指南或其他現代的、基於證據的密碼策略保持一致。
通過對所有結果使用相同的消息，確保註冊、憑據恢復和 API 路徑能夠抵禦帳戶枚舉攻擊。
限制或增加延遲失敗的登錄嘗試。當檢測到憑證填充、暴力破解或其他攻擊時，記錄所有故障並提醒管理員。
使用服務器端、安全、內置的會話管理器，在登錄後生成新的高熵隨機會話 ID。會話 ID 不應在 URL 中，安全存儲，並在註銷、空閒和絕對超時後失效。
認證和授權失敗 - 攻擊場景示例
場景#1：憑證填充（使用已知密碼列表）是一種常見的攻擊。假設應用程序沒有實施自動化威脅或憑證填充保護。在這種情況下，應用程序可以用作密碼預言機來確定憑證是否有效。
場景#2：大多數身份驗證攻擊是由於繼續使用密碼作爲唯一因素而發生的。一經考慮，最佳實踐、密碼輪換和複雜性要求會鼓勵用戶使用和重複使用弱密碼。建議組織按照 NIST 800-63 停止這些做法並使用多因素身份驗證。
場景 #3：應用程序會話超時設置不正確。用戶使用公共計算機訪問應用程序。用戶沒有選擇“註銷”，而是簡單地關閉瀏覽器選項卡並走開。攻擊者在一個小時後使用同一個瀏覽器，而用戶仍然通過身份驗證。
A08:2021 – 軟件和數據完整性故障 概述
2021 年的新類別側重於在不驗證完整性的情況下做出與軟件更新、關鍵數據和 CI/CD 管道相關的假設。來自 CVE/CVSS 數據的最高加權影響之一。著名的CWE包括CWE-502：不可信數據的反序列化、 CWE-829：包含不受信任的控制領域的功能和 CWE-494：下載沒有完整性檢查的代碼。
軟件和數據完整性故障 - 描述
軟件和數據完整性故障與不能防止完整性違規的代碼和基礎設施有關。例如，在對象或數據被編碼或序列化爲攻擊者可以看到和修改的結構的情況下，很容易受到不安全的反序列化的影響。另一種形式是應用程序依賴來自不受信任的來源、存儲庫和內容交付網絡 (CDN) 的插件、庫或模塊。不安全的 CI/CD 管道可能會導致未經授權的訪問、惡意代碼或系統受損。最後，許多應用程序現在包括自動更新功能，其中更新在沒有充分完整性驗證的情況下被下載並應用於以前受信任的應用程序。攻擊者可能會上傳自己的更新以分發並在所有安裝上運行。
軟件和數據完整性故障 - 如何預防
確保未簽名或未加密的序列化數據不會在沒有某種形式的完整性檢查或數字簽名的情況下發送到不受信任的客戶端，以檢測序列化數據的篡改或重放
通過簽名或類似機制驗證軟件或數據來自預期來源
確保庫和依賴項（例如 npm 或 Maven）使用受信任的存儲庫
確保使用軟件供應鏈安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）來驗證組件不包含已知漏洞
確保您的 CI/CD 管道具有正確的配置和訪問控制，以確保流經構建和部署過程的代碼的完整性。
軟件和數據完整性故障 - 攻擊場景示例
場景 #1 不安全的反序列化： React 應用程序調用一組 Spring Boot 微服務。作爲函數式程序員，他們試圖確保他們的代碼是不可變的。他們提出的解決方案是序列化用戶狀態並在每個請求中來回傳遞它。攻擊者注意到“R00”Java 對象簽名並使用 Java Serial Killer 工具在應用服務器上獲取遠程代碼執行權。
場景 #2 無需簽名即可更新：許多家用路由器、機頂盒、設備固件和其他固件不通過簽名固件驗證更新。未簽名固件是攻擊者越來越多的目標，預計只會變得更糟。這是一個主要問題，因爲很多時候除了在未來版本中修復並等待以前的版本過時之外，沒有任何補救機制。
場景#3 SolarWinds 惡意更新：衆所周知，國家會攻擊更新機制，最近的一次著名攻擊是 SolarWinds Orion 攻擊。開發該軟件的公司擁有安全的構建和更新完整性流程。儘管如此，這些還是能夠被破壞，並且在幾個月的時間裏，該公司向 18,000 多個組織分發了一個高度針對性的惡意更新，其中大約 100 個組織受到了影響。這是歷史上此類性質最深遠、最重大的違規行爲之一。
A09:2021 – 安全日誌記錄和監控失敗 概述
安全日誌記錄和監控來自行業調查（#3），比 2017 年 OWASP 前 10 名中的第十位略有上升。日誌記錄和監控可能很難測試，通常涉及採訪或詢問是否在滲透測試期間檢測到攻擊。此類別的 CVE/CVSS 數據不多，但檢測和響應漏洞至關重要。儘管如此，它對於可見性、事件警報和取證仍然非常有影響力。此類別擴展到CWE-778 日誌記錄不足之外，包括CWE-117 日誌的不當輸出中和、CWE-223 安全相關信息的遺漏和 CWE-532 將敏感信息插入日誌文件。
安全日誌記錄和監控失敗 - 描述
回到 2021 年 OWASP 前 10 名，該類別旨在幫助檢測、升級和響應主動違規行爲。如果沒有日誌記錄和監控，就無法檢測到漏洞。任何時候都會發生日誌記錄、檢測、監控和主動響應不足的情況：
不記錄可審計的事件，例如登錄、失敗登錄和高價值交易。
警告和錯誤不會生成、不充分或不清楚的日誌消息。
不會監控應用程序和 API 的日誌是否存在可疑活動。
日誌僅存儲在本地。
適當的警報閾值和響應升級流程沒有到位或有效。
DAST 工具（例如 OWASP ZAP）的滲透測試和掃描不會觸發警報。
應用程序無法實時或接近實時地檢測、升級或警告主動攻擊。
通過使用戶或攻擊者可以看到日誌記錄和警報事件，您很容易受到信息泄漏的影響（請參閱 A01:2021 – 損壞的訪問控制）。
安全日誌記錄和監控失敗 - 如何預防
開發人員應實施以下部分或全部控制措施，具體取決於應用程序的風險：
確保所有登錄、訪問控制和服務器端輸入驗證失敗都可以用足夠的用戶上下文來記錄，以識別可疑或惡意帳戶，並保留足夠的時間以允許延遲取證分析。
確保以日誌管理解決方案可以輕鬆使用的格式生成日誌。
確保日誌數據編碼正確，以防止對日誌或監控系統的注入或攻擊。
確保高價值交易具有帶有完整性控制的審計跟蹤，以防止篡改或刪除，例如僅追加數據庫表或類似的。
DevSecOps 團隊應該建立有效的監控和警報，以便快速檢測和響應可疑活動。
制定或採用事件響應和恢復計劃，例如 NIST 800-61r2 或更高版本。
有商業和開源應用程序保護框架（例如 OWASP ModSecurity 核心規則集）和開源日誌關聯軟件（例如 ELK 堆棧）具有自定義儀表板和警報功能。
安全日誌記錄和監控失敗 - 攻擊場景示例
場景#1：由於缺乏監控和日誌記錄，一家兒童健康計劃提供商的網站運營商無法檢測到違規行爲。外部方通知健康計劃提供者，攻擊者訪問並修改了超過 350 萬兒童的數千份敏感健康記錄。事後審查發現網站開發人員沒有解決重大漏洞。由於沒有對系統進行日誌記錄或監控，數據泄露可能自 2013 年以來一直在進行，時間超過七年。
場景#2：印度一家大型航空公司發生數據泄露事件，涉及數百萬乘客超過十年的個人數據，包括護照和信用卡數據。數據泄露發生在第三方雲託管服務提供商處，該提供商在一段時間後將泄露事件通知了航空公司。
場景 #3：一家主要的歐洲航空公司遭遇了 GDPR 可報告的違規行爲。據報道，該漏洞是由攻擊者利用的支付應用程序安全漏洞引起的，他們收集了超過 400,000 條客戶支付記錄。該航空公司因此被隱私監管機構罰款 2000 萬英鎊。
A10:2021 – 服務器端請求僞造 (SSRF) 概述
此類別是從行業調查 (#1) 中添加的。數據顯示發生率相對較低，測試覆蓋率高於平均水平，利用和影響潛力評級高於平均水平。由於新條目可能是用於關注和意識的單個或一小部分 CWE，因此希望它們受到關注，並且可以在未來版本中納入更大的類別。
服務器端請求僞造 (SSRF) - 描述
每當 Web 應用程序在未驗證用戶提供的 URL 的情況下獲取遠程資源時，就會出現 SSRF 缺陷。它允許攻擊者強制應用程序將精心設計的請求發送到意外目的地，即使受到防火牆、VPN 或其他類型的網絡 ACL 的保護也是如此。
隨着現代 Web 應用程序爲最終用戶提供方便的功能，獲取 URL 成爲一種常見情況。因此，SSRF 的發病率正在增加。此外，由於雲服務和架構的複雜性，SSRF 的嚴重性越來越高。
服務器端請求僞造 (SSRF) - 如何預防
開發人員可以通過實施以下部分或全部深度防禦控制來防止 SSRF：
服務器端請求僞造 (SSRF) - 從網絡層
在單獨的網絡中分段遠程資源訪問功能以減少 SSRF 的影響
強制執行“默認拒絕”防火牆策略或網絡訪問控制規則，以阻止除基本 Intranet 流量之外的所有流量
服務器端請求僞造 (SSRF) - 從應用層：
清理和驗證所有客戶端提供的輸入數據
使用肯定的允許列表強制執行 URL 架構、端口和目標
不要向客戶端發送原始響應
禁用 HTTP 重定向
注意 URL 一致性，以避免 DNS 重新綁定和“檢查時間、使用時間”(TOCTOU) 競爭條件等攻擊
不要通過使用拒絕列表或正則表達式來緩解 SSRF。攻擊者擁有有效負載列表、工具和技能來繞過拒絕列表。
服務器端請求僞造 (SSRF) - 攻擊場景示例
攻擊者可以使用 SSRF 攻擊受 Web 應用程序防火牆、防火牆或網絡 ACL 保護的系統，使用的場景包括：
場景#1：端口掃描內部服務器。如果網絡架構是未分段的，攻擊者可以繪製內部網絡，並根據連接結果或連接或拒絕 SSRF 負載連接所用的時間來確定內部服務器上的端口是打開還是關閉。
場景#2：敏感數據暴露。攻擊者可以訪問本地文件，例如 或內部服務以獲取敏感信息。
場景#3：訪問雲服務的元數據存儲。大多數雲提供商都有元數據存儲，例如http://169.254.169.254/。攻擊者可以讀取元數據來獲取敏感信息。
場景#4：破壞內部服務——攻擊者可以濫用內部服務進行進一步的攻擊，例如遠程代碼執行 (RCE) 或拒絕服務 (DoS)。