OWASP Top 10:2021 (A01~A05)
Published in
12 min readJan 18, 2022
OWASP Top 10 終於在 2021 年發布最新的版本了。根據官方的資料，有 8 個類別是從 CWE 等數據統計其漏洞於該系統的發生率(Incidence Rate，非出現實例的頻率)而來，還有 2 個類別是由行業調查選出的。一起來綜覽概述一下吧！
從官方提供的2017版與2021版的演變圖，可看到有三個(New)的全新類別，另外的類別也有名稱的修正和合併。
A01:2021-Broken Access Control (權限控制失效)
從原先第五名晉升至第一名，超過 94% 的應用程式易受此攻擊。這不僅是因為雲端計算和 API 使用的增加，還因為這個問題很難用自動化掃描工具檢測，這主要是透過滲透測試人員和漏洞賞金獵人才能發現，開發人員避免它通過實施安全訪問控制。可參考 ASVS V4 Access Control 章節。
弱點描述：
- 違反最小權限原則或默認拒絕，即只應授予特定功能、角色或用戶訪問權限，但任何人都可以使用。
- 通過修改 URL（參數竄改或強制瀏覽）、內部應用程式狀態或 HTML 頁面，或僅使用自定義 API 攻擊工具來繞過存取控制檢查。
- 容許 Unique ID 被更改為其他用戶的記錄，允許查看或編輯其他人的帳戶(Insecure Direct Object References)。
- 存取缺少存取控制的 API 以進行 POST、PUT 和 DELETE 等操作。
- 特權提升(Elevation of privilege)。未登入即成為用戶，或以用戶身份登入即成為管理員。
- 後設資料操作(Metadata manipulation)，例如重送或竄改 JSON Web Token(JWT)之存取控制 Token，或被操縱以提升特權或濫用 JWT 失效的 Cookie 或隱藏欄位。
- CORS 錯誤配置允許未經授權的 API 存取。
- 以未經身份驗證的用戶身份強制瀏覽已驗證的頁面或以標準用戶身份存取特權頁面。
如何預防：
- 除公開的資源外，默認為拒絕存取(Deny by Default, Fail Securely)。
- 一次性地建置存取控制機制，之後在整個應用程式中重複使用它們，包括最大限度地減少使用 CORS。
- 模型存取控制措施應該強化記錄所有權，而不是讓用戶可以創建、讀取、更新或刪除任何記錄。
- 獨特的應用程式業務限制要求應由領域模型予以強化。
- 停用 Web 伺服器目錄列表，並確保檔案中繼資料（例如，.git)和備份檔案不在 Web 根目錄中。
- 記錄存取控制失效，並在適當的時間警示管理員（例如，重覆性失效）。
- 對 API 和控制器存取進行流量限制，以降低自動攻擊工具所帶來的損害至最小化。
- JWT Token 於登出後，在伺服器端應使其失效。
A02:2021 — Cryptographic Failures (加密機制失效)
上升一名來到第二名。之前版本稱為「敏感性資料洩漏」更像是一種廣泛的症狀而非根因。本版本聚焦於密碼學相關的失效(或缺乏加密)，並因此常常導致敏感資料的洩漏。可參考 ASVS V6 Stored Cryptography、V8 Data Protection 及 V9 Communication 章節。
弱點描述：
首先確定靜態資料及資料傳輸的防護需求。如：，密碼、信用卡卡號、健康紀錄、個資、以及需要額外保護的營業祕密…等等主要被隱私法所保護的資料，如歐盟 GDPR 或 PCI DSS 等金融業相關的資料保護法或標準。對於這些資料需考量：
- 上述資料是否以明碼傳輸？如 HTTP、SMTP、FTP 等等協定，使用於對外網際網路的流量是危險的(可採 STARTTLS 升級)。且必須驗證所有的內部流量，如在負載平衡器、網站伺服器、或後端系統之間 。
- 是否有任何老舊或脆弱的加密演算法被預設使用或存在於較舊的程式碼？
- 是否有任何預設的加密金鑰被使用、脆弱的加密金鑰被重複使用，是否有適當的金鑰管理或金鑰輪換？
- 加密是否非強制？舉例：使用者代理(瀏覽器)是否有遺失安全相關的Directives 如 Content Security Policy (CSP) 或 header？
- 使用者代理(如：App、郵件客戶端)是否有驗證伺服器的憑證和信任鏈是有效的？
- 初始向量(IV)是否被忽略、重用或生成的加密操作模式不夠安全？是否使用了如 ECB 之類的不安全操作模式？
- 隨機亂數是否用於不符合加密要求的加密目的？即使選擇了正確的加密函數，亂數種子是否需要由開發人員提供？如果不需要，是否有用缺乏足夠熵/不可預測性(Sufficient Entropy/Unpredictability)的亂數種子？
- 是否正在使用已棄用的雜湊函數（例如 MD5 或 SHA1），或者在需要加密雜湊函數時使用非加密雜湊函數？
- 是否正在使用已棄用的加密填充方法，例如 PKCS#1 v1.5？(CVE-2020–20949、CVE-2020–20950)
- 加密錯誤消息或邊旁路攻擊(Side-channel Attack)是否可被利用，例如以密文填塞攻擊(Padding Oracle Attack)的形式？
如何預防：
- 對應用程式處理、儲存、傳輸的資料進行分類，根據隱私法、法令法規、或商業需求辨識哪些為敏感性資料。
- 依照分類執行對應的控制措施。
- 非必要不儲存敏感性資料，盡快捨棄或使用符合 PCI DSS 的資料記號化(Tokenization)甚至截斷(Truncation)。 沒有被保存的數據是不會被竊取的。
- 確保將所有靜態的敏感性資料加密。
- 確認使用最新版且標準的強演算法、協定及金鑰；使用適當的金鑰管理。
- 使用安全的協定加密傳輸中的資料，像是有前向保密(FS)、伺服器加密優先順序(Cipher Prioritization)及安全參數的 TLS。 使用像是 HTTP 強制安全傳輸技術(HSTS)的指令強化加密。
- 針對包含敏感資料的回應停用快取。
- 使用具有雜湊迭代次數因素(Work factor/Delay factor)，如 Argon2、scrypt、bcrypt 或 PBKDF2 的強自適應性加鹽雜湊法來儲存密碼。
- 必須選擇適合操作模式的初始化向量。對於許多模式，這意味著使用 CSPRNG（加密安全偽隨機數生成器）。
- 始終使用經過身份驗證的加密，而不僅僅是加密。
- 獨立驗證配置(Configuration)和設置(Settings)的有效性。
A03:2021 — Injection (注入式攻擊)
下滑到第三名，94% 被測試的應用程式都有驗測到某種類別注入式攻擊的問題。跨站腳本攻擊(Cross-site Scripting)現在在新版本屬於這個類別。可參考 ASVS V5 Validation, Sanitization and Encoding 章節。
弱點描述：
- 應用程式未驗證、過濾或清理使用者提供的資料。
- 在直譯器中未使用上下文感知轉義的動態查詢或無參數呼叫。
- 在物件關係對映 (ORM) 搜索參數中使用惡意數據來提取額外的敏感記錄。
- 在SQL或指令在動態查詢、命令或預存程序(Stored Procedures)中，直接使用或連結了惡意資料。
- 常見 Injection 包含 SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection。
如何預防：
- 首選選項是使用安全 API，完全避免使用解釋器，提供參數化界面，或整合到物件關係對映(ORM)工具中。
注意：即使在參數化的情況下，如果 PL/SQL 或 T-SQL 連接查詢和數據或使用 EXECUTE IMMEDIATE 或 exec() 執行惡意數據，Stored Procedures仍然會引入 SQL 注入攻擊。 - 使用正面或白名單在伺服器端驗證輸入的資料。這不是一個完整的防禦措施，因為許多應用程序需要特殊字符，例如應用程式的文本區域或應用程式界面 (API)應用於行動裝置上的應用程式。
- 對於任何剩餘的動態查詢，在轉譯中使用特殊符號進行查詢將對查詢語法帶來不同的涵義。
注意： SQL 結構，如資料表名稱、欄位名稱是無法被轉譯的，因此使用者提供資料結構的名稱是危險的，這是在報告編寫軟體中的常見問題。 - 在查詢中使用 LIMIT 和其他 SQL 控件，以防止在 SQL 注入的情況下大量洩露記錄。
A04:2021 — Insecure Design (不安全設計)
這是 2021 年版本的新類別，並特別針注在與設計相關的缺失。如果我們真的希望讓整個產業「向左移動」(Shift-left Testing)，那我們必須進一步的往威脅建模，安全設計模塊的觀念，和安全參考架構前進。可參考 ASVS V1 Architecture, Design and Threat Modeling章節。
弱點描述：
- 不安全設計是一個廣泛的類別，代表不同的弱點，表示為「缺失或無效的控制設計」。
- 不安全的設計和不安全的實作是有區別的。我們區分設計缺陷和實現缺陷是有原因的，它們有不同的根本原因和補救措施。
- 不安全的設計無法通過完美的實作來解決，因為根據定義，從未創建過所需的安全控制，絕無法防禦特定攻擊。
- 需求和資源管理：收集並與業務協商應用程序的業務需求，包括有關所有數據資產的機密性、完整性、可用性和真實性以及預期業務邏輯的保護要求。
- 安全設計(Secure Design)：安全設計一個文化與方法持續不斷的來評估威脅並保證程式碼有被穩健的設計與測試來預防已知的攻擊方法。
- 安全開發生命週期(Secure Development Lifecycle)：安全設計需要安全的開發生命週期、某種形式上的安全設計模式或是已完成的元件庫或工具以及威脅建模。可參考 OWASP SAMM 模型建構。
如何預防：
- 與 AppSec 專業人員一起建立和使用安全開發生命週期，以幫助評估和設計安全和隱私相關的控制。
- 建立與使用安全設計模式的函式庫或是已完成可使用的元件。
- 使用威脅建模(Threat Modeling)在關鍵的認證、存取控制、商業邏輯與關鍵缺陷上。
- 整合安全程式語言和控制措施到 User Story 的建模中。
- 整合合理性檢查在應用程式中的每一層（從前端到後端）。
- 撰寫單元測試與整合測試來驗證所有的關鍵流程對威脅建模都有對策。
- 通過設計在所有層級中可靠地隔離租用者。
- 限制使用者或服務的資源消耗。
A05:2021 — Security Misconfiguration (安全設定缺陷)
從上一版本的第六名移動上來。90% 被測試的應用程式都有驗測到某種類別的安全設定缺陷。前版本中的 XML 外部實體注入攻擊 (XML External Entities)現在屬於這個類別。可參考 ASVS V14 Configuration章節。
弱點描述：
- 在程式各堆疊層面缺少適當的安全強化，或對雲服務的權限配置不當。
- 啟用或安裝了不必要的功能（例如，不必要的端口、服務、頁面、帳號或權限）。
- 預設的帳戶及其密碼仍處於啟用狀態且未更改。
- 錯誤處理向使用者顯示堆疊追蹤(Stack Traces)或暴露出過多的錯誤訊息。
- 因系統升級，導致最新的安全功能被禁用或未安全配置。
- 應用伺服器、應用框架（例如，Struts、Spring、ASP.NET）、函式庫、資料庫等中的安全設置未設置為安全值。
- 服務器並未發送安全的 Headers 或 Directives，或未設置安全參數。
- 該軟件已過時或易受攻擊(可參閱 A06:2021-易受攻擊和過時的組件)。
如何預防：
- 一個可重複的安全強化流程，必需可達到快速且簡單的佈署，而且能在分隔且封鎖的環境下執行。
- 開發，品質管理，以及實際營運的環境，都須有一致相同的設定，並且使用不同的認證資訊。這種步驟需要盡可能的自動化，降低需要建立安全環境時，所需要的投入。
- 一個最精簡的平台，上面不會搭配任何不需要的功能，套件，檔案，以及範本。移除或不安裝任何，不須使用的功能或框架。
- 在變更管理下，需有特定的任務，依據安全告知，相關更新，來執行安全審視及更動(可參閱 A06:2021-易受攻擊和過時的組件)。審視雲端儲存的權限(例如 S3 bucket的權限)。
- 一個可分割的程式架構，對於各元件，用戶，可透過分離，容器化，雲端安全群組設定(ACLs)，來達到分割的效果。提供有效且安全的分離。
- 寄送安全指令給用戶端，例如 Security Headers。
- 一個自動化的流程，可以確認環境中各類的安全設定。
