OWASP TOP 10 2021
2021 年的 TOP 10 中有 3 個新類別、4 個更改了名稱和範圍的類別以及一些合併。
A01. 失效的訪問控制 Broken Access Control
失效的訪問控制是指應用程式中的訪問控制措施沒有被正確實施或沒有被充分考慮，從而導致攻擊者能夠繞過訪問控制措施，訪問未授權的資源和執行未授權的操作。
具體來說，失效的訪問控制漏洞可能包括以下方面：
- 目錄遍歷：攻擊者可以透過修改URL或提交特定的請求引數來訪問未授權的目錄或檔案。
- 許可權提升：攻擊者可以透過修改請求引數或透過其他方式來繞過應用程式的許可權限制，從而獲取更高的許可權或執行未授權的操作。
- 會話劫持：攻擊者可以透過獲取或偽造合法使用者的會話ID來偽裝成合法使用者，從而訪問敏感資源或執行未授權的操作。
- 特權繞過：攻擊者可以利用缺陷或漏洞繞過應用程式的特許可權制，從而訪問敏感資源或執行未授權的操作。
為了應對失效的訪問控制漏洞，應用程式開發者和管理員可以採取以下措施：
- 實施強制訪問控制：應用程式應該實現有效的訪問控制策略，並防止攻擊者透過偽造請求引數、修改URL或使用其他方法繞過訪問控制。
- 實現最小化原則：應用程式應該僅授權所需最小限度的許可權，並確保使用者僅訪問其需要的資源。
- 驗證和授權：應用程式應該實現嚴格的身份驗證和授權機制，以確保使用者只能訪問其授權的資源和操作。
- 實施會話管理：應用程式應該實施有效的會話管理機制，包括使用強密碼、使用HTTPS協議、定期更新會話金鑰等，以確保會話不被劫持或偽造。
- 進行安全測試：應用程式應該進行安全測試，包括漏洞掃描、滲透測試等，以識別潛在的失效的訪問控制漏洞並及時修復。
A02. 加密機制失效 Cryptographic Failures
加密機制失效是指應用程式中使用的加密演算法、金鑰管理和其他相關技術存在漏洞或缺陷，導致加密機制無法達到預期的安全保護效果。
具體來說，加密機制失效可能包括以下方面：
- 弱加密演算法：應用程式中使用的加密演算法過於簡單或易於被破解，從而導致加密資料不再安全。
- 不安全的金鑰管理：應用程式中的金鑰管理不夠安全，如金鑰儲存在明文中、金鑰強度不足等，使攻擊者可以獲取金鑰並解密加密資料。
- 敏感資訊洩露：敏感資訊的傳輸或儲存存在漏洞，如資料洩露、攔截、篡改等，使攻擊者可以獲取敏感資料。2017-A03 敏感資訊洩露
- 暴力破解攻擊：攻擊者使用暴力破解等方法獲取加密資料，從而導致加密機制失效。
為了應對加密機制失效漏洞，應用程式開發者和管理員可以採取以下措施：
- 選擇強加密演算法：應用程式應該選擇強加密演算法，並確保金鑰的長度和強度足夠安全。
- 實施安全的金鑰管理：應用程式應該採用安全的金鑰管理機制，包括金鑰加密、金鑰分發、金鑰儲存等，確保金鑰不被洩露或破解。
- 實施安全的傳輸和儲存：應用程式應該實施安全的傳輸和儲存機制，包括使用SSL/TLS協議、加密傳輸、安全儲存等，確保加密資料不被洩露或篡改。
- 防範暴力破解攻擊：應用程式應該實施防範暴力破解攻擊的措施，如限制登入嘗試次數、使用複雜密碼等，以防止攻擊者透過暴力破解獲取金鑰或加密資料。
- 進行安全測試：應用程式應該進行安全測試，包括加密演算法評估、金鑰管理評估等，以識別潛在的加密機制失效漏洞並及時修復。
A03. 注入 Injection
注入漏洞是指攻擊者可以透過注入惡意程式碼或指令來攻擊應用程式的漏洞。常見的注入漏洞包括SQL隱碼攻擊、命令注入和LDAP注入等。
具體來說，注入漏洞可能包括以下方面：
- SQL隱碼攻擊：攻擊者透過注入惡意的SQL程式碼來獲取敏感資料、修改資料庫內容或執行其他惡意操作。
- 命令注入：攻擊者透過注入惡意的命令來執行系統命令、獲取敏感資訊或執行其他惡意操作。
- LDAP注入：攻擊者透過注入惡意的LDAP程式碼來獲取敏感資料、修改LDAP目錄內容或執行其他惡意操作。
- 跨站指令碼攻擊（XSS）注入：攻擊者透過在受害者瀏覽器中注入惡意指令碼，從而獲取使用者的敏感資訊，例如密碼、銀行賬戶等。XSS攻擊可以分為反射型、儲存型和DOM型三種型別。2017-A07 跨站指令碼XSS
為了應對注入漏洞，應用程式開發者和管理員可以採取以下措施：
- 使用引數化查詢：應用程式應該使用引數化查詢或預處理語句，確保SQL語句的引數值是預先定義的，避免攻擊者透過注入惡意的SQL程式碼來執行惡意操作。
- 過濾和驗證輸入：應用程式應該對使用者輸入進行過濾和驗證，過濾特殊字元，限制特定的字符集,確保輸入資料符合預期的格式和型別,避免攻擊者透過注入惡意程式碼來執行惡意操作。在輸出時使用HTML編碼，避免JavaScript指令碼注入。
- 最小化許可權：應用程式應該最小化資料庫使用者的許可權，避免攻擊者透過注入惡意SQL程式碼來獲取或修改敏感資料。
- 使用ORM框架：應用程式可以使用ORM框架（物件關係對映），ORM框架將處理SQL程式碼和引數傳遞，使開發人員可以避免手寫的SQL程式碼中的注入問題。
- 檢查系統日誌：應用程式應該檢查系統日誌，監控攻擊行為，及時發現和處理注入漏洞。
- 定期進行漏洞掃描：應用程式應該定期進行漏洞掃描，包括注入漏洞掃描，以及及時修復潛在的漏洞。
A04. 不安全設計 Insecure Design
不安全設計通常是由於設計不良或缺乏安全意識而導致的，攻擊者可以利用這些設計缺陷來攻擊應用程式。
具體來說，不安全設計可能包括以下方面：
- 未考慮安全性：開發人員在設計應用程式時沒有考慮安全性，如忽略了訪問控制、密碼加密等。
- 信任過度：應用程式信任使用者提供的資料，而不進行適當的驗證，從而可能導致攻擊者利用這些缺陷來攻擊應用程式。
- 欺騙使用者：應用程式會誤導使用者，讓使用者進行危險的操作，例如“記住我”功能可能導致使用者在公共計算機上遭受攻擊。
為了應對不安全設計，應用程式開發者和管理員可以採取以下措施：
- 實施安全性的開發生命週期：開發團隊應該在整個應用程式開發過程中，重視安全性，包括設計、編碼、測試和部署等。
- 審查設計和程式碼：開發人員應該審查設計和程式碼，以確保應用程式符合最佳安全實踐，如採用強密碼策略、安全的會話管理和訪問控制等。
- 應用程式的最小許可權：應用程式應該最小化使用者許可權，只授予必需的許可權。
- 安全認證：應用程式應該對使用者身份進行驗證，並對敏感操作進行適當的認證和授權，避免攻擊者利用應用程式中的信任問題來攻擊。
- 針對安全性進行測試：應用程式應該定期進行安全性測試，包括程式碼審計、漏洞掃描和滲透測試等，以確保應用程式符合最佳安全實踐，並及時修復發現的漏洞。
A05. 安全配置錯誤 Security Misconfiguration
安全配置錯誤通常是由於不正確的配置或管理而導致的，攻擊者可以利用這些漏洞來攻擊應用程式。
具體來說，安全配置錯誤可能包括以下方面：
- 預設密碼：應用程式或其元件使用預設密碼，攻擊者可以輕鬆地利用這些密碼訪問應用程式或元件。
- 禁用安全功能：開發人員或管理員可能禁用了某些安全功能，例如檔案上傳的限制、錯誤訊息的顯示和日誌記錄等，從而導致應用程式易受攻擊。
- 未正確配置XML解析器：XML外部實體攻擊（XML External Entity, XXE）通常發生在應用程式未能正確配置XML解析器的情況下，攻擊者利用了XML解析器處理外部實體的機制。當XML解析器解析XML文件時，它會根據定義在文件中的實體宣告解析實體。攻擊者可以透過定義惡意的外部實體並將其插入XML文件中，從而導致XML解析器執行惡意操作，例如讀取檔案、執行系統命令等等。2017-A04XML外部實體攻擊(XXE)
- 不安全的預設配置：應用程式或其元件可能包含不安全的預設配置，例如開放的埠、除錯模式、開放的檔案共享等。
- 不及時的安全更新：應用程式或其元件可能包含已知的安全漏洞，但由於管理員沒有及時更新，導致攻擊者可以利用這些漏洞來攻擊應用程式。
為了應對安全配置錯誤，應用程式開發者和管理員可以採取以下措施：
- 最小化攻擊面：應用程式應該最小化攻擊面，例如只開放必需的埠、禁用不需要的服務等。
- 加強安全配置：應用程式和元件應該採用最佳安全配置實踐，例如使用強密碼、啟用錯誤訊息的顯示、關閉除錯模式等。
- 禁用外部實體：應用程式應該禁用XML解析器的外部實體功能，例如在解析XML文件時使用禁用外部實體的選項。這樣可以有效防止攻擊者利用外部實體攻擊。
- 實施白名單：應用程式應該實施白名單措施，例如只信任特定的IP地址、域名等等，以減少攻擊者利用XXE漏洞的風險。
- 加強輸入驗證：應用程式應該加強對使用者輸入的驗證，例如限制XML文件中的實體宣告，以防止攻擊者利用XXE漏洞傳送惡意請求。
- 使用安全XML解析器：應用程式可以使用安全的XML解析器，例如谷歌的安全XML解析器或OWASP的ESAPI庫，以減少XXE攻擊的風險。
- 及時更新：應用程式和元件應該及時更新，以修復已知的安全漏洞。
- 實施安全審計：應用程式和元件應該定期進行安全審計，以查詢潛在的配置錯誤或漏洞，並及時修復它們。
- 強制訪問控制：應用程式和元件應該強制訪問控制，只授權給需要的使用者和角色。
- 安全監控：應用程式和元件應該實施安全監控，包括日誌記錄、入侵檢測和安全事件響應等，以及時發現和應對安全問題。
A06. 危險和過時的元件 Vulnerable and Outdated Components
危險和過時的元件常是由於使用具有已知安全漏洞的第三方元件或庫而導致的，攻擊者可以利用這些漏洞來攻擊應用程式。
具體來說，危險和過時的元件可能包括以下方面：
- 已知的漏洞：應用程式或其元件可能包含已知的安全漏洞，例如Heartbleed、Shellshock等。2017-A09使用含有已知漏洞的元件
- 過時的元件：應用程式或其元件可能使用已過時的第三方元件或庫，這些元件或庫可能包含已知的安全漏洞，但由於沒有及時更新，導致攻擊者可以利用這些漏洞來攻擊應用程式。
- 不可信的元件來源：應用程式或其元件可能從不可信的元件來源獲取元件或庫，這些元件或庫可能包含惡意程式碼，攻擊者可以利用這些元件來攻擊應用程式。
為了應對危險和過時的元件，應用程式開發者和管理員可以採取以下措施：
- 最小化元件：應用程式應該最小化使用第三方元件或庫，並僅使用必需的元件。
- 使用可信的元件來源：應用程式應該從可信的元件來源獲取元件或庫，並使用數字簽名來驗證元件的完整性和真實性。
- 及時更新：應用程式和元件應該及時更新，以修復已知的安全漏洞，並使用最新的版本。
- 實施漏洞管理：應用程式和元件應該實施漏洞管理，定期掃描應用程式和元件以查詢已知的安全漏洞，並及時修復它們。
- 漏洞披露：應用程式和元件應該參考元件供應商的漏洞披露通知，並及時升級元件或庫。
- 安全監控：應用程式和元件應該實施安全監控，包括日誌記錄、入侵檢測和安全事件響應等，以及時發現和應對安全問題。
A07. 身份鑑別和身份認證失效 Identification and Authentication Failures
身份鑑別和身份認證失效通常是由於應用程式在身份驗證和鑑別過程中存在漏洞或錯誤而導致的。
具體來說，身份鑑別和身份認證失效可能包括以下方面：
- 弱密碼和口令：應用程式可能允許使用者使用弱密碼和口令進行身份認證，這使得攻擊者更容易猜測或破解密碼。2017-A02失效的身份認證
- 缺乏多因素身份認證：應用程式可能只使用單一的身份認證方法，例如使用者名稱和密碼，而沒有使用其他的多因素身份認證方法，例如令牌、生物識別等，這使得攻擊者更容易偽造身份。2017-A02失效的身份認證
- 會話管理漏洞：應用程式可能存在會話管理漏洞，例如會話劫持、會話固定、會話登出等，這使得攻擊者能夠利用被攻擊者的身份進行攻擊。
- 拒絕服務攻擊：應用程式可能受到拒絕服務攻擊，例如暴力破解、暴力撞庫、暴力掃描等，這會影響使用者的身份驗證和鑑別過程。
為了應對身份鑑別和身份認證失效，應用程式開發者和管理員可以採取以下措施：
- 使用強密碼和口令：應用程式應該要求使用者使用強密碼和口令，並使用密碼策略來強制要求使用者遵守密碼規則。
- 實施多因素身份認證：應用程式應該實施多因素身份認證，例如令牌、生物識別等，以增強使用者身份認證的安全性。
- 加強會話管理：應用程式應該實施會話管理，例如會話劫持檢測、會話固定預防、會話登出等，以減少攻擊者利用被攻擊者的身份進行攻擊的可能性。
- 安全認證協議：應用程式應該使用安全的身份認證協議，例如OAuth、OpenID等，以確保身份認證過程的安全性。
- 拒絕服務防護：應用程式應該實施拒絕服務防護措施，例如限制登入嘗試次數、IP地址過濾、驗證碼等，以減少暴力破解、暴力撞庫等拒絕服務攻擊的影響。
A08. 軟體和資料完整性失效 Software and Data Integrity Failures
軟體和資料完整性失效通常是由於應用程式在儲存、處理或傳輸資料時存在漏洞或錯誤而導致的。攻擊者可以利用這些漏洞或錯誤來篡改應用程式中的資料或程式碼，從而破壞應用程式及資料的完整性。
具體來說，軟體和資料完整性失效可能包括以下方面：
- 資料庫注入漏洞：應用程式可能受到資料庫注入攻擊，攻擊者可以利用這些漏洞來篡改應用程式中的資料。
- CSRF攻擊：應用程式可能受到CSRF攻擊，攻擊者可以利用這些漏洞來利用使用者的身份執行未經授權的操作，例如更改使用者密碼。
- 不安全的反序列化：攻擊者利用應用程式中的反序列化過程，將惡意資料反序列化為可執行程式碼，以執行惡意操作的漏洞。在反序列化過程中，應用程式將序列化的資料還原為物件或資料結構。攻擊者可以透過修改序列化的資料或提供特製的輸入來欺騙應用程式，從而執行惡意程式碼，例如執行遠端命令、訪問敏感資料或篡改資料等。2017-A08不安全的反序列化
- 檔案上傳漏洞：應用程式可能存在檔案上傳漏洞，攻擊者可以利用這些漏洞上傳包含惡意程式碼的檔案到伺服器上，從而破壞應用程式的完整性。
- 程式碼注入漏洞：應用程式可能受到程式碼注入攻擊，攻擊者可以利用這些漏洞將惡意程式碼注入應用程式中，從而破壞應用程式的完整性。
為了應對軟體和資料完整性失效，應用程式開發者和管理員可以採取以下措施：
- 輸入驗證和過濾：應用程式應該實施輸入驗證和過濾來防止資料庫注入漏洞和程式碼注入漏洞。
- CSRF防護：應用程式應該實施CSRF防護措施，例如使用CSRF令牌，以防止CSRF攻擊。
- 反序列化防護：序列化和反序列化應該僅限於可信的資料來源。應該使用安全的序列化庫和演算法，例如JSON或Protobuf，而不是不安全的序列化技術，例如Java的ObjectInputStream類。
- 檔案上傳驗證：應用程式應該對上傳的檔案進行驗證和過濾，以防止檔案上傳漏洞。
- 安全編碼實踐：應用程式開發者應該使用安全編碼實踐來避免程式碼注入漏洞和其他型別的漏洞。
- 加強訪問控制：應用程式應該實施訪問控制措施，例如身份驗證和授權，以防止未經授權的資料或程式碼修改。
- 加強日誌和監控：應用程式應該實施日誌和監控措施，例如記錄所有使用者操作和異常情況，以及及時響應和處理安全事件。
A09. 安全記錄及監控失效 Security Logging and Monitoring Failures
安全記錄及監控失效通常是由於應用程式未能正確記錄、監控和響應安全事件而導致的。這些安全事件可能包括潛在的攻擊、異常行為、系統故障等等。
具體來說，安全記錄及監控失效可能包括以下方面：
- 缺少安全日誌記錄：應用程式未能正確記錄安全事件，例如登入嘗試、身份驗證失敗、系統錯誤等等。
- 缺少安全監控：應用程式未能實施安全監控措施，例如檢測異常行為、威脅情報、漏洞掃描結果等等。
- 缺少響應計劃：應用程式未能實施安全響應計劃，例如在安全事件發生時採取適當的行動來遏制威脅、減少損失等等。
為了應對安全記錄及監控失效，應用程式開發者和管理員可以採取以下措施：
- 實施安全日誌記錄：應用程式應該實施安全日誌記錄措施，例如記錄登入嘗試、身份驗證失敗、系統錯誤等等。
- 實施安全監控措施：應用程式應該實施安全監控措施，例如實時監測異常行為、威脅情報、漏洞掃描結果等等。
- 實施安全響應計劃：應用程式應該實施安全響應計劃，例如在安全事件發生時採取適當的行動來遏制威脅、減少損失等等。
- 加強訪問控制：應用程式應該實施訪問控制措施，例如限制使用者許可權、記錄所有使用者操作等等，以便快速檢測和響應安全事件。
- 加強安全培訓和意識：應用程式開發者和管理員應該接受安全培訓和意識教育，以瞭解安全記錄及監控的重要性，並學會如何識別和應對安全事件。
A10. 伺服器端請求偽造 Server-Side Request Forgery (SSRF)
伺服器端請求偽造（Server-Side Request Forgery, SSRF）是指攻擊者可以利用應用程式的漏洞，欺騙伺服器發起網路請求，從而攻擊內部系統或雲服務。攻擊者可以利用SSRF漏洞訪問應用程式未授權的外部系統和資源，例如訪問內部網路、獲取敏感資料等等。
具體來說，SSRF漏洞通常由以下原因導致：
- 輸入驗證不充分：應用程式未能正確驗證使用者提供的輸入，例如URL引數、請求體等等。
- 信任不合理：應用程式在發起網路請求時信任了不可信的使用者輸入。
- 未授權訪問：應用程式未能正確限制訪問許可權，導致攻擊者可以訪問未授權的資源。
為了應對SSRF漏洞，應用程式開發者和管理員可以採取以下措施：
- 實施輸入驗證：應用程式應該實施輸入驗證措施，例如驗證URL引數、請求體等等，以防止攻擊者利用SSRF漏洞傳送惡意請求。
- 實施授權機制：應用程式應該實施授權機制，例如限制網路訪問許可權、驗證使用者身份等等，以確保只有授權的使用者可以訪問內部資源。
- 限制網路訪問：應用程式應該限制網路訪問範圍，例如透過防火牆、安全組等等限制網路訪問範圍，以減少攻擊者利用SSRF漏洞的風險。
- 實施白名單：應用程式應該實施白名單措施，例如限制網路訪問範圍、只信任特定的IP地址、域名等等，以減少攻擊者利用SSRF漏洞的風險。
- 加強安全培訓和意識：應用程式開發者和管理員應該接受安全培訓和意識教育，以瞭解SSRF漏洞的風險和應對方法，學會如何識別和防止SSRF攻擊。
參考來源