OWASP2021 Top10

OWASP Top 10 是 “Web 應用程序十大安全風險列表” ，總結了 Web 應用程序最可能、最常見、最危險的十大漏洞，是開發、測試、服務、咨詢人員應知應會的知識。

2021 年前十名變化

今年的榜單有三個新類別，相比 2017 版四個類別的命名和范圍發生了變化，並在 2021 年榜單中進行了一些類別合並。

A01:2021-Broken Access Control 從第五位上升；94% 的應用程序都經過了某種形式的破壞訪問控制的測試。映射到 Broken Access Control 的 34 個 CWE 在應用程序中出現的次數比任何其他類別都多。

A02:2021-Cryptographic Failures 上移一位至 #2，以前稱為敏感數據暴露，這是廣泛的症狀而不是根本原因。此處重新關注與密碼學相關的故障，這些故障通常會導致敏感數據暴露或系統受損。

A03:2021-Injection 下滑到第三位。94% 的應用程序都針對某種形式的注入進行了測試，映射到此類別的 33 個 CWE 在應用程序中出現次數第二多。跨站點腳本編寫現在是此版本中此類別的一部分。

A04:2021 - 不安全設計是 2021 年的一個新類別，重點關注與設計缺陷相關的風險。如果我們真的想作為一個行業 “向左移動”，就需要更多地使用威脅建模、安全設計模式和原則以及參考架構。

A05:2021 - 安全配置錯誤從上一版的第 6 位上升；90% 的應用程序都經過了某種形式的錯誤配置測試。隨着更多轉向高度可配置的軟件，看到這一類別上升也就不足為奇了。XML 外部實體 (XXE) 的前一個類別現在屬於此類別。

A06:2021-Vulnerable and Outdated Components 之前的標題是使用具有已知漏洞的組件，在行業調查中排名第二，但也有足夠的數據通過數據分析進入前 10 名。該類別從 2017 年的第 9 位上升，是我們難以測試和評估風險的已知問題。它是唯一沒有任何 CVE 映射到包含的 CWE 的類別，因此默認的利用和影響權重 5.0 被計入他們的分數。

A07:2021-Identification and Authentication Failures 以前是 Broken Authentication 並且從第二位下滑，現在包括與識別失敗更多相關的 CWE。這個類別仍然是前 10 名的一個組成部分，但標准化框架的可用性增加似乎有所幫助。

A08:2021 - 軟件和數據完整性故障是 2021 年的一個新類別，專注於在不驗證完整性的情況下做出與軟件更新、關鍵數據和 CI/CD 管道相關的假設。CVE/CVSS 數據的最高加權影響之一映射到此類別中的 10 個 CWE。2017 年的不安全反序列化現在是這一更大類別的一部分。

A09:2021 - 安全日志記錄和監控失敗以前是日志記錄和監控不足，是從行業調查 (#3) 中添加的，從之前的 #10 上升。此類別已擴展為包括更多類型的故障，難以測試，並且在 CVE/CVSS 數據中沒有得到很好的體現。但是，此類故障會直接影響可見性、事件警報和取證。

A10:2021-Server-Side Request Forgery 是從行業調查 (#1) 中添加的。數據顯示發生率相對較低，測試覆蓋率高於平均水平，並且利用和影響潛力的評級高於平均水平。此類別代表行業專業人士告訴我們這很重要的場景，即使目前數據中沒有說明。

OWASP Top 10 - 2021

A01:2021 - 損壞的訪問控制

描述

訪問控制強制執行策略，使用戶不能在其預期權限之外采取行動。故障通常會導致未經授權的信息泄露、修改或破壞所有數據或執行超出用戶限制的業務功能。常見的訪問控制漏洞包括：

• 通過修改 URL、內部應用程序狀態或 HTML 頁面，或僅使用自定義 API 攻擊工具來繞過訪問控制檢查。

• 允許將主鍵更改為其他用戶的記錄，允許查看或編輯其他人的帳戶。

• 特權提升。在未登錄的情況下充當用戶或以用戶身份登錄時充當管理員。

• 元數據操作，例如重放或篡改 JSON Web 令牌 (JWT) 訪問控制令牌，或用於提升權限或濫用 JWT 失效的 cookie 或隱藏字段。

• CORS 錯誤配置允許未經授權的 API 訪問。

• 強制以未經身份驗證的用戶身份瀏覽經過身份驗證的頁面或以標准用戶身份瀏覽特權頁面。訪問 API 時缺少對 POST、PUT 和 DELETE 的訪問控制。

如何預防

訪問控制僅在受信任的服務器端代碼或無服務器 API 中有效，攻擊者無法修改訪問控制檢查或元數據。

• 除公共資源外，默認拒絕。

• 實施一次訪問控制機制並在整個應用程序中重復使用它們，包括最大限度地減少 CORS 的使用。

• 模型訪問控制應該強制記錄所有權，而不是接受用戶可以創建、讀取、更新或刪除任何記錄。

• 獨特的應用程序業務限制要求應由領域模型強制執行。

• 禁用 Web 服務器目錄列表並確保文件元數據（例如 .git）和備份文件不在 Web 根目錄中。

• 記錄訪問控制失敗，在適當時提醒管理員（例如，重復失敗）。

• 速率限制 API 和控制器訪問，以最大限度地減少自動攻擊工具的危害。

• 注銷后，JWT 令牌應在服務器上失效。

開發人員和 QA 人員應包括功能訪問控制單元和集成測試。

A02:2021 - 加密失敗

描述

首先是確定傳輸中和靜止數據的保護需求。例如，密碼、信用卡號、健康記錄、個人信息和商業秘密需要額外保護，主要是如果該數據屬於隱私法（例如歐盟的通用數據保護條例 (GDPR)）或法規（例如金融數據保護）例如 PCI 數據安全標准 (PCI DSS)。對於所有此類數據：

• 是否有任何數據以明文形式傳輸？這涉及 HTTP、SMTP 和 FTP 等協議。外部互聯網流量是危險的。驗證所有內部流量，例如，負載平衡器、Web 服務器或后端系統之間的流量。

• 默認情況下或在較舊的代碼中是否使用任何舊的或弱的加密算法？

• 是否正在使用默認加密密鑰、生成或重復使用弱加密密鑰，或者是否缺少適當的密鑰管理或輪換？

• 是否未強制執行加密，例如，是否缺少任何用戶代理（瀏覽器）安全指令或標頭？

• 用戶代理（例如，應用程序、郵件客戶端）是否不驗證收到的服務器證書是否有效？

請參閱 ASVS 加密 (V7)、數據保護 (V9) 和 SSL/TLS (V10)

如何預防

至少執行以下操作，並查閱參考資料：

• 對應用程序處理、存儲或傳輸的數據進行分類。根據隱私法、監管要求或業務需求確定哪些數據是敏感的。

• 根據分類應用控制。

• 不要不必要地存儲敏感數據。盡快丟棄它或使用符合 PCI DSS 的標記化甚至截斷。未保留的數據不能被竊取。

• 確保加密所有靜態敏感數據。

• 確保擁有最新且強大的標准算法、協議和密鑰；使用適當的密鑰管理。

• 使用安全協議（例如具有完美前向保密 (PFS) 密碼的 TLS、服務器的密碼優先級和安全參數）加密所有傳輸中的數據。使用 HTTP 嚴格傳輸安全 (HSTS) 等指令強制加密。

• 對包含敏感數據的響應禁用緩存。

• 使用具有工作因子（延遲因子）的強自適應和加鹽散列函數存儲密碼，例如 Argon2、scrypt、bcrypt 或 PBKDF2。

• 獨立驗證配置和設置的有效性。

A03:2021 - 注入

描述

應用程序在以下情況下容易受到攻擊：

• 應用程序不會驗證、過濾或清理用戶提供的數據。

• 沒有上下文感知轉義的動態查詢或非參數化調用直接在解釋器中使用。

• 在對象關系映射 (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 注入的情況下大量披露記錄。

A04:2021 - 不安全的設計

描述

不安全設計是一個廣泛的類別，代表許多不同的弱點，表現為 “缺失或無效的控制設計”。缺少不安全的設計是缺少控制的地方。例如，想象一下應該加密敏感數據的代碼，但沒有方法。無效的不安全設計是可以實現威脅的地方，但域（業務）邏輯驗證不足會阻止該操作。例如，假設域邏輯應該根據收入等級處理流行病稅收減免，但不驗證所有輸入都已正確簽名並提供比應授予的更重要的減免收益。

安全設計是一種文化和方法，它不斷評估威脅並確保代碼經過穩健設計和測試，以防止已知的攻擊方法。安全設計需要安全的開發生命周期、某種形式的安全設計模式或鋪砌道路組件庫或工具，以及威脅建模。

如何預防

• 與 AppSec 專業人員建立並使用安全的開發生命周期，以幫助評估和設計與安全和隱私相關的控制

• 建立和使用安全設計模式庫或准備使用組件的鋪好的道路

• 將威脅建模用於關鍵身份驗證、訪問控制、業務邏輯和關鍵流

• 編寫單元和集成測試以驗證所有關鍵流都能抵抗威脅模型

A05:2021 - 安全配置錯誤

描述

如果應用程序是：

• 在應用程序堆棧的任何部分缺少適當的安全強化或對雲服務的權限配置不正確。

• 啟用或安裝了不必要的功能（例如，不必要的端口、服務、頁面、帳戶或權限）。

• 默認帳戶及其密碼仍處於啟用狀態且未更改。

• 錯誤處理向用戶顯示堆棧跟蹤或其他信息過多的錯誤消息。

• 對於升級的系統，最新的安全功能被禁用或未安全配置。

• 應用程序服務器、應用程序框架（例如，Struts、Spring、ASP.NET）、庫、數據庫等中的安全設置未設置為安全值。

• 服務器不發送安全標頭或指令，或者它們未設置為安全值。

• 軟件已過時或易受攻擊（請參閱 A06:2021 - 易受攻擊和過時的組件）。

如果沒有協調一致的、可重復的應用程序安全配置過程，系統將面臨更高的風險。

如何預防

應實施安全安裝過程，包括：

• 可重復的強化過程使部署另一個適當鎖定的環境變得快速而輕松。開發、QA 和生產環境都應配置相同，在每個環境中使用不同的憑據。這個過程應該是自動化的，以最大限度地減少設置新安全環境所需的工作。

• 一個沒有任何不必要的功能、組件、文檔和示例的最小平台。刪除或不安裝未使用的功能和框架。

• 作為補丁管理流程的一部分，審查和更新適用於所有安全說明、更新和補丁的配置的任務（請參閱 A06:2021 - 易受攻擊和過時的組件）。查看雲存儲權限（例如，S3 存儲桶權限）。

• 分段應用程序架構通過分段、容器化或雲安全組 (ACL) 在組件或租戶之間提供有效且安全的分離。

• 向客戶端發送安全指令，例如安全標頭。

• 驗證配置和設置在所有環境中的有效性的自動化過程。

A06:2021 - 易受攻擊和過時的組件

描述

你可能很脆弱：

• 如果您不知道您使用的所有組件的版本（客戶端和服務器端）。這包括您直接使用的組件以及嵌套的依賴項。

• 如果軟件易受攻擊、不受支持或已過期。這包括操作系統、Web / 應用程序服務器、數據庫管理系統 (DBMS)、應用程序、API 和所有組件、運行時環境和庫。

• 如果您不定期掃描漏洞並訂閱與您使用的組件相關的安全公告。

• 如果您沒有以基於風險的方式及時修復或升級底層平台、框架和依賴項。這通常發生在修補是變更控制下的每月或每季度任務的環境中，使組織面臨數天或數月不必要地暴露於固定漏洞的風險。

• 如果軟件開發人員不測試更新、升級或修補的庫的兼容性。

• 如果您不保護組件的配置（請參閱 A05:2021 - 安全配置錯誤）。

如何預防

應該有一個補丁管理流程來：

• 刪除未使用的依賴項、不必要的功能、組件、文件和文檔。

• 使用版本、OWASP Dependency Check、retire.js 等工具持續清點客戶端和服務器端組件（例如框架、庫）及其依賴項的版本。成分。使用軟件組合分析工具來自動化該過程。訂閱與您使用的組件相關的安全漏洞的電子郵件警報。

• 僅通過安全鏈接從官方來源獲取組件。首選簽名包以減少包含修改后的惡意組件的機會（請參閱 A08:2021 - 軟件和數據完整性故障）。

• 監視未維護或未為舊版本創建安全補丁的庫和組件。如果無法打補丁，請考慮部署虛擬補丁來監控、檢測或防止發現的問題。

每個組織都必須確保在應用程序或產品組合的生命周期內制定持續的監控、分類和應用更新或配置更改的計划。

A07:2021 - 身份驗證失敗

描述

確認用戶的身份、身份驗證和會話管理對於防止與身份驗證相關的攻擊至關重要。如果應用程序存在以下情況，則可能存在身份驗證漏洞：

• 允許自動攻擊，例如撞庫，其中攻擊者擁有有效用戶名和密碼的列表。

• 允許蠻力或其他自動攻擊。

• 允許使用默認密碼、弱密碼或眾所周知的密碼，例如 “Password1” 或“admin/admin”。

• 使用弱或無效的憑據恢復和忘記密碼流程，例如無法確保安全的 “基於知識的答案”。

• 使用純文本、加密或弱散列密碼（請參閱 A3:2017 - 敏感數據暴露）。

• 缺少或無效的多因素身份驗證。

• 在 URL 中公開會話 ID（例如，URL 重寫）。

• 成功登錄后不要輪換會話 ID。

• 不會正確地使會話 ID 無效。用戶會話或身份驗證令牌（主要是單點登錄 (SSO) 令牌）在注銷或一段時間不活動期間未正確失效。

如何預防

• 在可能的情況下，實施多因素身份驗證以防止自動憑證填充、暴力破解和被盜憑證重用攻擊。

• 不要使用任何默認憑據進行交付或部署，尤其是對於管理員用戶。

• 實施弱密碼檢查，例如針對前 10,000 個最差密碼列表測試新密碼或更改的密碼。

• 將密碼長度、復雜性和輪換策略與 NIST 800-63b 的第 5.1.1 節中關於記憶秘密的指南或其他現代的、基於證據的密碼策略保持一致。

• 通過對所有結果使用相同的消息，確保注冊、憑據恢復和 API 路徑能夠抵御帳戶枚舉攻擊。

• 限制或增加延遲失敗的登錄嘗試。當檢測到憑證填充、暴力破解或其他攻擊時，記錄所有故障並提醒管理員。

• 使用服務器端、安全、內置的會話管理器，在登錄后生成新的高熵隨機會話 ID。會話 ID 不應在 URL 中，安全存儲，並在注銷、空閑和絕對超時后失效。

A08:2021 - 軟件和數據完整性故障

描述

軟件和數據完整性故障與不能防止完整性違規的代碼和基礎設施有關。例如，在對象或數據被編碼或序列化為攻擊者可以看到和修改的結構的情況下，很容易受到不安全的反序列化的影響。另一種形式是應用程序依賴來自不受信任的來源、存儲庫和內容交付網絡 (CDN) 的插件、庫或模塊。不安全的 CI/CD 管道可能會導致未經授權的訪問、惡意代碼或系統受損。最后，許多應用程序現在包括自動更新功能，其中更新在沒有充分完整性驗證的情況下被下載並應用於以前受信任的應用程序。攻擊者可能會上傳自己的更新以分發並在所有安裝上運行。

如何預防

• 確保未簽名或未加密的序列化數據不會在沒有某種形式的完整性檢查或數字簽名的情況下發送到不受信任的客戶端，以檢測序列化數據的篡改或重放

• 通過簽名或類似機制驗證軟件或數據來自預期來源

• 確保庫和依賴項（例如 npm 或 Maven）使用受信任的存儲庫

• 確保使用軟件供應鏈安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）來驗證組件不包含已知漏洞

• 確保您的 CI/CD 管道具有正確的配置和訪問控制，以確保流經構建和部署過程的代碼的完整性。

A09:2021 - 安全日志記錄和監控失敗

描述

回到 2021 年 OWASP 前 10 名，該類別旨在幫助檢測、升級和響應主動違規行為。如果沒有日志記錄和監控，就無法檢測到漏洞。任何時候都會發生日志記錄、檢測、監控和主動響應不足的情況：

• 不記錄可審計的事件，例如登錄、失敗登錄和高價值交易。

• 警告和錯誤不會生成、不充分或不清楚的日志消息。

• 不會監控應用程序和 API 的日志是否存在可疑活動。

• 日志僅存儲在本地。

• 適當的警報閾值和響應升級流程沒有到位或有效。

• DAST 工具（例如 OWASP ZAP）的滲透測試和掃描不會觸發警報。

• 應用程序無法實時或接近實時地檢測、升級或警告主動攻擊。

通過使用戶或攻擊者可以看到日志記錄和警報事件，您很容易受到信息泄漏的影響（請參閱 A01:2021 – 損壞的訪問控制）。

如何預防

開發人員應實施以下部分或全部控制措施，具體取決於應用程序的風險：

• 確保所有登錄、訪問控制和服務器端輸入驗證失敗都可以用足夠的用戶上下文來記錄，以識別可疑或惡意帳戶，並保留足夠的時間以允許延遲取證分析。

• 確保以日志管理解決方案可以輕松使用的格式生成日志。

• 確保日志數據編碼正確，以防止對日志或監控系統的注入或攻擊。

• 確保高價值交易具有帶有完整性控制的審計跟蹤，以防止篡改或刪除，例如僅追加數據庫表或類似的。

• DevSecOps 團隊應該建立有效的監控和警報，以便快速檢測和響應可疑活動。

• 制定或采用事件響應和恢復計划，例如 NIST 800-61r2 或更高版本。

有商業和開源應用程序保護框架（例如 OWASP ModSecurity 核心規則集）和開源日志關聯軟件（例如 ELK 堆棧）具有自定義儀表板和警報功能。

A10:2021 - 服務器端請求偽造（SSRF）

描述

每當 Web 應用程序在未驗證用戶提供的 URL 的情況下獲取遠程資源時，就會出現 SSRF 缺陷。它允許攻擊者強制應用程序將精心設計的請求發送到意外目的地，即使受到防火牆、VPN 或其他類型的網絡 ACL 的保護也是如此。

隨着現代 Web 應用程序為最終用戶提供方便的功能，獲取 URL 成為一種常見情況。因此，SSRF 的發病率正在增加。此外，由於雲服務和架構的復雜性，SSRF 的嚴重性越來越高。

如何預防

開發人員可以通過實施以下部分或全部深度防御控制來防止 SSRF：

網絡層：

• 在單獨的網絡中分段遠程資源訪問功能以減少 SSRF 的影響

• 強制執行 “默認拒絕” 防火牆策略或網絡訪問控制規則，以阻止除基本 Intranet 流量之外的所有流量

應用層：

• 清理和驗證所有客戶端提供的輸入數據

• 使用肯定的允許列表強制執行 URL 架構、端口和目標

• 不要向客戶端發送原始響應

• 禁用 HTTP 重定向

• 注意 URL 一致性，以避免 DNS 重新綁定和 “檢查時間、使用時間”(TOCTOU) 競爭條件等攻擊

不要通過使用拒絕列表或正則表達式來緩解 SSRF。攻擊者擁有有效負載列表、工具和技能來繞過拒絕列表。