搜尋文件

輸入關鍵字,搜尋標題與正文。

    Web 應用資安文件 09/13

    SSRF 與伺服器對外請求邊界

    本文提要

    當筆記服務提供「貼上網址自動產生連結預覽」、「從遠端網址匯入圖片」或「事件發生時呼叫使用者設定的 Webhook」時,發起網路請求的不再是使用者的瀏覽器,而是應用伺服器自己。 如果伺服器沒有嚴格驗證與隔離這個目標位置,攻擊者就能利用伺服器當跳板,向外部無法直接連入的內部網路或本機介面發送請求,這就是伺服器端請求偽造(Server-Side Request Forgery,SSRF)。

    18px · 寬鬆行距

    閱讀設定

    排版預覽 · 示範文字(可捲動)

    檔案與目錄

    Linux 以一棵從根目錄 / 開始的樹狀結構組織檔案。目錄用來整理檔案,也可以包含其他目錄。

    pwd
    ls -la /home
    18px

    16、18、20、22px;隨瀏覽器文字大小縮放。

    欄寬套用於背景文章;此處預覽字級與行距。手機正文自動配合螢幕。

    文件與本文目錄
    本主題文件

    當筆記服務提供「貼上網址自動產生連結預覽」、「從遠端網址匯入圖片」或「事件發生時呼叫使用者設定的 Webhook」時,發起網路請求的不再是使用者的瀏覽器,而是應用伺服器自己。 如果伺服器沒有嚴格驗證與隔離這個目標位置,攻擊者就能利用伺服器當跳板,向外部無法直接連入的內部網路或本機介面發送請求,這就是伺服器端請求偽造(Server-Side Request Forgery,SSRF)。

    先備概念見信任邊界與威脅思考、Linux 網路基礎與 VPC 與資源連線。 查證日期:2026-11-03。依 OWASP SSRF Prevention Cheat Sheet 與 MITRE CWE-918 整理。 本次僅查證文件,未部署應用或發起探測請求;以下為自創的筆記連結預覽情境。

    SSRF 借用的是伺服器所在的網路位置與身分

    外部使用者直接從網際網路連線時,防火牆與私有子網路會擋下連往內部管理介面、快取服務或本機連接埠的封包。 但應用伺服器本身就位在內部網路裡;只要應用伺服器接受使用者傳來的 url 參數並照單全收地發出請求,原本的邊界防火牆就不再能替內部服務擋住這個請求。 參考 MITRE CWE-918:Server-Side Request Forgery (SSRF)。

    圖解
    攻擊者 ──→ POST /preview { "url": "http://127.0.0.1:8080/admin" }
                   │
                   ▼
            筆記應用伺服器(位於私有網路內)
                   │ 以伺服器自身的網路位置發出請求
                   ▼
            本機管理埠、內網服務或雲端 Instance Metadata
    

    在雲端環境中,常見的高風險目標還包括執行個體中繼資料服務(例如透過連結本機位址 169.254.169.254 提供的中繼資料與臨時憑證入口)。 即使伺服器不會把取得的回應全文直接顯示給使用者(常稱 Blind SSRF),攻擊者仍可能透過回應時間差、錯誤狀態碼,或觸發內部無須額外驗證的管理端點造成實質影響。

    為什麼只用字串檢查網址常常不夠

    許多初步修補會嘗試「如果網址包含 localhost 或 127.0.0.1 就拒絕」,但這種純文字黑名單非常容易被繞過:

    表格・3 欄 4 列
    繞過面向常見失效原因為何字串檢查擋不住
    名稱解析(DNS)攻擊者註冊一個外部網域,將其 A / AAAA 紀錄指向 127.0.0.1 或私有 IP網址字串看起來是一般外部網域,解析後的實際連線位址才是內網
    DNS Rebinding第一次解析檢查時回傳合法公開 IP,緊接著發起連線時因很短的 TTL 改回傳內網 IP「檢查時解析的結果」與「HTTP 用戶端實際連線時解析的結果」不是同一次
    HTTP 重新導向(Redirect)初始網址是合法外部網站,但回應 302 Found 指向 http://127.0.0.1/...若 HTTP 用戶端自動跟隨轉址,第二跳目標未重新經過內網位址檢查
    URL 解析器差異與替代表示法不同程式庫對特殊 authority、IPv6 表示法或非標準 IP 格式解讀不一致驗證邏輯看到的 host 與底層連線庫實際連往的 host 不同

    因此,只檢查輸入字串表面長相,無法保證最終建立 TCP 連線的目標位址真的是公開網際網路上的合法主機。 參考 OWASP Server-Side Request Forgery Prevention Cheat Sheet。

    應用層與網路層的分層防護

    先問一個根本問題:這個功能真的需要連往任意外部網址嗎? 如果業務其實只需要連往固定幾個合作服務,最穩健的做法是不接受使用者傳入完整 URL,而是由伺服器根據白名單設定決定連線目的地。

    若像「筆記連結預覽」這類功能確實需要讀取未知的公開網站,則必須同時在應用層與網路層設下防護,不能只靠單一層:

    1. 應用層請求控制

    • 限制協定與連接埠:只允許 http: 與 https:(或僅 https:),拒絕 file:、gopher: 等其他 URI scheme,並限制標準連接埠。
    • 綁定解析後的目標 IP 檢查:在建立連線時確認解析出的 IPv4/IPv6 位址不屬於迴路位址(loopback)、私有網路、link-local(如 169.254.0.0/16 與 fe80::/10)等保留範圍,且讓實際連線直接使用該已驗證的 IP,避免 DNS rebinding。
    • 嚴格處理轉址與回應:關閉無條件自動跟隨轉址,或對每一跳轉址目標重新執行完整驗證;同時限制連線逾時、讀取大小與允許的回應媒體類型,且不將原始錯誤堆疊或內部回應原封不動吐回前端。

    2. 網路層與執行環境隔離

    應用層程式庫仍可能因設定疏漏而漏判,因此應在網路與主機環境補上硬邊界:

    • 將負責讀取外部網址的工作隔離:由專用的代理或獨立無狀態 worker 執行對外讀取,不讓它所在的子網路具備連入資料庫、內部管理後台或敏感微服務的路由與防火牆權限。
    • 出口流量(Egress)預設拒絕私有網段:在作業系統防火牆、容器網路策略或雲端網路規則上,明確禁止對外讀取元件連往內部私有 CIDR 與本機管理服務。
    • 強化雲端環境保護並遵守最小權限:加固執行個體中繼資料存取要求(例如限制需先取得具備跳數限制的 session token),並確保運算資源掛載的 IAM 身分與權限 只具備最小必要範圍,降低萬一憑證外洩時的影響半徑。

    相關文件