伺服器端請求偽造 (SSRF)

示例場景

假設您的應用程式有一個端點，可以從提供的 URL 獲取圖片。

GET /fetch-image?url=https://example.com/image.png

伺服器可以訪問公司的內網。

如果伺服器不對提供的 URL 引數進行驗證，那麼客戶端可以透過將內網 URL 傳遞給 API 來提取敏感資料。

fetch("https://example.org/fetch-image?url=https://:443/admin/org.png");

儘管客戶端無法直接訪問 https://:443/，但伺服器可以，並且伺服器會將響應中繼給客戶端。

客戶端不必發起 HTTP 請求：它可能可以使用 file:// 協議。

fetch("https://example.org/fetch-image?url=file:///etc/passwd");

在這些情況下，攻擊者可以獲取對敏感資料的訪問許可權。有時攻擊者無法獲得響應正文，但在這種情況下仍然可能造成問題。

• 透過強制伺服器發出大量請求，攻擊者可以執行 拒絕服務 (DoS) 攻擊。
• 透過檢查伺服器返回的狀態碼或請求的執行時間，攻擊者可能會推斷出有關目標的敏感資訊。

攻擊者可能會使用重定向或重定向鏈來規避驗證。例如，他們可能擁有一個域名 https://evilexample.org/redirect，而該主機所做的就是重定向到 https://:443/ 或其他（內部）URL，從而可能繞過輸入驗證。

fetch("https://example.org/fetch-image?url=https://evilexample.org/redirect");

SSRF 的防禦措施

緩解 SSRF 漏洞需要多種防禦策略，結合輸入驗證、謹慎的響應處理和安全的網路架構。一些關鍵方法包括：

輸入驗證和白名單

限制伺服器 API 將使用的 URL。例如，上面討論的 fetch-image 服務可以指定一個包含預期域名的白名單。

const ALLOWED_DOMAINS = ["https://api.example.com", "https://cdn.example.com"];

阻止協議和 URL 方案

確保只允許特定的 URL 方案。對於常規 Web 應用程式，很可能只允許 https:// 就足夠了。

重定向驗證

不要自動遵循重定向，同時也要對重定向的 URL 執行輸入驗證和/或白名單。限制重定向鏈。

最小許可權和隔離

確保執行出站請求的服務不擁有超出其所需的任何許可權，並避免將具有請求能力的伺服器與敏感的內部服務進行共置。

防禦總結清單

• 審查所有獲取資源的功能，並驗證或白名單使用者輸入。
• 阻止除 HTTPS 之外的所有協議。
• 警惕 URL 重定向並限制重定向鏈。
• 對伺服器網路許可權應用最小許可權原則：理想情況下，除非必要，否則伺服器不應擁有對內部網路的無限制訪問許可權。
• 記錄和監控請求。

另見

• 伺服器端請求偽造防範備忘單