貼上 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。
本站把「不替使用者保管祕密」「只診斷已確認所有權的目標」「把遭入侵時可能造成的損害降到最小」作為設計的基礎（→ 關於本站）。
SSRF、CSRF 與開放重新導向的比較
這三者都牽涉「由外部指定的目標」，但移動的主體與能觸及的範圍不同。
| 攻擊 | 誰前往哪裡 | 能觸及什麼 |
|---|---|---|
| SSRF | 你的伺服器向被指定的目標送出請求 | 從外部無法觸及的地方，例如內部網路與雲端憑證 |
| CSRF | 使用者的瀏覽器送出使用者無意送出的請求 | 使用者在已登入網站上能做的事 |
| 開放重新導向 | 使用者的瀏覽器被轉送到被指定的外部網站 | 假網站（網路釣魚） |
SSRF 特別危險，是因為它觸及的是「伺服器的內部」。防火牆對外保護的地方，經由伺服器仍然可能被觸及。
實際案例：也潛藏在框架的功能裡
SSRF 不只出現在自己寫的「取得這個 URL」功能中，也會出現在框架的功能裡。例如近年 Next.js 的 CVE 中，SSRF（CWE-918）是最常見的弱點類型之一，出現在圖片最佳化等會去取得外部圖片的伺服器功能中（→ 從實際資料看 Next.js 與 React 的漏洞，英文）。在 MITRE 於 2025 年 12 月公布的「CWE Top 25」（最危險的 25 種軟體弱點）中，SSRF 排名第 22。
雲端方面，Capital One 外洩事件是標準案例。SSRF 觸及了中繼資料服務，權限過大的臨時憑證被竊。AWS 在 2019 年 11 月推出 IMDSv2，就是為了減輕這類損害。
如何檢查自己的環境
列出所有會去取得指定 URL 的地方
在程式碼中搜尋目標可能含有使用者輸入的 HTTP 用戶端（fetch、axios、requests 等）。連結預覽、Webhook、圖片匯入、PDF 產生與匯入功能都是典型位置。
確認框架的允許設定
在圖片最佳化或外部取得的設定中，確認允許的主機不會太寬（Next.js 的話，確認 images.remotePatterns 裡沒有只用萬用字元的項目）。
強制使用 IMDSv2（AWS）
在每台 EC2 執行個體的中繼資料選項中，確認 HttpTokens 為 required（僅限 IMDSv2）。不執行容器的伺服器，請把權杖回應的 hop limit 維持在 1。
限制伺服器的對外流量
把取得 URL 的程式放在連不到內部網路的獨立環境執行，或把對外流量限制在必要的目標。即使 App 的校驗有遺漏，網路層仍能擋下。
出處（一手資料）
- OWASP, "Server-Side Request Forgery Prevention Cheat Sheet" — cheatsheetseries.owasp.org（allowlist、阻斷內部位址、重新導向與 DNS 的處理）
- AWS, "Use the Instance Metadata Service to access instance metadata" — docs.aws.amazon.com（IMDSv2 工作階段權杖、required 設定、hop limit）
- AWS Security Blog, "Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service"（2019 年 11 月）— aws.amazon.com
- Microsoft, "Azure Instance Metadata Service" — learn.microsoft.com（Azure 也使用 169.254.169.254）
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses"（2025 年 12 月）— cwe.mitre.org（CWE-918 排名第 22）