【2021】常見web安全漏洞TOP10排行

應用程式安全風險

攻擊者可以通過應用程式中許多的不同的路徑方式去危害企業業務。每種路徑方法都代表了一種風險，這些風險都值得關注。

什麼是 OWASP TOP 10

OWASP（開放式Web應用程式安全專案）是一個開放的社群，由非營利組織 OWASP基金會支援的專案。對所有致力於改進應用程式安全的人士開放，旨在提高對應用程式安全性的認識。

其最具權威的就是“10項最嚴重的Web 應用程式安全風險列表” ，總結並更新Web應用程式中最可能、最常見、最危險的十大漏洞，是開發、測試、服務、諮詢人員應知應會的知識。

OWASP Top 10 2021 是全新的，具有新的圖形設計和一頁有用的資訊圖。

2021 年前 10 名發生了什麼變化

有三個新類別，四個類別的命名和範圍發生了變化，並且 2021 年的前 10 名中進行了一些合併。

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-Software and Data Integrity Failures 軟體和資料完整性故障

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

A09:2021-Security Logging and Monitoring Failure 安全日誌記錄和監控失敗

以前是 日誌記錄和監控不足，是從行業調查 (#3) 中新增的，從之前的 #10 上升。此類別已擴充套件為包括更多型別的故障，難以測試，並且在 CVE/CVSS 資料中沒有得到很好的體現。但是，此類故障會直接影響可見性、事件警報和取證。

A10:2021-Server-Side Request Forgery 伺服器請求偽造

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

前 10 名的這一部分比以往任何時候都更受資料驅動，但並非盲目地受資料驅動。我們從貢獻的資料中選擇了十個類別中的八個，從高水平的行業調查中選擇了兩個類別。我們這樣做的根本原因是，檢視貢獻的資料就是回顧過去。AppSec 研究人員花時間尋找新的漏洞和測試它們的新方法。將這些測試整合到工具和流程中需要時間。當我們能夠可靠地大規模測試漏洞時，可能已經過去了很多年。為了平衡這種觀點，我們使用行業調查來詢問一線人員他們認為資料可能尚未顯示的漏洞。

有很多關於十大風險之間重疊的討論。根據每個（包括 CWE 列表）的定義，確實沒有任何重疊。但是，從概念上講，可能存在基於更高級別命名的重疊或互動。維恩圖多次用於顯示這樣的重疊。

上面的維恩圖代表了 2017 年十大風險類別之間的相互作用。這樣做時，幾個要點變得明顯：

有人可能會爭辯說，跨站點指令碼最終屬於注入，因為它本質上是內容注入。看看 2021 年的資料，XSS 需要進入注入變得更加明顯。

重疊僅在一個方向。我們通常會根據最終表現或“症狀”而不是（可能很深的）根本原因對漏洞進行分類。例如，“敏感資料暴露”可能是“安全配置錯誤”的結果；但是，您不會從另一個方向看到它。因此，在互動區域中繪製了箭頭以指示發生的方向。

有時這些圖表是用A06:2021 Using Components with known Vulnerabilities 中的所有內容繪製的。雖然其中一些風險類別可能是第三方漏洞的根本原因，但它們的管理方式和責任通常不同。其他型別通常代表第一方風險。

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。訪問管理頁面需要管理員許可權。

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

如果未經身份驗證的使用者可以訪問任一頁面，則這是一個缺陷。如果非管理員可以訪問管理頁面，這是一個缺陷。

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)。

文章來源：

https://mp.weixin.qq.com/s?src=11×tamp=1631198780&ver=3304&signature=mVvR1Op4HECl2g1ZgbUKzGS1F2ZUFpbg6ms29X4TznRKz-KrjJAwTeRR3-txjdW5DIcK7OX2plNlFruraSnLfALhQudnaVe8Y0SWKrYpxpWMtAnuXpUYRtlzIRSex6&new=1

https://github.com/OWASP/Top10/blob/master/2021/docs/index.md

https://woj.app/7546.html