目錄

• A01：2021-失效的訪問控制Broken Access Control
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A02：2021-加密機制失效（敏感數據泄漏）Cryptographic Failures
• • 常見CVE(弱點枚舉)
  • 風險說明
  • 預防措施
• A03：2021-注入Injection
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A04：2021-不安全設計Insecure Design
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A05：2021-安全配置錯誤Security Misconfiguration
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A06：2021-自帶缺陷和過時的組件Vulnerable and Outdated Components
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A07：2021-身份識別和身份驗證錯誤（無效的身份認證）Identification and Authentication Failures
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A08：2021-軟件和數據完整性故障Software and Data Integrity Failures
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A09：2021-安全日志和監控故障Security Logging and Monitoring Failures
• • 常見CWE(弱點枚舉)
  • 風險說明
  • 預防措施
• A10：2021-服務端請求偽造 Server-Side Request Forgery
• • 風險說明
  • 預防措施

A01：2021-失效的訪問控制Broken Access Control

常見CWE(弱點枚舉)

CWE-200: Exposure of Sensitive Information to an Unauthorized
Actor（將敏感信息泄漏給未經授權的參與者）

CWE-201: Exposure of Sensitive Information Through
Sent Data（通過發送的數據泄漏敏感信息）

CWE-352: Cross-Site Request Forgery （跨站請求偽造）

風險說明

訪問控制強制實施策略，使用戶無法在其預期權限之外進行操作。失敗的訪問控制通常會導致未經授權的信息泄露、修改或銷毀所有數據、或在用戶權限之外執行業務功能。常見的訪問控制脆弱點包括：

違反最小特權原則或默認拒絕原則，即訪問權限應該只授予特定能力、角色或用戶，但實際上任何人都可以訪問。

通過修改 URL（參數篡改或強制瀏覽）、內部應用程序狀態或 HTML 頁面，或使用修改 API 請求的攻擊工具來繞過訪問控制檢查。

通過提供唯一標識符（不安全的直接對象引用）允許查看或編輯其他人的帳戶。

API沒有對POST、PUT 和DELETE強制執行訪問控制。

特權提升。 在未登錄的情況下假扮用戶或以用戶身份登錄時充當管理員。

元數據操作，例如通過重放或篡改 JSON Web 令牌 (JWT) 來訪問控制令牌，或操縱cookie 或隱藏字段以提升權限，或濫用 JWT 失效。

CORS 配置錯誤以致允許未授權或不可信的API訪問。

以未通過身份驗證的用戶身份強制瀏覽的通過身份驗證時才能看到的頁面或作為標準用戶身份訪問特權頁面。

預防措施

訪問控制只在受信服務器端代碼或無服務器API中有效，這樣攻擊者才無法修改訪問控制檢查或元數據。

除公有資源外，默認為“拒絕訪問”。

使用一次性的訪問控制機制，并在整個應用程序中不斷重用它們，包括最小化跨源資源共享 (CORS) 的使用。

建立訪問控制模型以強制執行所有權記錄，而不是簡單接受用戶創建、讀取、更新或刪除的任何記錄。

特別的業務應用訪問限制需求應由領域模型強制執行。

禁用Web服務器目錄列表，并確保文件元數據（例如： .git）和備份文件不存在于Web的根目錄中。

在日志中記錄失敗的訪問控制，并在適當時向管理員告警（例如：重復故障）。

對API和控制器的訪問進行速率限制，以最大限度地降低自動化攻擊工具帶來的危害。

當用戶注銷后，服務器上的狀態會話標識符應失效。無狀態的JWT令牌應該是短暫的，以便讓攻擊者的攻
擊機會窗口最小化。 對于時間較長的JWT，強烈建議遵循OAuth標準來撤銷訪問。

A02：2021-加密機制失效（敏感數據泄漏）Cryptographic Failures

常見CVE(弱點枚舉)

CWE-259: Use of Hard-coded Password （使用硬編碼密碼）

CWE-327: Broken or Risky Crypto Algorithm（損壞或有風險的加密算法）

CWE-331 Insufficient Entropy （熵不足）

風險說明

首先要確認：對傳輸中數據和存儲數據都有哪些保護需求。 例如，密碼、信用卡號、醫療記錄、個人信息和商業秘密需要額外保護，尤其是在這些數據屬于隱私保護法（如：歐盟GDPR) 或法規條例（如：金融數據保護標準PCI DSS)適用范圍的情況下。 對于這些數據，要確定：

在傳輸數據過程中是否使用明文傳輸？這和傳輸協議有關，如：HTTP、SMTP、經過TLS升級（如STARTTLS ）的FTP。外部網絡流量是有害的。需要驗證所有的內部通信，如，負載平衡、Web服務器或后端系統之間的流量。

無論是在默認情況下還是在舊的代碼中，是否還在使用任何舊的或脆弱的加密算法或傳輸協議？

是否使用默認加密密鑰、生成或重復使用脆弱的加密密鑰，或者是否缺少適當的密鑰管理或密鑰回轉？加密密鑰是否已經提交到源代碼存儲庫？

是否未執行強制加密，例如，是否缺少安全相關的HTTP（瀏覽器）指令或標頭？

接收到的服務器證書和信任鏈是否經過正確驗證？

初始化向量是否忽略，重用或生成的密碼操作模式是否不夠安全？ 是否正在使用不安全的操作模式，例如歐洲央行正在使用的操作模式？ 當認證加密更合適時是否使用加密？

在缺乏密碼基密鑰派生函數的情況下，是否將密碼用作加密密鑰？

隨機性是否用于并非旨在滿足加密要求的加密目的？ 即使選擇了正確的函數，它是否需要由開發人員播種，如果不需要，開發人員是否用缺乏足夠熵/不可預測性的種子覆蓋了內置的強大播種功能？

是否使用過時的散列函數，例如 MD5 或 SHA1，或者在散列函數需要加密時使用非加密散列函數？

是否在使用已棄用的加密填充方法，例如 PCKS number 1 v1.5？

加密的錯誤消息或側信道信息是否可以利用，例如使用填充預言機攻擊的形式？

預防措施

? 對應用程序處理、存儲或傳輸的數據分類，并根據隱私法、監管要求或業務需求確定哪些數據是敏感的。
? 對于沒有必要存儲的敏感數據，應當盡快清除，或者通過PCI DSS標記化或攔截。 未存儲的數據不能竊取。
? 確保加密存儲的所有敏感數據。
? 確保使用了最新的、強大的標準算法、協議和密鑰；并且密鑰管理到位。
? 確保加密傳輸過程中的數據，如使用安全協議（例如具有前向保密 (FS) 密碼的 TLS、服務器的密碼優先級
和安全參數）。確保強制執行數據加密，如使用HTTP 嚴格安全傳輸協議 (HSTS) 等指令。
? 禁用緩存對包含敏感數據的響應。
? 根據數據分類應用實施所需的安全控制。
? 不要使用FTP 和SMTP 等傳統協議來傳輸敏感數據。
? 使用具有工作因子（延遲因子）的強自適應和加鹽散列函數存儲密碼，例如 Argon2、scrypt、bcrypt 或PBKDF2。
? 必須選擇適合操作模式的初始化向量。對于大多數模式，可以使用CSPRNG（密碼安全偽隨機數生成器）。
對于需要隨機數的模式，則初始化向量 (IV) 不需要使用CSPRNG。 在所有情況下，對于一個固定密鑰，永遠不應該使用兩次IV。
? 始終使用經過驗證的加密，而不僅僅是加密。
? 密鑰應以加密方式隨機生成并作為字節數組存儲在內存中。 如果使用密碼，則必須通過適當的密碼基密鑰派生函數將其轉換為密鑰。
? 確保在適當的地方使用加密隨機性，并且沒有以可預測的方式或低熵進行播種。 大多數現代 API 不需要開發人員為 CSPRNG 設置種子以獲得安全性。
? 避免使用的已廢棄的加密函數和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。
? 單獨驗證每個安全配置項的有效性。

A03：2021-注入Injection

常見CWE(弱點枚舉)

CWE-79： Cross-siteScripting（跨站點腳本）

CWE-89：SQL Injection（SQL注入）

CWE-73：External Control of File Name or Path（文件名或路徑的外部控制）

風險說明

在以下情況下，應用程序易受攻擊：

應用程序不會驗證、過濾或清洗用戶提供的數據。

動態查詢或無上下文感知轉義的非參數化調用直接在解釋器中使用。

惡意數據在對象關系映射（ORM）搜索參數中用于提取額外的敏感記錄。

惡意數據被直接使用或連接。SQL或命令包含動態查詢、命令或存儲過程中的結構和惡意數據。

預防措施

防止注入需要將數據與命令和查詢分開：

推薦的選擇是使用安全的API，這樣可以避免完全使用解釋器、提供參數化接口或遷移到對象關系映射工具（ORM）。注意：即使參數化，如果PL/SQL或T-SQL將查詢和數據連接起來，或者使用EXECUTE IMMEDIATE或exec（）執行惡意數據，則存儲過程仍然可以引入SQL注入。

使用肯定（positive）或“白名單”服務器端輸入驗證。這并不是一種完美的防御，因為許多應用
程序需要特殊字符，例如移動應用程序中的文本區域或API。

對于任何殘余的動態查詢，請使用該解釋器的特定轉義語法轉義特殊字符。注意：SQL結構（如表
名、列名等）無法轉義，因此用戶提供的結構名是危險的。這是報表編寫軟件中的常見問題。

在查詢中使用LIMIT和其他SQL控件，以防止在SQL注入的情況下大量披露記錄。

A04：2021-不安全設計Insecure Design

2021年版的一個新類別，側重于與設計和體系結構缺陷相關的風險，呼吁更多地使用威脅建模、
安全設計模式和參考體系結構。

常見CWE(弱點枚舉)

CWE-209：Generation of Error Message Containing Sensitive Information（生成包含敏感信息的錯誤消息）

CWE-256：Unprotected Storage of Credentials（憑證的未保護存儲）

CWE-256：Unprotected Storage of Credentials（憑證的未保護存儲）

CWE-522：Insufficiently Protected Credentials（憑證保護不足）

風險說明

不安全設計是一個廣泛的類別，代表不同的弱點，表示為“缺少或無效的控制設計”。不安全設計
不是所有其他前10個風險類別的來源。不安全設計和不安全的實現之間存在差異。我們區分設計缺陷和實現缺陷是有原因的，它們有不同的根本原因和補救措施。安全設計仍然可能存在實現缺陷，從而導致可能被利用的漏洞。一個不安全設計不能通過一個完美的實現來修復，因為根據定義，所需的安全控制從未被創建來抵御特定的攻擊。導致不安全設計的因素之一是開發的軟件或系統中缺乏固有的業務風險分析，因此無法確定需要何種級別的安全設計。

需求和資源管理
收集應用程序的業務需求并與業務部門協商，包括所有數據資產和預期業務邏輯的機密性、完整性、可用性和真實性方面的保護需求。考慮應用程序的公開程度，以及是否需要租戶隔離（除訪問控制外）。編制技術要求，包括功能性和非功能性安全要求。計劃和協商所有設計、建造、測試和運營的預算，包括安全活動。

安全設計
安全設計是一種文化和方法，它不斷評估威脅，并確保代碼經過穩健的設計和測試，以防止已知的攻擊方法。威脅建模應整合到細化會議（或類似活動）中；查看數據流和訪問控制或其他安全控制中的更改。在用戶故事開發中，確定正確的流程和故障狀態，確保責任方和受影響方充分理解并同意這些狀態。分析預期和故障流的假設和條件，確保其仍然準確和可取。確定如何驗證正確行為所需的假設和實施條件。確保結果記錄在用戶故事中。從錯誤中吸取教訓，并提供積極的激勵以促進改進。安全設計既不是附加組件，也不是可以添加到軟件中的工具。

安全開發生命周期
安全的軟件需要安全開發生命周期、某種形式的安全設計模式、AppSec規劃方法、安全的組件庫、工具和威脅建模。在整個項目和軟件維護過程中，在軟件項目開始時聯系您的安全專家。考慮利用
OWASP軟件保證成熟度模型（SAMM）來幫助構建您的安全軟件開發工作。

預防措施

與應用安全專業人員建立并使用安全的開發生命周期，以幫助評估和設計與安全和隱私相關的控制。

建立并使用安全設計模式的庫，或使用AppSec規劃中現有的要素。

對關鍵身份驗證、訪問控制、業務邏輯和密鑰流使用威脅建模。

將安全語言和安全控制集成到用戶故事中。

在應用程序的每一層（從前端到后端）集成合理性檢查。

編寫單元和集成測試，以驗證所有關鍵流是否能夠抵抗威脅模型。為應用程序的每一層編譯正確用例和誤用案例。

根據暴露和保護需要，對系統層和網絡層進行分層。

通過設計在所有層中嚴格隔離租戶。

限制用戶或服務的資源消耗。

A05：2021-安全配置錯誤Security Misconfiguration

常見CWE(弱點枚舉)

CWE-16 Configuration（配置）

CWE-611 Improper Restriction of XML External Entity Reference（XML 外部實體引用的不當限制）

風險說明

您的應用程序可能受到攻擊，如果應用程序是：

應用程序棧的任何部分缺少適當的安全加固，或者云服務的權限配置錯誤。

應用程序啟用或安裝了不必要的功能（例如：不必要的端口、服務、網頁、帳戶或權限）。

默認帳戶和密碼仍然可用且沒有更改。

錯誤處理機制向用戶紕漏堆棧信息或其他大量錯誤信息。

對于升級的系統，最新的安全特性被禁用或未安全配置。

應用程序服務器、應用程序框架（如：Struts、Spring、ASP.NET）、庫文件、數據庫等沒有進
行安全配置。

服務器不發送安全標頭或指令，或未被設定安全參數。

您的應用軟件已過期或易受攻擊（參見“A6:2021-脆弱和過時的組件”）。
缺少一個體系的、可重復的應用程序安全配置過程，系統將處于高風險中

預防措施

一個可以快速且易于部署在另一個鎖定環境的可重復的加固過程。開發、質量保證和生產環境都應該進行相同配置，并且在每個環境中使用不同的密碼。這個過程應該是自動化的，以盡量減少安裝
一個新安全環境的耗費。

搭建最小化平臺，該平臺不包含任何不必要的功能、組件、文檔和示例。移除或不安裝不適用的功能和框架。

檢查和修復安全配置項來適應最新的安全說明、更新和補丁，并將其作為更新管理過程的一部分（參見“A6:2021-脆弱和過時的組件”）。在檢查過程中，應特別注意云存儲權限（如：S3桶權
限）。

一個能在組件和用戶間提供有效的分離和安全性的分段應用程序架構，包括：分段、容器化和云安全組（ACL）。

向客戶端發送安全指令，例如：安全標頭。

一個能夠驗證所有環境中進行了正確的安全配置和設置的自動化過程。

A06：2021-自帶缺陷和過時的組件Vulnerable and Outdated Components

常見CWE(弱點枚舉)

CWE-1104 Use of Unmaintained Third-Party
Components（使用未維護第三方組件）

風險說明

如果滿足下面的某個條件，那么您的應用就易受此類攻擊：

如果您不知道所有使用的組件版本信息（包括：服務端和客戶端）。這包括了直接使用的組件或間接依賴的組件。

如果軟件易受攻擊，不再支持或者過時。這包括：系統、Web服務器、應用程序服務器、數庫
管理系統（DBMS）、應用程序、API和所有的組件、運行環境和庫。

如果您沒有定期做漏洞掃描和訂閱使用組件的安全公告。

如果您不基于風險及時修復或升級底層平臺、框架和依賴庫。很可能發生這種情況：根據變更控制，每月或每季度進行升級，這使得組織在這段時間內會受到已修復但未修補的漏洞的威脅。

如果軟件工程師沒有對更新的、升級的或打過補丁的組件進行兼容性測試。

如果您沒有對組件進行安全配置（參見“A05:2021–安全配置錯誤”)。

預防措施

移除不使用的依賴、不需要的功能、組件、文件和文檔。

利用如versions、OWASP Dependency Check、retire.js等工具來持續的記錄客戶端和服務器端以及它們的依賴庫的版本信息。持續監控如CVE和NVD等是否發布已使用組件的漏洞信息，可以使用軟件分析工具來自動完成此功能。訂閱關于使用組件安全漏洞的警告郵件。

僅從官方渠道安全的獲取組件，并使用簽名機制來降低組件被篡改或加入惡意漏洞的風險 (參見
“A08:2021-軟件和數據完整性故障”)。

監控那些不再維護或者不發布安全補丁的庫和組件。如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。
每個組織都應該制定相應的計劃，對整個軟件生命周期進行監控、評審、升級或更改配置。

A07：2021-身份識別和身份驗證錯誤（無效的身份認證）Identification and Authentication Failures

常見CWE(弱點枚舉)

CWE-297: Improper Validation of Certificate with Host Mismatch（與不匹配的服務端進行不適當的憑證確認）

CWE-287: Improper Authentication（不適當的認證）

CWE-384: Session Fixation（會話固定攻擊）

風險說明

允許像是攻擊者已經擁有有效用戶名稱和密碼列表的撞庫自動化攻擊。

允許暴力或其他自動化攻擊。

允許預設、脆弱、常見的密碼，像是"Password1"或"admin/admin"。

使用脆弱或無效的認證資訊回復或忘記密碼的流程，如不安全的"知識相關問答"。

使用明碼、被加密的或使用較脆弱雜湊法的密碼(參考A3: 2017-敏感性資料泄漏)。(TODO)https://github.com/OWASP/Top10/issues/553

不具有或是無效的多因素認證。

于URL中泄漏會話(session) ID(如URL重寫)。

成功登入后沒有輪換會話(session) ID。

沒 有 正 確 的 注 銷 會 話 (session) ID。用 戶 的 會 話(session)或 認 證tokens(主 要 是 單 一 登 入(SSO)token) 沒有在登出時或一段時間沒活動時被適當的注銷。

預防措施

在可能的情況下，實施多因素認證來防止自動化撞庫攻擊、暴力破解、以及遭竊認證資訊被重復
利用的攻擊。

不要交付或部署任何預設的認證憑證，特別是管理者。

實施弱密碼的檢查，如測試新設定或變更的密碼是否存在于前10000個最差密碼清單。

將密碼長度、復雜度和輪換政策與NIST 800-63b文件“第5.1.1節-被記憶的秘密或其他現代基于
證據的密碼政策”的內容保持一致。

對所有結果使用相同的訊息回應，確保注冊、認證憑據回復以及API路徑能夠抵御帳號枚舉攻擊。

限制或增加登入失敗嘗試的延遲。記錄所有失敗并于偵測到撞庫、暴力破解或其他攻擊時發出告
警。

使用服器端、安全的內建會話管理器，在登入后產生有高熵值的新隨機會話ID。會話ID不應出現
在URL中，必須被安全的儲存，并且在登出后、閑置、超時后被注銷。

A08：2021-軟件和數據完整性故障Software and Data Integrity Failures

常見CWE(弱點枚舉)

CWE-829：Inclusion of Functionality from Untrusted Control Sphere（包含來自不受信任控制領域的功能）

CWE-494：Download of Code Without
Integrity Check（不進行完整性檢查的代碼下載）

CWE-502：Deserialization of Untrusted
Data（不可信數據的反序列化）。

風險說明

軟件和數據完整性故障與無法防止違反完整性的代碼和基礎設施有關。這方面的一個例子是，應用程序依賴于不受信任的源、存儲庫和內容分發網絡（CDN）的插件、庫或模塊。不安全的CI/CD管道可能會帶來未經授權的訪問、惡意代碼或系統安全風險。最后，許多應用程序現在包括自動更新功能。其中，更新包在沒有進行充足完整性驗證的情況下被下載，并應用于以前受信任的應用程序。攻擊者可能會上傳自己的更新包，以便在所有安裝上分發和運行。另一個例子是，對象或數據被編碼或序列化為攻擊者可以看到和修改的結構，很容易受到不安全的反序列化的影響。

預防措施

使用數字簽名或類似機制來驗證軟件或數據來自預期來源，且未被修改。

確保庫和依賴項目，如：npm 或 Maven，正在使用受信任的存儲庫。如果您的風險較高，請考慮
托管一個經過審核的、內部已知合格的存儲庫。

確保使用軟件供應鏈安全工具（如：OWASP Dependency Check 或 OWASP CycloneDX）來驗證組件不包含已知漏洞。

確保對代碼和配置更改進行審核，以最大限度地減少惡意代碼或配置引入軟件管道的可能性。

確保您的CI/CD管道具有適當的隔離、配置和訪問控制，以確保代碼在構建和部署過程中的完整性。

確保通過特定形式的完整性檢查或數字簽名來檢測序列化數據是否存在篡改或重播，所有未簽名或未加密的序列化數據不會發送到不受信任的客戶端。

A09：2021-安全日志和監控故障Security Logging and Monitoring Failures

常見CWE(弱點枚舉)

CWE-778 Insufficient Logging（日志記錄不足）

CWE-117 Improper Output Neutralization for Logs（日志輸出不當）

CWE-223 Omission of Security-relevant Information（安全事件信息漏報）

CWE-532 Insertion of Sensitive Information into Log File（在日志文件中包含敏感信息）

風險說明

如果不進行日志記錄和監測，就無法發現違規行為。任何時候都會發生日志記錄、檢測、監視和主動響應不足的情況:

需要審計的事件，例如：登錄、失敗的登錄和高價值交易，但未記錄。

警告和錯誤未生成日志或日志記錄不充分或日志消息不清晰。

應用程序和 API的日志未進行安全可疑活動的監控。

日志只存儲在本地。

適當的警報閾值和響應升級過程不到位或無效。

滲透測試和動態應用安全測試（DAST）工具（例如：OWASP ZAP）的掃描沒有觸發警報。

應用無法實時或接近實時地檢測、升級或或對主動攻擊發出警報。

如果讓用戶或攻擊者看到日志和警報事件，您就容易受到信息泄露的攻擊（查看“A01:2021-失
效的訪問控制”）。

預防措施

開發人員應根據應用的風險，實施以下部分或全部控制：

確保所有的登錄、訪問控制和服務器端輸入驗證失敗都可以被記錄在足夠的用戶上下文中，以識別可疑或惡意的帳戶，并保留足夠的時間以允許延遲的取證分析。

確保日志是日志管理解決方案以方便使用的格式生成的。

確保日志數據被正確編碼加密，以防止對日志或監控系統的注入或攻擊。

確保高價值交易有完整性控制的審計跟蹤，以防止篡改或刪除，例如：只附加數據庫表或類似的內容。

DevSecOps團隊應該建立有效的監控和警報，以便發現可疑的活動并迅速做出反應。

建立或采用事故應對和恢復計劃，例如：美國國家標準技術研究所(NIST)800-61r2或更高版本。

有一些商業和開源的應用程序保護框架，如：OWASP ModSecurity核心規則集，以及開源的日志相關軟件，如：Elasticsearch、Logstash、Kibana（ELK），具有自定義儀表盤和告警功能。

A10：2021-服務端請求偽造 Server-Side Request Forgery

風險說明

一旦Web應用在獲取遠程資源時沒有驗證用戶提供的URL，就會出現SSRF缺陷。它允許攻擊者強制應用程序發送一個精心構建的請求到一個意外目的地，即使是在有防火墻、VPN或其他類型的網絡訪問控制列表（ACL）保護的情況下。

隨著現代Web應用為終端用戶提供便利的功能，獲取URL成為一種常見的場景。因此，SSRF安全攻擊事件也在不斷增加。此外，由于云服務和架構的復雜性，SSRF的嚴重性也越來越高。

預防措施

開發者可以通過實現以下部分或全部防御手段，縱深防御來阻止 SSRF:

網絡層防御建議：

在隔離的網絡中設置多個遠程資源訪問功能的網段，以減少SSRF的影響。

執行“默認拒絕”防火墻策略或網絡訪問控制規則，以阻止除必要的內部網通信外的所有通信。
提示: 建立基于應用的防火墻規則的所有權和生命周期。

在防火墻上記錄所有接受和阻止的網絡流(參見“A09:2021-安全日志和監控故障”)。

應用層防御建議：

檢查和驗證所有客戶端提供的輸入數據。

使用白名單允許列表允許列表執行URL統一資源標志符、端口和目標。

不要給客戶端發送原始的回復。

禁用 HTTP 重定向。

注意URL的一致性，以避免DNS重新綁定和“檢查時間，使用時間”(TOCTOU)競爭條件等攻擊。

不要通過使用黑名單拒絕列表或正則表達式來緩解SSRF。攻擊者擁有有效載荷列表、工具和繞過拒絕列表的技能。

需額外考慮的措施:

不要在前端系統上部署其他與安全相關的服務（如：OpenID）。控制這些系統上的本地流量（如：localhost）。

對于專用和可管理的前端用戶，可以在獨立系統上使用網絡加密（如：vpn）來滿足非常高的安全保護需求。

總結

以上是生活随笔為你收集整理的2021年OWASP-TOP10的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。