> ## Content Index
> Fetch the complete content index at: https://taiwanding.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 從一個 URL 輸入框到內網漫遊：Bug Bounty 獵人的 SSRF 方法論
- URL: https://taiwanding.com/cong-yi-ge-url-shu-ru-kuang-dao-nei-wang-man-you-bug-bounty-lie-ren-de-ssrf-fang-fa-lun/
- Published: 2026-02-26T08:37:14.000Z
- Updated: 2026-07-15T02:50:26.000Z
- Author: Kevin Chen
- Tags: #ssrf, #knowledge, Bug bounty

聲明：本文僅供授權測試與自建實驗環境使用，請勿對未經授權的系統進行測試或利用，進行 Bug Bounty 時務必遵守該計畫的 scope、rate limit 與 disclosure policy。

## 為什麼你該關注 SSRF

你在測試一個社群平台，發現它有「貼上連結自動產生預覽卡片」的功能，你貼了一個網址，伺服器乖乖地跑去幫你抓網頁標題和縮圖回來。

問題是：伺服器替你發了這個請求，但它「可以去哪裡抓」、以及「允許用什麼 scheme 抓」，真的有被限制嗎？

這就是 Server-Side Request Forgery（SSRF）的核心：當伺服器根據用戶輸入去發起出站請求，但沒有對目標位址做正確驗證時，攻擊者就有機會讓伺服器存取非預期資源（內網服務、雲端 metadata、本地檔案等）。在 Bug Bounty 裡，SSRF 常常不是終點，而是一個放大器：它把原本外部碰不到的東西，變成你可以間接觸及的資產。

本文面向 Bug Bounty 獵人，聚焦在兩件事：

1. 怎麼系統性地找到 SSRF
2. 怎麼評估影響範圍，把「能發請求」推進到「具體風險」  
同時也從防禦角度解釋：為什麼某些設計容易產生 SSRF，以及該怎麼修。

## 哪些功能藏著 SSRF

不是只有 URL 預覽才會出 SSRF。任何讓伺服器「根據你的輸入去抓東西」的功能都值得懷疑，特別是出站 fetch 發生在後端、且你能控制目標位址的情境。

常見高風險功能點：

1. URL 預覽 / Link Unfurling  
論壇、CMS 都有，你貼一個連結，伺服器去抓 Open Graph 或其他 meta（例如 og:title、og:image）回來渲染卡片，伺服器本來就預期要抓外部資源，但如果沒有限制可以抓哪裡，就會變 SSRF。
2. 圖片處理 / 縮圖 / 轉檔  
用戶提供圖片 URL，後端做裁剪、濾鏡、縮圖，只要後端會「幫你抓 URL」，就可能成為 SSRF。  
另外也要注意 SVG：SVG 本質上是 XML/向量格式，可能引用外部資源；如果後端會解析、渲染或轉檔，容易變成非預期出站請求的觸發點。
3. PDF 生成 / 網頁轉 PDF  
「輸入網址轉成 PDF」是重災區，若後端渲染引擎會處理完整 HTML/JS 或載入外部資源，攻擊者可能透過可控內容觸發對任意 URL 的請求，並讓結果被渲染進 PDF 中帶出（視引擎與限制而定）。
4. Webhook 設定 / 第三方整合  
SaaS 平台常讓你填一個 URL，事件觸發時伺服器主動打過去，只要目標位址可控、沒有嚴格 allowlist，就可能是 SSRF，更麻煩的是，有些平台會在 delivery log 顯示回應摘要，讓 SSRF 從 blind 變成可回顯。
5. OAuth / OpenID Connect（OIDC）  
伺服器需要去 authorization server 拿 token、抓 discovery 設定、抓 key（例如 jwks），如果 discovery URL、token endpoint 或 key endpoint 被用戶側間接控制（或被重導/注入），就可能形成 SSRF 或多階段的 SSRF 風險。
6. RSS / Feed 匯入  
用戶提供 RSS/Atom URL，伺服器抓 XML 解析，這裡同時可能出現 SSRF 與 XXE 的攻擊面，常常值得一起評估。

### 快速定位 SSRF 入口

用最省時間的方式做第一輪篩選：

1. 參數面搜尋（HTTP history / crawler 結果）  
關鍵字通常長這樣：  
url, uri, href, src, redirect, callback, fetch, preview, proxy, load, endpoint, dest, target, link, feed, webhook, import
2. UI/功能面掃描  
優先看：  
integrations、notifications、import/export、preview、media processing、document generation、webhook management
3. 一個很直覺的判斷  
如果某個參數值是完整 URL（包含 scheme），或看起來會被後端拿去抓取資源，它就值得深入測試。

## URL Scheme 的威力：為什麼 SSRF 不只是「能打 HTTP」

很多人談 SSRF 只盯著 http/https，但真正讓影響範圍暴增的，是後端對 URL scheme 的支援程度與限制方式。

1. http:// / https://  
基本款。若伺服器沒有限制出站請求的目標，攻擊者可能探測內網服務、觸及受限管理介面，或在雲端環境嘗試觸及 link-local 上的 metadata service。  
重要的是：能不能造成憑證或敏感資訊暴露，取決於雲端平台的防護措施（例如是否強制 token、是否有網路層阻擋、應用是否能讀到並回傳內容）。
2. file://  
若後端 URL client 支援 file scheme（或有類似本地資源載入能力），就可能讓 SSRF 升級成讀取本地檔案的風險，等同 Local File Inclusion。實際可讀到什麼，取決於執行權限、sandbox、路徑限制與回顯能力。
3. gopher://  
若環境支援 gopher（很多現代環境其實會禁掉或不支援），它的危險在於：SSRF 可能從「抓 HTTP 資源」升級成「對內網 TCP 服務的任意互動風險」，  
在內網存在未授權或弱配置的服務（例如缺少驗證的管理介面、快取服務、資料庫、內部 agent）且網路隔離不足時，潛在影響可能從資料洩漏一路升級到高風險操作（最壞情況包含任意指令執行），是否能達到最壞情況，取決於服務本身配置與 network segmentation。

防禦啟示：如果業務只需要抓 HTTP(S)，在程式碼層把 scheme 白名單硬限制為 http/https，是最基本也最划算的一刀。它能直接封死大量高風險利用路徑。

## 確認 SSRF 的方法論

這裡用一個核心目標來思考：你不是在「跑流程」，你在回答三個問題

1. 伺服器是否真的會發出請求？
2. 請求結果是否會回到你手上？
3. 它最壞能碰到什麼、造成什麼後果？

### Step 1：確認伺服器會發出請求

找到可疑的 URL 參數後，先做出站行為確認。

最可靠的方式是 Out-of-Band（OOB）驗證：

- 把目標 URL 指向你控制的端點或 OOB 平台（例如 Burp Collaborator、interactsh）
- 觀察是否收到 DNS query、HTTP request 或其他協議層面的回連

只要你能確認「請求由目標伺服器發出」，就能把 SSRF 這件事從猜測變成事實。

注意：某些情境會有快取、非同步處理、延遲抓取、或只在特定條件才抓取（例如只抓圖片、只允許特定 content-type）。你要做的是耐心地把觸發條件摸清楚。

### Step 2：判斷回顯類型（這一步決定利用空間）

兩種典型型態：

1. 帶回顯（Non-blind）  
伺服器抓到的內容會以某種形式出現在回應中，或可被你觀察到：
- URL 預覽直接顯示 title/description/縮圖
- 圖片處理把抓到的圖片渲染/回傳
- PDF 生成把結果渲染進 PDF  
這種情況最有價值，因為你能看到伺服器存取的資源內容或至少看到差異。
1. Blind  
回應只告訴你成功/失敗，沒有內容，此時就改用間接證據來推斷：
- 回應差異：不同目標可能導致不同 status code、回應大小、錯誤訊息
- 時間差異：不同目標可能導致不同延遲（連線逾時、立即拒絕、正常回應）
- DNS 推斷：即使 HTTP 回應一致，DNS 查詢是否發生仍可提供線索

### Step 3：評估影響範圍（Bug Bounty 能否成立的關鍵）

確認 SSRF 存在後，下一步不是「立刻開始掃」，而是用成本最低的方法回答影響問題，讓你能寫出有份量的 report。

你可以嘗試回答：

1. 是否能觸及雲端 metadata service（或其他敏感 link-local 端點）？  
如果能取得雲端身分憑證或其他敏感資訊，嚴重性可能直接躍升（但務必依 scope 與計畫允許程度行事）。
2. 是否能存取內網管理介面或內部 API？  
重點不是「你能連到」，而是「是否構成未授權存取」或「是否能取得敏感資訊」。
3. 是否存在本地檔案讀取風險（僅當環境/客戶端支援相關能力）？  
若應用把抓取結果回顯或渲染出去，風險會更明確。
4. 是否能與非 HTTP 服務互動（同樣取決於 scheme/客戶端支援與網路隔離）？  
這通常是高風險升級路徑，但也最依賴環境條件。
5. 回應差異是否足以做資產存在性推斷？  
即使看不到內容，只要能穩定推斷「某服務存在/某資源存在」，就可能提升風險評估（也同時要注意不要造成過度探測或違反規範）。

關鍵句：影響範圍越大，report 的價值越高，反之，如果只能證明「伺服器打到了我的 OOB」，卻無法展示任何進一步風險，很多計畫會判定 impact 不足。

## Blind SSRF：Bug Bounty 的殘酷現實

很多計畫會把 blind SSRF 標成 Informational，甚至直接 N/A。原因很現實：審查員需要看到可證明的 impact。

blind SSRF 想寫出有份量的報告，重點是把 SSRF 放回「攻擊面放大器」的定位：

- 你能觸及哪些內部資源或端點（以可證明、可重現、低噪音的方式）
- 這些端點為什麼敏感（管理介面、內部 API、敏感資訊聚集點）
- 在合理威脅模型下，最壞可能造成什麼後果（但避免過度臆測；把前提條件講清楚）

投 report 前一定要先讀 scope：如果 program 明確寫了 “SSRF with no impact is out of scope”，那你就要把證據做足再投，不然很容易浪費時間。

## 結語

SSRF 的攻擊面比大多數人想像的要廣，從 URL 預覽到 webhook，從 PDF 生成到 OAuth flow，凡是伺服器會根據你的輸入去「抓東西」的地方，都值得測試。

對 Bug Bounty 獵人來說，核心方法論是：  
找到帶完整 URL 的參數 → 用 OOB 確認出站請求 → 判斷回顯類型 → 用最小成本評估影響範圍並形成可證明的風險敘述。把 SSRF 從「能發請求」推進到「能造成什麼後果」，你報告的含金量就會上去。

對開發者和資安團隊來說，SSRF 的防禦需要 Defense in Depth：應用層的 scheme 白名單與 DNS 後驗證是地基，網路層的 egress policy 與 segmentation 才是兜底。兩者一起做，才能把 SSRF 的風險真正壓下來。

Happy Hunting！