title: 【轉載】服務端請求偽造（SSRF）是什麼？
date: 2021-08-14 09:01:57
comment: false
toc: true
category:
- 分享
tags: - 服務端
- 偽造
- SSRF
- 請求
本文轉載自：服務端請求偽造（SSRF）是什麼？
- 原文地址：What is Server-Side Request Forgery (SSRF)?
- 原文作者：Ian Muscat
- 譯文出自：掘金翻譯計劃
- 本文永久鏈接：github.com/xitu/gold-m…
- 譯者：MoonBall
- 校對者：PassionPenguin、kamly
服務端請求偽造（SSRF）漏洞讓攻擊者從存在漏洞的應用程序的後端服務中發送惡意請求。攻擊者通常使用 SSRF 攻擊位於防火牆之後的內部系統，這些內部系統是不能從外部網絡訪問的。攻擊者也可以利用 SSRF 訪問通過伺服器的環回接口（(127.0.0.1）可訪問的服務。
當攻擊者可以完全控制或部分控制應用程序發送的請求時，SSRF 漏洞就出現了。常見的例子是攻擊者能控制第三方服務的 URL，並且應用程序將發起該 URL 對應的請求。
以下是一個 PHP 例子，它易遭受 SSRF 攻擊。
<?php
/**
* 檢查是否設置了 GET 變量 'url'
* 例如 - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif
*/
if (isset($_GET['url'])){
$url = $_GET['url'];
/**
* 發起易遭受 SSRF 攻擊的請求因為
* 在發起請求之前
* 沒有對 $url 做驗證
*/
$image = fopen($url, 'rb');
/**
* 發送正確的響應頭
*/
header("Content-Type: image/png");
/**
* 響應圖片的內容
*/
fpassthru($image);}
在上面的例子中，攻擊者可以完全控制 url 參數。攻擊者可以向因特網上的任意網站和被攻擊伺服器（localhost ）上的資源發起 GET 請求。
在下面的例子中，攻擊者向 Apache HTTP 服務發起一個請求。該 Apache HTTP 服務開啟了 mode_status 模式（該模式默認是開啟的）。
GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com
攻擊者也可以使用 SSRF 向 web 伺服器有權訪問的其他內部資源發出請求，儘管它們不是公開可訪問的。例如，攻擊者可以訪問類似 AWS/Amazon EC2 和 OpenStack 的雲服務實例的元數據。攻擊者甚至可以利用 SSRF 發揮創意，對內部 IP 進行端口掃描。
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com
除了 http:// 和 https:// URL 協議之外，攻擊者可以利用鮮為人知的或古老的 URL 協議訪問本地系統或內部網絡上的文件。
下面的例子使用了 file:/// 協議。
GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com
部分應用可能允許攻擊者使用更多奇怪的 URL 協議。比如，如果應用使用 cURL 發起請求，那麼攻擊者可以使用 dict:// URL 協議向任意的主機和端口發起請求，並發送自定義數據。
GET /?url=dict://localhost:11211/stat HTTP/1.1
Host: example.com
上面的請求使得應用程序連接 localhost 的 11211 端口，並發送 stat 字符串。端口 11211 是 Memcached 的默認端口，該端口通常不會對外暴露。
檢查服務端請求偽造#
為了自動檢測服務端請求偽造，你需要使用一個中間服務，因為檢查這種漏洞需要一種外部可訪問的並存在時延的方式。Acunetix 通過將 AcuMonitor 作為中間服務解決該問題。
在掃描期間，Acunetix 向不同的 AcuMonitor URL 發起請求。如果 AcuMonitor 在這些不同的 URL 中收到一個請求，它將通知 Acunetix。然後 Acunetix 經發出 SSRF 警報。
下圖是使用 AcuMonitor 的 Acunetix 掃描結果，它檢查了服務端請求偽造。該警報包含 HTTP 請求的信息。它包括發起請求的伺服器 IP 地址和請求中攜帶的 User-Agent 字符串（如果存在）。這些信息可以幫助開發者定位問題源頭並修復問題。
消除服務端請求偽造#
將簡單的黑名單和正則表達式應用於用戶輸入是一種消除 SSRF 攻擊的糟糕方法。通常，黑名單是一種幾乎無效的安全控制手段。因為攻擊者總是可以找到方法去繞過它們。在這個例子中，攻擊者可以使用 HTTP 重定向、通配符 DNS 服務（比如 xip.io ）或者甚至是 可替代的 IP 編碼實現繞過黑名單。
白名單和 DNS 解析#
最穩健的避免服務端請求偽造的方式是將你的應用需要訪問的 DNS 名稱和 IP 地址添加到白名單中。如果白名單機制不能滿足你的需求，並且你必須依賴黑名單機制，那麼對用戶輸入進行合理的校驗就顯得非常重要。比如，不允許向私有的 IP 地址發起請求（私用 IP 地址參考 RFC 1918）。
然而，在使用黑名單的場景中，正確的消除 SSRF 的方式將因應用而異。換句話說，沒有使用黑名單機制修復 SSRF 漏洞的銀彈，因為它高度依賴應用功能和業務需求。
處理響應#
避免響應數據洩露給攻擊者，你必須確保收到的響應是期望的內容。在任何情況下，都不應將伺服器發送的請求的原始響應體傳遞給客戶端。
禁用不使用的 URL 協議#
如果你的應用僅使用 HTTP 或 HTTPS 發起請求，那麼就只允許這些 URL 協議。如果你禁用掉不使用的 URL 協議，攻擊者將不能使用具有潛在危險的協議發起請求，比如：file:/// , dict:// , ftp:// 和 gopher:// 。
內網服務進行身份認證#
默認情況下，類似於 Memcached、Redis、Elasticsearch、MongoDB 的服務不要求身份認證。攻擊者可以利用服務端請求偽造漏洞，無需身份認證便能訪問這些服務。因此，為了確保應用程序的安全，最好儘可能啟用身份認證，即使是本地網絡上的服務。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久鏈接 即為本文在 GitHub 上的 MarkDown 鏈接。
掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章来源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。