「輸入一個 URL，就幫你把裡面的內容取回來」——這種隨處可見的便利功能，在最壞的情況下會成為雲端金鑰被奪走的入口。這就是 SSRF。本文從零講解它的原理與防禦。
到底發生了什麼
正常的存取是「使用者 → 外部網站」。而 SSRF 則是把伺服器當成代理，讓它去存取「內部」。由於伺服器能夠觸達從外部看不見的內部網路，或雲端的憑證提供端，攻擊者就能藉此間接窺探這些地方。
169.254.169.254（雲端憑證）在雲端環境中，從這個內部目標（中繼資料提供端）有可能取到 臨時憑證。一旦透過 SSRF 到達那裡，金鑰就會被奪走，進而連鎖導致整個儲存空間被匯出。這在現實中已經釀成了大規模事故。→ Capital One —— SSRF 導致 1 億人資訊外洩的事件
它潛藏在哪裡
「伺服器去取得使用者輸入的 URL」這類功能全都是候選對象。
| 功能 | 常見的實作方式 |
|---|---|
| OG / 連結預覽產生 | 伺服器取得被貼上的 URL 並產生縮圖 |
| Webhook 傳送 | 伺服器向使用者指定的目標發起 POST |
| 圖片・檔案匯入 | 「從 URL 取得圖片」 |
| 網站診斷工具 | 伺服器存取所輸入的網站並進行檢查 |
驗證時常被忽略的坑
只做到「攔截內部 IP 就行」是不夠的。下面這些繞過路徑必須堵住。
只做簡單攔截會有漏洞
- 重新導向跟隨：被允許的網域用
302跳轉到內部位址。 - DNS 重新解析（rebinding）：校驗時是外部 IP，取得時切換成內部 IP。
- IP 寫法的變體：用十進位、八進位、縮寫寫法等來偽裝內部位址。
- 其他協定：
file://或gopher://等意料之外的協定。
功能開發方應有的防禦
SSRF 要靠「功能的實作方式」來防禦。這也是本站作為安全產品對自家診斷功能所施加的規則。
目標採用 allowlist 方式
將協定（http/https）和主機只限定為已允許的那些。「只放行允許的」比「攔截內部的」更穩妥。
阻斷內部目標
拒絕對 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254（中繼資料）等的存取。
只限已確認所有權的網域（診斷類）
只針對使用者已證明所有權的網域。不讓它去存取第三方網站。
堵住繞過路徑與中繼資料
對重新導向的最終落點也要校驗，並考慮 DNS 重新解析。雲端上則透過 IMDSv2 等方式，讓存取中繼資料必須帶 token。
本站把「不替使用者保管祕密」「只診斷已確認所有權的目標」「把爆炸半徑降到最小」作為設計的基石（→ 關於本站）。
接下來閱讀
FAQ
Q哪些功能容易出現 SSRF？
「伺服器去取得使用者輸入的 URL」這類功能。例如 OG 預覽產生、Webhook 傳送、圖片匯入、網站診斷工具等。越是便利的功能越需要小心。
Q為什麼 SSRF 在雲端環境中尤其危險？
因為雲端上的虛擬機器有一個僅限內部存取的「中繼資料提供端」，從那裡可能取到臨時憑證。一旦透過 SSRF 到達那裡，金鑰就會被奪走，進而連鎖導致整個儲存空間被匯出（這正是 Capital One 事故的路徑）。
Q如何防禦 SSRF？
用 allowlist 嚴格校驗目標，並阻斷對內部 IP（127.0.0.1、10.x、169.254.169.254 等雲端中繼資料）的存取。如果是診斷類功能，則只限定為「已確認所有權的網域」，同時堵住重新導向跟隨和 DNS 重新解析的繞過路徑。