SSRF 風險

SSRF 全名是 Server-Side Request Forgery，中文通常翻成伺服器端請求偽造。它的危險點在於：攻擊者不是直接從自己電腦打內網，而是誘導你的伺服器幫他去打。只要系統有「替使用者抓網址內容」這類功能，就值得特別留意。

典型長什麼樣

最常見的情境是程式接收一個 URL，然後伺服器去下載、預覽、轉檔或轉發資料。例如：

1. 貼一個圖片網址，系統幫你抓圖。
2. 給一個 webhook URL，系統主動回呼。
3. 輸入一個遠端 API 網址，系統代為請求。

如果這些網址完全信任使用者輸入，問題就來了。

為什麼危險

因為你的伺服器通常能看到比外部使用者更多的東西，例如：

1. 內網服務。
2. 127.0.0.1 或 localhost 上的管理介面。
3. 雲端環境中的 Metadata 服務。

攻擊者如果能讓你的系統去請求這些位置，就可能把原本不該暴露的資訊間接拿出來。

防禦重點

1. 不要直接信任完整 URL

如果可以，盡量不要讓使用者提供任意完整網址。改成只接受必要參數，再由系統自己組出要請求的目標，通常安全很多。

2. 做 allowlist，不要只做 denylist

與其一直擋 127.0.0.1、10.x.x.x、192.168.x.x 等私網段，不如反過來只允許已知可信的網域或服務。

3. 解析後還要檢查 IP

只看字串表面不夠，因為網域解析後可能仍然指向內網或保留位址，所以最好在 DNS 解析後再驗證一次。

常見誤區

1. 以為 regex 驗網址就夠了

Regex 只能幫你做格式檢查，不能解決目標位置是否安全這件事。

2. 只擋 localhost

真正危險的不只 localhost，還包括整批私網 IP、特殊位址與雲端 metadata 端點。

小結

SSRF 真正可怕的地方，是把你自己的伺服器變成攻擊跳板。只要系統會根據使用者輸入主動發出請求，就應該把目標驗證、網域 allowlist、IP 檢查和網路層限制一起納入設計，而不是只做表面字串過濾。