OWASP Top 10:2021 (A06~A10)
OWASP Top 10 終於在 2021 年發布最新的版本了。根據官方的資料，有 8 個類別是從 CWE 等數據統計其漏洞於該系統的發生率(Incidence Rate，非出現實例的頻率)而來，還有 2 個類別是由行業調查選出的。一起來綜覽概述一下吧！
A06:2021 — Vulnerable and Outdated Components (易受攻擊和已淘汰的元件)
此弱點由第九爬升到第六，在產業調查中排名第二，但有足夠的資料讓它進入前十。 易受攻擊的組件是我們努力測試和評估風險的已知問題，該弱點是在 CWEs 中唯一沒有任何 CVE 對應的類別。可參考 ASVS V1 Architecture, Design and Threat Modeling 章節。
弱點描述：
您可能容易受到攻擊：
- 如果您不知道您使用的所有組件的版本（客戶端和服務器端）。這包括您直接使用的組件以及嵌入的相依套件(Nested Dependencies)。
- 如果軟體容易受到攻擊、已不支援或已淘汰。 包括作業系統、網頁/應用程式伺服器、資料庫管理系統 (DBMS)、應用程式、 API 以及所有組件、執行環境和程式庫(Libraries)。
- 如果您沒有定期執行弱點掃瞄並訂閱與您使用組件相關的資安通報。
- 如果您未憑藉基於風險的方式及時修補或升級底層平台、框架和相依套件。 這通常發生在修補工作是變更控制下的每月或每季度任務的環境中，會使組織數天甚至數月不必要地暴露於可修補的漏洞風險。
- 如果軟體開發人員未測試更新、升級或修補後程式庫的相容性。
- 如果你未保護組件的設定檔案。（請參閱 A05:2021 — 安全設定缺陷）。
如何預防：
應該設置修補程式管理流程來：
- 刪除未使用的相依套件、不必要的功能、組件、檔案及文件。
- 持續使用版控工具來盤點客戶端和伺服器端組件（例如框架、程式庫）及相依組件的版本，如版控工具、OWASP Dependency Check、retire.js 等。 持續監控 CVE 和 NVD 等等來源來確認是組件是否存在的漏洞。使用軟體組合分析工具來自動化該流程。 訂閱您使用的組件相關的安全漏洞的資安通報。
- 持續盤點客戶端和伺服器端組件（例如框架、程式庫）及相依組件的版本，如版控工具、OWASP Dependency Check、retire.js 等。 持續監控 CVE 和 NVD 等等來源來確認是組件是否存在的漏洞。 使用軟體組合分析工具來自動化該流程。 訂閱您使用的組件相關的安全漏洞的資安通報。 使用諸如版控工具、OWASP Dependency Check、retire.js 等工具持續盤點客戶端和服務器端組件（例如框架、程式庫）及其相依組件的版本。
- 僅透過官方提供的安全連結來取得組件。 優先選擇已簽署的更新包，以降低更新包被加入惡意組件的可能。（請參閱 A08:2021-軟體及資料完整性失效）。
- 監控未維護或未為舊版本創建安全修補程式的程式庫和組件。 如果無法修補程式，請考慮部署虛擬修補程式來監控、檢測或防禦已發現的特定弱點。
- 有一些自動化工具可以幫助攻擊者找到未修補或配置錯誤的系統。 例如，Shodan IoT 搜索引擎可以幫助您找到存在 2014 年 4 月未修補 Heartbleed 漏洞的設備。
A07:2021 — Identification and Authentication Failures (認證及驗證機制失效)
之前被稱之為”無效的身份認證”，此類別從第二名下滑，現在包含了與身份識別失效相關的 CWE。可參考 ASVS V2 Authentication、V3 Session Management 章節。
弱點描述：
- 允許像是攻擊者已經擁有有效用戶名稱和密碼列表的撞庫攻擊(Credential Stuffing Attack)。
- 允許暴力或其他自動化攻擊。
- 允許預設、脆弱、常見的密碼，像是”Password1"或”admin/admin”。
- 使用脆弱或無效的認證資訊回覆或忘記密碼的流程，如不安全的「知識相關問答」。
- 將密碼使用明碼、加密或較脆弱雜湊法的方式儲存(參考A3: 2017-敏感性資料洩漏)。
- 不具有或是無效的多因子認證。
- 於 URL 中洩漏 Session ID (如 URL Rewriting)。
- 成功登入後沒有替換 Session ID (易遭受 Session Fixation Attack)。
- 沒有正確的註銷 Session ID。 用戶的Session或認證 Tokens (主要是 SSO Token) 沒有在登出時或一段時間沒活動時被適當的註銷。
如何預防：
- 在可能的情況下，實作多因素認證來防止自動化撞庫攻擊、暴力破解、以及遭竊認證資訊被重複利用的攻擊。
- 不要交付或部署任何預設的認證資訊，特別是管理者。
- 實作脆弱密碼的檢查，如測試新設定或變更的密碼是否存在於前 10,000個最差密碼清單。
- 將密碼長度、複雜度、和輪換政策與 NIST 800–63b 第5.1.1節「被記憶的秘密或其他現代基於證據的密碼政策」保持一致。
- 對所有結果使用相同的訊息回應，確保註冊、認證資訊回覆、以及 API 路徑能夠抵禦帳號列舉攻擊。
- 限制或增加失敗登入嘗試的延遲。記錄所有失敗並於偵測到撞庫、暴力破解或其他攻擊時發出告警。
- 使用伺服器端、安全的內建 Session 管理，在登入後產生新的高亂數隨機程度(Entropy)的隨機 Session ID。 Session ID 不應出現在 URL 中，必須被安全的儲存，並且在登出後、閒置、超時後被註銷。
A08:2021 — Software and Data Integrity Failures (軟體及資料完整性失效)
這是 2021 年版本全新的類別，並在軟體更新，機敏及重要資料，和 CI/CD 管道中並沒有做完整性的確認為前提做假設並進行評估。2017 年版本中不安全的反序列化(Deserialization)現在被合併至此類別。可參考 ASVS V5.5 Deserialization Prevention、V10.1 Code Integrity、V10.3 Application Integrity 章節。
弱點描述：
- 此程式碼或基礎架構未能保護軟體及資料之完整性受到破壞。
- 舉例來說，物件或資料經編碼或序列化到一個對攻擊者可讀寫之結構中將導致不安全的反序列化。
- 應用程式依賴的 Plugins 來自於不受信任來源，庫(Repository)及 CDN，函式庫或模組。
- 不安全的持續性整合/部署(CI/CD)流程則會造成潛在的未經授權存取，惡意程式碼或系統破壞。
- 自動更新功能在缺乏充足完整性驗證功能時就下載並安裝更新到處於安全狀態下的應用程式。攻擊者能上傳自製更新檔案，更新檔案將傳播到所有已安裝之應用程式並在這些應用程式上執行。
- 許多家用路由器、機上盒、裝置韌體等未以通過簽署之韌體驗證更新檔案。未簽署韌體是越來越多攻擊者的目標且情況只會變得更糟。
如何預防：
- 確保不受信任之客戶端不會收到未簽署或加密之序列化資料並利用完整性檢查或數位簽章來偵測竄改或重送攻擊。
- 利用數位簽章或類似機制確保軟體或資料來自預期之提供者。
- 確保函式庫及從屬套件，例如 npm 或 Maven，是從受信任的庫(Repository)取得。
- 使用軟體供應鏈安全工具(例如 OWASP Dependency Check 或 OWASP CycloneDX)確保元件沒有已知弱點。
- 適當地設定持續性整合/部署(CI/CD)流程的組態及存取控制以確保程式碼在組建及部署流程中的完整性。
A09:2021 — Security Logging and Monitoring Failures (資安記錄及監控失效)
在之前為「不完整的紀錄及監控」並納入在業界問卷中在本次列名為第三名並從之前的第十名上移。記錄及監控功能驗證非常有挑戰性，通常需要以訪談或詢問之方式檢驗有無偵測滲透測試的攻擊活動。偵測及應變對資安事件至關重要，但此類型之CVE/CVSS資料不多。可參考 ASVS V7 Error Handling and Logging 章節。
弱點描述：
- 可稽核事件未記錄，如登入成功，登入失敗及高價值交易。
- 警告或錯誤發生時未產生，產生不充足或產生不明確日誌。
- 未監控應用程式或應用程式介面(API)日誌中的可疑活動。
- 日誌僅儲存於本地端。
- 未設有或設有無效之適當告警閥值(Thresholds)及應變升級程序。
- 滲透測試及 DAST 工具(如 OWASP ZAP)掃描沒有觸發告警。
- 應用程式無法接近即時或即時偵測，升級或警告進行中之攻擊。
- 允許使用者或攻擊者讀取日誌或告警事件可能造成資訊洩漏(請參閱A01:2021-Broken Access Control)
如何預防：
- 確保記錄所有登入，存取控制及伺服器端輸入驗證之失敗，日誌應包含充足使用者情境以識別可疑或惡意帳號，日誌應存留充足時間以利未來可能之鑑識分析要求。
- 確保日誌格式符合一般日誌管理系統常用格式。
- 確保日誌經正確編碼以防止遭受注入攻擊或日誌/監控系統遭受攻擊。
- 確保高價值交易進行時產生稽核軌跡(日誌)並實作完整性控制以避免竄改或刪除，如僅限附加的資料表或類似工具。
- DevSecOps 團隊應建立有效地監控及告警機制以利偵測可疑活動並快速應變。
- 建立或導入事件應變及復原計畫和團隊(如 CSIRT, Computer Security Incident Response Team)，如 NIST 800–61r2 或更新版本。
A10:2021 — Server-Side Request Forgery (SSRF) (伺服端請求偽造)
這個類別是在業界問卷排名第一名，並在此版本內納入。此問題有較低被驗測次數和範圍，但有高於平均的威脅及影響權重比率。可參考 OWASP SSRF Prevention、PortSwigger — SSRF、A New Era of SSRF by Orange Tsai、CWE-918。
弱點描述：
- 當網頁應用程式正在取得遠端資源，卻未驗證由使用者提供的網址，此時就會發生 SSRF。
- 即便有防火牆、VPN 或其他網路 ACL 保護的情況下，攻擊者仍得以強迫網頁應用程式發送一個經過捏造的請求給一個非預期的目的端。
- 現今網頁應用為提供終端使用者便利，取得網址已經是常見服務。因此，SSRF 的發生率在逐步增加。而且，因為雲端服務和雲端結構的複雜性，SSRF 的嚴重性將會愈來愈嚴峻。
如何預防：
From Network layer (從網路層)：
- 將遠端資源存取功能切割成不同子網路以降低偽造伺服端請求之衝擊。
- 於防火牆政策或於網路存取控制規則實施「預設全拒絕(Deny by Default)」 ，以封鎖全部來自外部之網路流量。（請參閱A09:2021-安全記錄和監控失敗）
From Application layer (從應用層)：
- 過濾並驗證來自於用戶端提供之全部輸入。
- 以正面表列方式列出 URL、Port、目的地清單。
- 不傳送原始回應給用戶端。
- 停用 HTTP 重新導向 (HTTP Redirection)。
- 留意網址之一致性，以避免例如 DNS Rebinding攻擊、TOCTOU 攻擊(Time-of-check to time-of-use Attack)。
其他措施：
- 不要在前端系統（例如 OpenID）上部署其他安全相關服務。控制這些系統上的本地流量（例如 localhost）。
- 對於具有專用和可管理用戶組的前端，在獨立系統上使用網絡加密（例如 VPN）來考慮非常高的保護需求。
