伺服器端請求偽造（Server-Side Request Forgery，SSRF）讓攻擊者指使伺服器發出非預期的網路請求。它和 CSRF 都是「藉別人之手」的攻擊，但 CSRF 騙的是受害者瀏覽器，SSRF 騙的是目標應用伺服器。SSRF 的影響範圍取決於目標伺服器能存取的網路與服務。

「伺服器能對任意網址發出請求」不一定是漏洞——某些功能（如圖片預覽、Webhook、URL Preview）就是設計如此。發現一個能觸發外部請求的點時，重點是證明影響：能否打進內網、能否取出敏感資料。

證明 SSRF 影響的策略#

依照伺服器能存取的資源不同，SSRF 的價值可以差很多：

打進內網#

很多大型站台會用防火牆隔離公開伺服器與內網（如資料庫、metadata service）。若 SSRF 能讓你穿越這道牆：

  • 直接存取資料庫
  • 取得雲端 metadata（AWS、GCP、Azure）
  • 對私有 IP 發 HTTP 請求

對外請求 + 重定向繞限制#

如果只能對外不能對內，試試讓自家伺服器跟到 3xx 重新導向：

  • 把外部目標換成攻擊者控制的網址
  • 攻擊者回應 301/302/303/307 把伺服器導向 127.0.0.1 或內部 IP

黑名單繞過#

一些站只檢查「URL 結尾是不是某域名」——可註冊 attackerexample.com 通過末尾比對。

GET vs POST#

確認 SSRF 後再判斷可呼叫的方法：

  • POST：可能引發狀態變更（建立帳號、執行系統指令）——影響大但較複雜
  • GET：通常用於資料外洩

進階 POST SSRF 可參考 Orange Tsai 在 Black Hat 2017 的 A New Era of SSRF ↗。

Blind SSRF（盲注 SSRF）#

當你看不到伺服器發出去後拿回來的回應時，就是 Blind SSRF。利用方式：

利用回應時間#

對內部伺服器做埠掃描：

  • 開放 → 快速回應
  • 關閉 → 快速錯誤
  • 被過濾 → 連線逾時

常掃的埠：22（SSH）、80（HTTP）、443（HTTPS）、8080、8443。

利用 DNS（OOB Exfiltration）#

如果能誘發目標伺服器對你控制的網域做 DNS 查詢：

  • 把要外洩的資料當成子網域前綴放進去
  • 例如執行 whoami 後把結果放進 <output>.yourdomain.com
  • 因 URL 只允許英數字元，需用 base32 編碼結果

用 SSRF 攻擊使用者#

如果無法打進內網，可以反向利用 SSRF 對應用本身或其他使用者下手：

  • 讓 SSRF 端點抓你的伺服器，回傳含 XSS 或 SQLi payload 的 HTML
  • 若該回應被儲存（例如「設個人圖片」功能），即成 Stored XSS

案例 1：ESEA SSRF and Querying AWS Metadata#

漏洞描述#

研究者 Brett Buerhaus 用 Google Dork 搜尋：

site:https://play.esea.net/ ext:php

找到帶有 url= 參數的端點。試了：

  • ?url=http://ziot.org → 報錯「需是圖片」
  • ?url=http://ziot.org/1.png → 成功
  • 加 null byte（%00） → 失敗
  • 加雙斜線繞過 → 失敗
  • 把 /1.png 換成 ?1.png → 成功！變成 http://ziot.org?1.png，伺服器抓回 ziot.org 首頁

確認 SSRF 後，他和 Ben Sadeghipour 合作升級。Ben 提示試 AWS metadata：

http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/iam/security-credentials/

ESEA 跑在 AWS 上，回傳了內部主機名。iam/security-credentials/ 端點甚至可能洩漏 IAM 憑證——掌握後即可用 AWS CLI 操控帳號權限內所有服務。

AWS metadata service（169.254.169.254）是 SSRF 經典 PoC 對象——大多數雲服務有類似端點，找到 SSRF 後優先嘗試。

Takeaways#

  • Google Dork 能快速找到帶有特殊參數的舊頁面
  • 看到 url= 參數要警覺
  • 找到 SSRF 後想大一點——XSS 是小利用，AWS metadata 才是大事

案例 2：Google Internal DNS SSRF#

漏洞描述#

研究者 Julien Ahrens 看到 Google G Suite 工具箱有 dig DNS 查詢工具，且允許自訂 Name server。他先試：

Figure 10-1: 對 Google dig 工具的查詢範例

  • Name server 設為 127.0.0.1，查 rcesecurity.com
  • 回應為 「Server did not respond」——不是「permission denied」，意味著伺服器有試圖內部連線

錯誤訊息的微妙差異是 SSRF 的線索：「沒回應」 ≠ 「被拒絕」。

接著他用 Burp Intruder 列舉 10.x.x.x 範圍內的 IP，找到一個會回應的內部 DNS。再 brute force corp.google.com 的子網域，找到 ad.corp.google.com。對該內部 DNS 查詢這個子網域：

;ANSWER
ad.corp.google.com. 58 IN A 100.REDACTED
ad.corp.google.com. 58 IN A 172.REDACTED
...

公開 DNS 對同樣查詢會回 NXDOMAIN——他成功從外部讀到 Google 私有 DNS 資訊。順帶找到一台對外暴露的 minecraft.corp.google.com。

內部 IP 範圍清單#

找 SSRF 時優先測試這些保留 IP：

  • 10.0.0.0 ~ 10.255.255.255
  • 100.64.0.0 ~ 100.127.255.255
  • 127.0.0.0 ~ 127.255.255.255
  • 172.16.0.0 ~ 172.31.255.255
  • 192.0.0.0 ~ 192.0.0.255
  • 198.18.0.0 ~ 198.19.255.255

Takeaways#

看到網站功能會發出外部 HTTP 請求時，把目標指向 127.0.0.1 或上述保留 IP，看伺服器有沒有照單全收。

案例 3：Internal Port Scanning Using Webhooks#

  • 難度：易
  • URL：N/A
  • 回報日期：2017 年 10 月
  • 獎金：未公開

漏洞描述#

本書作者試一個提供 Webhook 的站台。送 http://localhost、http://127.0.0.1 都被擋；但用替代寫法 127.1、127.0.1 通過了——黑名單沒考慮非標準 IP 寫法。

https://www.psyon.org/tools/ip_address_converter.php?ip=127.0.0.1/ ↗ 列出多種等價寫法。

但只是「繞過 localhost 檢查」尚不足以拿獎金。作者改測「Web Integrations」功能：

  • 送 127.0.0.1 → 500 Unable to connect
  • 送 127.0.0.1:443 → 同樣 500
  • 送 127.0.0.1:8080 → 同樣 500
  • 送 127.0.0.1:22 → 503 Could not retrieve all headers ← 不一樣

503 表示連線成功但 HTTP 解析失敗（因為 22 是 SSH 而非 HTTP）。藉錯誤訊息差異，作者證明可以對該主機做 Port Scan。

Takeaways#

收到 webhook／URL preview／RSS 等可控的外部 URL 端點時：

  • 試 localhost 替代寫法
  • 試不同 Port，比較錯誤訊息或回應時間
  • 細微差異就是 Port Scanning 的本錢

章末總結#

  • SSRF 不是「能對外發 request」這麼簡單——重點是伺服器能碰到什麼資源
  • 高價值目標：AWS／雲端 metadata、內部 DNS、內部 API、Redis／Memcached
  • 受限時的繞過策略：3xx 重新導向、黑名單末尾比對、localhost 替代寫法、URL parser 差異
  • Blind SSRF 用時間差或 DNS OOB 推資料
  • 把 SSRF 結合 XSS／CSRF 等其他漏洞，可大幅提升嚴重度
Backward SQL 注入 XML 外部實體（XXE） Forward