Web 安全 之 Server-side request forgery

Server-side request forgery (SSRF)

在本節中，咱們將解釋 server-side request forgery（服務端請求僞造）是什麼，並描述一些常見的示例，以及解釋如何發現和利用各類 SSRF 漏洞。

SSRF 是什麼

SSRF 服務端請求僞造是一個 web 漏洞，它容許攻擊者誘導服務端程序向攻擊者選擇的任何地址發起 HTTP 請求。

在典型的 SSRF 示例中，攻擊者可能會使服務端創建一個到服務端自身、或組織基礎架構中的其它基於 web 的服務、或外部第三方系統的鏈接。

SSRF 攻擊的影響

成功的 SSRF 攻擊一般會致使未經受權的操做或對組織內部數據的訪問，不管是在易受攻擊的應用程序自己，仍是應用程序能夠通訊的其它後端系統。在某些狀況下，SSRF 漏洞可能容許攻擊者執行任意的命令。

利用 SSRF 漏洞可能能夠操做服務端應用程序使其向與之鏈接的外部第三方系統發起惡意請求，這將致使潛在的法律責任和聲譽受損。

常見的 SSRF 攻擊

SSRF 攻擊一般利用服務端應用程序的信任關係發起攻擊並執行未經受權的操做。這種信任關係可能包括：對服務端自身的信任，或同組織內其它後端系統的信任。

SSRF 攻擊服務端自身

在針對服務端自己的 SSRF 攻擊中，攻擊者誘導應用程序向其自身發出 HTTP 請求，這一般須要提供一個主機名是 127.0.0.1 或者 localhost 的 URL 。

例如，假設某個購物應用程序，其容許用戶查看某個商品在特定商店中是否有庫存。爲了提供庫存信息，應用程序須要經過 REST API 查詢其餘後端服務，而其餘後端服務的 URL 地址直接包含在前端 HTTP 請求中。所以，當用戶查看商品的庫存狀態時，瀏覽器可能發出以下請求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

這將致使服務端向指定的 URL 發出請求，檢索庫存狀態，而後將結果返回給用戶。

在這種狀況下，攻擊者能夠修改請求以指定服務器本地的 URL ，例如：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

此時，服務端將會訪問本地 /admin URL 並將其內容返回給用戶。

固然，攻擊者能夠直接訪問 /admin URL ，可是這一般沒用，由於管理功能基本都須要進行適當的身份驗證，而若是對 /admin URL 的請求來自機器本地，則正常狀況下的訪問控制可能會被繞過。該服務端應用程序可能會授予對管理功能的徹底訪問權限，由於請求彷佛來自受信任的位置。

爲何應用程序會以這種方式運行，而且隱式信任來自本地的請求？這可能有多種緣由：

• 訪問控制檢查多是另外的一個微服務。當服務器鏈接自身時，將會繞過訪問控制檢查。
• 出於災難恢復的目的，應用程序可能容許來自本地機器的任何用戶在不登陸的狀況下進行管理訪問。這爲管理員在丟失憑證時恢復系統提供了一種方法。這裏的假設是隻有徹底可信的用戶才能直接來自服務器本地。
• 管理接口可能與主應用是不一樣的端口號，由於用戶可能沒法直接訪問。

在這種信任關係中，來自本地機器的請求的處理方式與普通請求不一樣，這經常使 SSRF 成爲一個嚴重的漏洞。

針對其餘後端系統的 SSRF 攻擊

SSRF 利用的另一種信任關係是應用服務端與用戶沒法直接訪問的內部後端系統之間進行的交互，這些後端系統一般具備不可路由的專用 IP 地址，因爲受到網絡拓撲結構的保護，它們的安全性每每較弱。在許多狀況下，內部後端系統包含一些敏感功能，任何可以與系統交互的人均可以在不進行身份驗證的狀況下訪問這些功能。

在前面的示例中，假設後端系統有一個管理接口 https://192.168.0.68/admin 。此時，攻擊者能夠經過提交如下請求利用 SSRF 漏洞訪問管理接口：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

規避常見的 SSRF 防護

一般應用程序包含 SSRF 行爲以及防止惡意攻擊的防護措施，然而這些防護措施是能夠被規避的。

基於黑名單過濾的 SSRF

某些應用程序禁止例如 127.0.0.1、localhost 等主機名、或 /admin 等敏感 URL 。這種狀況下，可使用各類技巧繞過過濾：

• 使用 127.0.0.1 的替代 IP 地址表示，例如 2130706433，017700000001，127.1 。
• 註冊本身的域名，並解析爲 127.0.0.1 ，你能夠直接使用 spoofed.burpcollaborator.net 。
• 使用 URL 編碼或大小寫變化來混淆被阻止的字符串。

基於白名單過濾的 SSRF

有些應用程序只容許輸入匹配、或包含白名單中的值，或以白名單中的值開頭。在這種狀況下，有時能夠利用 URL 解析的不一致來繞過過濾器。

URL 規範包含有許多在實現 URL 的解析和驗證時容易被忽略的特性：

• 你能夠在主機名以前使用 @ 符號嵌入憑證。例如 https://expected-host@evil-host 。
• 你可使用 # 符號表示一個 URL 片斷。例如 https://evil-host#expected-host 。
• 你能夠利用 DNS 命令層次結構將所需的輸入放入你控制的標準 DNS 名稱中。例如 https://expected-host.evil-host 。
• 你可使用 URL 編碼字符來迷惑 URL 解析代碼。若是處理 URL 編碼的過濾器的實現不一樣與執行後端 HTTP 請求的代碼，這一點尤爲有用。
• 你能夠把這些技巧結合起來使用。

經過開放重定向繞過 SSRF 過濾器

有時利用開放重定向漏洞能夠繞過任何基於過濾器的防護。

在前面的示例中，假設用戶提交的 URL 通過嚴格驗證，以防止惡意利用 SSRF 的行爲，可是，容許使用 URL 的應用程序包含一個開放重定向漏洞。若是用於發起後端 HTTP 請求的 API 支持重定向，那麼你能夠構造一個知足過濾器的要求的 URL ，並將請求重定向到所需的後端目標。

例如，假設應用程序包含一個開放重定向漏洞，例以下面 URL 的形式：

/product/nextProduct?currentProductId=6&path=http://evil-user.net

重定向到：

http://evil-user.net

你能夠利用開放重定向漏洞繞過 URL 過濾器，並利用 SSRF 漏洞進行攻擊，如：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

這個 SSRF 攻擊之全部有效，是由於首先 stockAPI URL 在應用程序容許的域上，而後應用程序向提供的 URL 發起請求，觸發了重定向，最終向重定向的內部 URL 發起了請求。

Blind SSRF - 不可見 SSRF 漏洞

所謂 Blind SSRF（不可見 SSRF）漏洞是指，能夠誘導應用程序向提供的 URL 發起後端 HTTP 請求，可是請求的響應並無在應用程序的前端響應中返回。

不可見 SSRF 漏洞一般較難利用，但有時會致使服務器或其餘後端組件上的遠程代碼執行。

尋找 SSRF 漏洞的隱藏攻擊面

許多 SSRF 漏洞之因此相對容易發現，是由於應用程序的正常通訊中就包含了完整的 URL 請求參數。而其它狀況就比較難搞了。

請求中的部分 URL

有時應用程序只將主機名或 URL 路徑的一部分放入請求參數中，而後，提交的值被合併到服務端請求的完整 URL 中。若是該值很容易被識別爲主機名或 URL 路徑，那麼潛在的攻擊面可能很明顯。可是，由於你不能控制最終請求的 URL，因此 SSRF 的可利用性會受到限制。

數據格式內的 URL

有些應用程序以某種數據格式傳輸數據，URL 則包含在指定數據格式中。這裏的數據格式的一個明顯的例子就是 XML ，當應用程序接受 XML 格式的數據並對其進行解析時，可能會受到 XXE 注入，進而經過 XXE 完成 SSRF 攻擊。有關 XXE 注入漏洞會有專門的章節講解。

經過 Referer 頭的 SSRF

一些應用程序使用服務端分析軟件來跟蹤訪問者，這種軟件常常在請求中記錄 Referer 頭，由於這對於跟蹤傳入連接特別有用。一般，分析軟件實際上會訪問 Referer 頭中出現的任何第三方 URL 。這一般用於分析引用站點的內容，包括傳入連接中使用的錨文本。所以，Referer 頭一般是 SSRF 漏洞的有效攻擊面。有關涉及 Referer 頭的漏洞示例請參閱 Blind SSRF 。

---

Blind SSRF

在本節中，咱們將解釋什麼是不可見的服務端請求僞造，並描述一些常見的不可見 SSRF 示例，以及解釋如何發現和利用不可見 SSRF 漏洞。

什麼是不可見 SSRF

不可見 SSRF 漏洞是指，能夠誘導應用程序向提供的 URL 發出後端 HTTP 請求，但來自後端請求的響應沒有在應用程序的前端響應中返回。

不可見 SSRF 漏洞的影響

不可見 SSRF 漏洞的影響每每低於徹底可見的 SSRF 漏洞，由於其單向性，雖然在某些狀況下，能夠利用它們從後端系統檢索敏感數據，但不能輕易地利用它們來實現完整的遠程代碼執行。

如何發現和利用不可見 SSRF 漏洞

檢測不可見 SSRF 漏洞最可靠的方法是使用 out-of-band（OAST）帶外技術。這包括嘗試觸發對你控制的外部系統的 HTTP 請求，並監視與該系統的網絡交互。

使用 OAST 技術最簡單有效的方式是使用 Burp Collaborator(此功能須要付費)。你可使用 Burp Collaborator client 生成惟一的域名，將這個域名以有效負載的形式發送到檢測漏洞的應用程序，並監視與這個域名的任何交互，若是觀察到來自應用程序傳入的 HTTP 請求，則說明應用程序存在 SSRF 漏洞。

注意：在測試 SSRF 漏洞時，一般會觀察到所提供域名的 DNS 查找，可是卻沒有後續的 HTTP 請求。這一般是應用程序視圖向該域名發出 HTTP 請求，這致使了初始的 DNS 查找，但實際的 HTTP 請求被網絡攔截了。基礎設施容許出站的 DNS 流量是相對常見的，由於出於不少目的須要，可是會阻止到意外目的地的 HTTP 鏈接。

簡單地識別一個能夠觸發 out-of-band 帶外 HTTP 請求的不可見 SSRF 漏洞自己並無提供一個可利用的途徑。因爲你沒法查看來自後端請求的響應，所以也沒法得知具體的內容。可是，它仍然能夠用來探測服務器自己或其餘後端系統上的其餘漏洞。你能夠盲目地掃描內部 IP 地址空間，發送旨在檢測已知漏洞的有效負載，若是這些有效負載也使用帶外技術，那麼您可能會發現內部服務器上的一個未修補的嚴重漏洞。

另外一種利用不可見 SSRF 漏洞的方法是誘導應用程序鏈接到攻擊者控制下的系統，並將惡意響應返回到進行鏈接的 HTTP 客戶端。若是你能夠利用服務端 HTTP 實現中的嚴重的客戶端漏洞，那麼你也許可以在應用程序基礎架構中進行遠程代碼執行。