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攻擊，

參考來源

https://owasp.org/www-project-top-ten/

https://zhuanlan.zhihu.com/p/453424697

標籤：其他

上一篇：【動手學深度學習】2.4 ~ 2.7 節學習（微積分、自動求導、概率、查閱檔案）

下一篇：「動態規劃」LeetCode 70(爬樓梯)