做Web安全測試這幾年文件上傳漏洞是我遇到頻率最高、也最容易被低估的一個(gè)點(diǎn)。很多應(yīng)用都有頭像上傳、附件上傳、圖片裁剪上傳業(yè)務(wù)離不開它攻防雙方也都盯著它。真正動(dòng)手測試時(shí)大多數(shù)人會(huì)先改擴(kuò)展名試幾個(gè)常見后綴不行就換個(gè)大馬重傳沒成功就下結(jié)論這里應(yīng)該沒什么問題。但文件上傳的校驗(yàn)方式遠(yuǎn)比想象中復(fù)雜——擴(kuò)展名黑名單、白名單、MIME類型檢查、文件頭魔數(shù)校驗(yàn)、內(nèi)容二次解析、大小限制、文件名過濾每一層都可能存在繞過空間而這些組合邏輯恰恰是Fuzz測試最擅長覆蓋的場景。這篇文章記錄我用Burp Suite Intruder做文件上傳漏洞Fuzz測試的完整思路、配置細(xì)節(jié)和踩坑記錄適合已經(jīng)掌握Burp基礎(chǔ)操作、想深入挖掘上傳類漏洞的安全測試同行。文件上傳Fuzz不是簡單地把幾十個(gè)惡意文件挨個(gè)傳一遍而是把上傳請求拆解成若干可變異的位置用Intruder批量生成并發(fā)送不同類型的探針根據(jù)響應(yīng)差異判斷校驗(yàn)邏輯和繞過條件。整個(gè)過程你需要解決三個(gè)問題變異哪些位置、用什么字典、如何從成百上千條響應(yīng)里找出有價(jià)值的輸出。這三件事做完上傳漏洞的測試才算真正落地而不是撞運(yùn)氣。1. 文件上傳漏洞為什么值得Fuzz1.1 從業(yè)務(wù)場景看文件上傳的攻擊面文件上傳本質(zhì)上是一個(gè)用戶輸入進(jìn)入服務(wù)器文件系統(tǒng)的通道。只要服務(wù)器對上傳內(nèi)容有哪怕一處校驗(yàn)不嚴(yán)就可能導(dǎo)致文件被寫入非預(yù)期目錄、覆蓋已有文件甚至以腳本形式被解析執(zhí)行。常見的觸發(fā)點(diǎn)包括用戶頭像、商品圖片、簡歷附件、批量導(dǎo)入文件、客服聊天上傳等幾乎每一個(gè)接收文件的接口都是候選測試目標(biāo)。我在測試中習(xí)慣把文件上傳的校驗(yàn)拆成四個(gè)維度來看第一個(gè)是擴(kuò)展名維度服務(wù)器是否允許、是否攔截特定后綴第二個(gè)是MIME類型維度包括請求頭里的Content-Type字段第三個(gè)是文件內(nèi)容維度很多系統(tǒng)會(huì)讀取文件頭部字節(jié)來驗(yàn)證真?zhèn)蔚谒膫€(gè)是文件名字符維度包括路徑分隔符、特殊字符、編碼后的變體。大多數(shù)漏洞的產(chǎn)生不是某一個(gè)維度完全失效而是開發(fā)團(tuán)隊(duì)只做了單層校驗(yàn)。比如只限制前端后綴、只檢查了Content-Type、只在文件頭寫了固定簽名那么繞過方案幾乎就是明擺著的。1.2 Fuzz測試與傳統(tǒng)手動(dòng)測試的差異手動(dòng)測試上傳漏洞時(shí)通常的操作是打開Burp的Repeater改一個(gè)參數(shù)發(fā)一次請求再改一個(gè)參數(shù)再發(fā)一次效率低不說還容易遺漏邊緣情況。比如擴(kuò)展名從.php試到.php5再試到.phtml純靠手點(diǎn)其實(shí)挺考驗(yàn)?zāi)托腗IME類型image/jpeg改成image/png或者改成application/octet-stream再改成text/plain也是一輪輪重復(fù)勞動(dòng)。真正遇到繞不過去的點(diǎn)你很難判斷是目標(biāo)校驗(yàn)太嚴(yán)還是你漏掉了某個(gè)變體。Fuzz測試的差異在于把人肉枚舉變成參數(shù)化批量枚舉。你用Intruder定義好測試位置、準(zhǔn)備一份覆蓋足夠多變體的字典、設(shè)置好線程和匹配規(guī)則剩下的就是讓工具跑。響應(yīng)長度、狀態(tài)碼、響應(yīng)時(shí)間、返回關(guān)鍵字都會(huì)被記錄下來你可以從幾百條結(jié)果里一眼看出哪幾個(gè)請求走出了正常攔截的模式從而定位到值得深入驗(yàn)證的繞過向量。這種方式對文件上傳這種校驗(yàn)邏輯層層遞進(jìn)的場景尤其合適因?yàn)槟阈枰瑫r(shí)觀察不同維度組合對結(jié)果的影響手動(dòng)操作幾乎不可能完整覆蓋。2. Intruder基礎(chǔ)配置別讓工具拖后腿2.1 請求模板的正確構(gòu)造方式開始Fuzz之前你要先在Burp里拿到一個(gè)真實(shí)的上傳請求。最簡單的方式是配置好瀏覽器代理然后在目標(biāo)上傳功能里正常提交一個(gè)小文件在HTTP History里找到對應(yīng)的POST請求右鍵發(fā)送到Intruder。一個(gè)典型的上傳請求長這樣POST /api/upload HTTP/1.1 Host: test.target Content-Type: multipart/form-data; boundary------------------------abc123 User-Agent: Mozilla/5.0 Content-Length: 348 --------------------------abc123 Content-Disposition: form-data; namefile; filenametest.jpg Content-Type: image/jpeg GIF89a test --------------------------abc123 Content-Disposition: form-data; namesubmitted --------------------------abc123--拿到這樣的請求模板后第一件事不是急著標(biāo)記位置而是檢查RequestBody的完整性和Headers字段。我見過很多測試者重復(fù)使用同一個(gè)boundary卻修改了文件內(nèi)容導(dǎo)致目標(biāo)解析失敗所有請求都返回同樣的錯(cuò)誤最后誤判為不存在漏洞。正確做法是保留原始請求的完整結(jié)構(gòu)把需要變異的字段單獨(dú)標(biāo)記出來其余部分一個(gè)字節(jié)都不要?jiǎng)?。特別是Content-Type的boundary值、Content-Length會(huì)在Burp發(fā)送時(shí)自動(dòng)更新不需要手改萬一某一輪測試批量失敗先回到原始請求確認(rèn)它仍然能復(fù)現(xiàn)正常響應(yīng)再繼續(xù)后面的Fuzz。2.2 位置標(biāo)記Position的選取邏輯Intruder的核心工作方式是你在請求中用§符號劃出Payload的插入位置每次發(fā)送請求時(shí)它會(huì)把Payload放進(jìn)這些位置。對于文件上傳Fuzz常見的位置選取邏輯有以下幾種。第一種、最基礎(chǔ)的是只標(biāo)記文件名里的擴(kuò)展名部分比如把test.jpg改成test.§payload§。注意這里不要把整個(gè)文件名標(biāo)記進(jìn)去否則你的字典里每個(gè)Payload都要包含完整的test.前綴。我會(huì)把前綴寫在請求原文里讓Intruder只插入后綴部分這樣字典可以保持干凈便于復(fù)用。第二種、標(biāo)記整個(gè)filename值。當(dāng)你需要測試文件名過濾規(guī)則、路徑穿越特征或特殊字符時(shí)把filename§payload§整體作為標(biāo)記位置字典里放文件名變體比如../test.php、test.php%00.jpg、.htaccess等。第三種、標(biāo)記MIME類型字段。把Content-Type: §payload§作為標(biāo)記位置配合image/jpeg、application/x-php等值測試。第四種、在某些場景下還需要標(biāo)記文件內(nèi)容區(qū)。如果目標(biāo)校驗(yàn)了魔數(shù)你要把內(nèi)容區(qū)的固定簽名替換成Payload比如在文件內(nèi)容開頭插入GIF89a、%PDF、\xFF\xD8\xFF\xE0等字節(jié)。此時(shí)通常配合Cluster Bomb攻擊類型讓擴(kuò)展名和文件內(nèi)容兩個(gè)位置同時(shí)變異。2.3 Payload類型怎么選才高效Intruder內(nèi)置的Payload類型里文件上傳Fuzz實(shí)戰(zhàn)用到最多的是Simple list和Custom iterator。Simple list適合單點(diǎn)枚舉你準(zhǔn)備一份候選字典一行一個(gè)值工具會(huì)逐個(gè)替換到標(biāo)記位置。配合Payload Processing里的Add prefix和Add suffix規(guī)則可以不用改字典就能生成test.php、test.php5這類變體。Custom iterator適合需要把多個(gè)片段組合成完整Payload的場景典型用例是雙擴(kuò)展名測試。你可以設(shè)置兩個(gè)或三個(gè)Position第一段是原始文件名前綴第二段是擴(kuò)展名列表第三段又是后綴列表通過調(diào)節(jié)各個(gè)列表的順序和數(shù)量在短時(shí)間內(nèi)生成大量test.php.jpg、test.jpg.php這樣的組合比手工在字典里寫全排列高效得多。Attack Type的選擇也很關(guān)鍵。單標(biāo)記位置用Sniper就夠兩個(gè)標(biāo)記位置需要配對組合時(shí)首選Cluster Bomb如果你要的是多個(gè)標(biāo)記位置用同一套Payload同步替換Battering Ram偶爾會(huì)用上。實(shí)戰(zhàn)里我碰到最多的是Sniper對擴(kuò)展名做單維度枚舉、Cluster Bomb對擴(kuò)展名MIME或擴(kuò)展名文件內(nèi)容做組合測試這兩種組合已經(jīng)能覆蓋絕大多數(shù)場景。3. 針對文件上傳的Fuzz策略設(shè)計(jì)3.1 文件類型繞過擴(kuò)展名與MIME的排列組合文件上傳第一道關(guān)卡通常是擴(kuò)展名檢查具體又分黑名單和白名單兩種思路。黑名單攔截一大堆已知危險(xiǎn)后綴但列表經(jīng)常不完整白名單只允許圖片、文檔后綴看起來安全但繞過思路更多。碰到黑名單校驗(yàn)先看攔截報(bào)錯(cuò)信息能幫你縮小范圍。如果系統(tǒng)提示該文件類型不允許上傳說明代碼里大概率維護(hù)了一個(gè)阻塞后綴列表你要做的就是探測列表遺漏。常用的爆破方向是PHP系擴(kuò)展名.php3、.php5、.phtml、.pht、.phar、.php7、ASP系.asp、.aspx、.asa、.cer、.cdx、JSP系.jsp、.jspx、.jspf再加上少見的變體。字典里保留一份基礎(chǔ)列表每次測試都往里追加新出現(xiàn)的變體比每次臨時(shí)查資料高效。白名單校驗(yàn)的策略完全不同。既然系統(tǒng)只允許.jpg上傳你要思考的是是否存在Apache解析漏洞、Nginx配置錯(cuò)誤、IIS分號截?cái)噙@類服務(wù)器解析層面的后門。這類問題在Fuzz階段的表現(xiàn)是上傳.jpg文件后系統(tǒng)把請求里的某個(gè)字段如filename或文件內(nèi)容解析為實(shí)際執(zhí)行的腳本。所以遇到白名單我會(huì)在Fuzz完擴(kuò)展名之后立刻轉(zhuǎn)向雙擴(kuò)展名特殊字符的組合測試而不是繼續(xù)在白名單后綴上撞運(yùn)氣。MIME類型的Fuzz相對簡單一些但容易被遺漏。很多應(yīng)用的后端只檢查了multipart請求里的Content-Type字段卻忽略了對文件真實(shí)內(nèi)容的驗(yàn)證。Intruder字典里放image/jpeg、image/png、image/gif、application/pdf、text/plain、application/octet-stream、multipart/form-data的變體逐個(gè)替換后觀察響應(yīng)差異。有時(shí)候光是把這個(gè)字段改成text/plain配合上傳的PHP內(nèi)容就能讓文件成功落地并被執(zhí)行——這種低門檻問題在實(shí)戰(zhàn)里出現(xiàn)的概率不低。3.2 內(nèi)容檢測繞過魔數(shù)、雙擴(kuò)展名與大小寫變體如果系統(tǒng)會(huì)讀取文件頭幾字節(jié)來驗(yàn)證文件類型你就要在文件內(nèi)容區(qū)做文章。常見的魔數(shù)校驗(yàn)包括GIF文件頭的GIF89a、JPEG文件頭的\xFF\xD8\xFF、PNG文件頭的\x89PNG注意PNG魔數(shù)通常有特定前綴。繞過思路是在惡意腳本內(nèi)容前加上對應(yīng)圖片格式的合法文件頭使文件在檢查內(nèi)容時(shí)偽裝成圖片同時(shí)又保留后端可以解析的腳本邏輯。這類測試用Intruder做并不復(fù)雜。把請求里的文件內(nèi)容區(qū)域標(biāo)記成一個(gè)獨(dú)立的位置字典里放各種魔數(shù)前綴再配合Cluster Bomb讓文件命名和內(nèi)容區(qū)同時(shí)變異。需要注意一點(diǎn)很多服務(wù)器是根據(jù)文件擴(kuò)展名決定是否執(zhí)行而不是根據(jù)內(nèi)容魔數(shù)。所以內(nèi)容可變和擴(kuò)展名也可變要聯(lián)動(dòng)組合單獨(dú)改內(nèi)容而擴(kuò)展名被攔截等于白測。雙擴(kuò)展名測試在這個(gè)階段特別有價(jià)值。常見組合是.jpg.php、.php.jpg、.php%00.jpg、.php.、.php .這幾個(gè)變體。原理分幾種一種是服務(wù)器把最后一個(gè)點(diǎn)后面的部分當(dāng)作擴(kuò)展名來放行但解析引擎按第一個(gè)點(diǎn)或倒數(shù)第二個(gè)點(diǎn)來執(zhí)行腳本另一種是空字節(jié)截?cái)嘧屜到y(tǒng)只看到.jpg而后端解析為.php還有一種是末尾點(diǎn)號讓某些Windows配置下的服務(wù)器把文件當(dāng)可執(zhí)行類型處理。把這些變體按系統(tǒng)類型分組排在字典里比盲目亂試更容易出結(jié)果。3.3 文件名相關(guān)的測試向量文件名的處理也是一道不可忽略的測試面。某些上傳組件在保存文件時(shí)沒有對文件名做過濾導(dǎo)致路徑穿越、符號鏈接覆蓋、甚至寫入系統(tǒng)敏感目錄。Fuzz時(shí)建議把fileName值作為一個(gè)獨(dú)立標(biāo)記位置字典里放../test.php、..\test.php、test.php%00.jpg、test.php::$DATA、test.php.、test.php連同空格、%2e%2e%2f等變體。這些Payload的重點(diǎn)在于觀察響應(yīng)里的路徑回顯。如果上傳成功后返回了文件的訪問URL你要根據(jù)URL里的路徑偏移判斷能否穿越到指定目錄。測試路徑穿越時(shí)最好配合一個(gè)可訪問目錄下的對照文件比如先上傳一個(gè)正常文件拿到基準(zhǔn)URL再Fuzz穿越Payload對比返回URL的目錄結(jié)構(gòu)。另外Windows和Unix環(huán)境的路徑分隔符語義完全不同測試環(huán)境是Windows時(shí)反斜杠和冒號變體優(yōu)先Unix環(huán)境下正斜杠和點(diǎn)號變體優(yōu)先。4. 實(shí)戰(zhàn)一次完整的文件上傳Fuzz過程4.1 目標(biāo)分析先摸清校驗(yàn)邏輯拿到一個(gè)目標(biāo)上傳點(diǎn)之后我的習(xí)慣是先用Repeater做三輪手工試探速度很慢但對后續(xù)Fuzz幫助巨大。第一輪正常上傳一張符合業(yè)務(wù)要求的圖片記錄狀態(tài)碼、響應(yīng)體關(guān)鍵字和返回URL。第二輪只把擴(kuò)展名改成.php其他不動(dòng)看系統(tǒng)報(bào)什么錯(cuò)能直接暴露很多校驗(yàn)規(guī)則。比如文件類型不允許php說明是黑名單后綴過濾圖片格式不正確說明會(huì)讀取文件內(nèi)容上傳失敗請重試且無明確關(guān)鍵詞可能是白名單或復(fù)合校驗(yàn)。第三輪把Content-Type從image/jpeg改成application/x-php但擴(kuò)展名保持.jpg看是否單獨(dú)檢查MIME。這三輪做完基本能確認(rèn)校驗(yàn)是單層還是多層為后面選字典和Fuzz策略提供依據(jù)。4.2 構(gòu)造Fuzz字典從小的開始做Fuzz前先想清楚一個(gè)問題這輪測試要覆蓋哪個(gè)維度這決定字典內(nèi)容而不是把所有Payload一股腦塞進(jìn)一個(gè)列表。我一般會(huì)準(zhǔn)備三個(gè)基礎(chǔ)字典文件。第一個(gè)是擴(kuò)展名字典包含常見腳本后綴和變體大約幾十條。第二個(gè)是文件名字典包含特殊字符、路徑穿越、雙擴(kuò)展名組合大約幾十條。第三個(gè)是MIME字典包含各種Content-Type值。這三個(gè)字典在我日常測試中反復(fù)使用遇到新的繞過思路就手動(dòng)追加進(jìn)去。每次Fuzz前我會(huì)先從主字典里挑選一小部分子集比如10到20條先跑通整個(gè)Intruder流程和環(huán)境配置確認(rèn)無報(bào)錯(cuò)后再擴(kuò)大字典。這個(gè)小字典驗(yàn)證的習(xí)慣幫我避免了很多低效的大批量白跑。字典里的Payload排序也有講究。我習(xí)慣把最可能成功的變體放在前面比如主流腳本后綴和最常見的雙擴(kuò)展名組合放前20條冷門變體放后面這樣即使測試中途被中斷前面已經(jīng)覆蓋了高概率場景。4.3 執(zhí)行與結(jié)果分析響應(yīng)特征怎么看發(fā)送前有幾個(gè)設(shè)置一定要檢查。線程數(shù)不要一上來就拉滿目標(biāo)是小站點(diǎn)但是批量發(fā)包也容易觸發(fā)防護(hù)或把服務(wù)拖到異常。我常用的配置是線程10到20、超時(shí)10秒、重試兩次。另外在Intruder的Options里開啟Grep-Match把特征關(guān)鍵字預(yù)先填好比如success、上傳成功、Forbidden、Invalid file type這樣結(jié)果列表里會(huì)多出幾列高亮標(biāo)記方便快速篩選。請求發(fā)出后從兩個(gè)維度看結(jié)果。第一個(gè)維度是整體響應(yīng)如果有少量請求的狀態(tài)碼、響應(yīng)長度明顯偏離大多數(shù)請求這本身就是強(qiáng)篩選依據(jù)。比如99%的請求返回200且長度相近只有幾個(gè)返回302或500那這幾個(gè)就是重點(diǎn)排查對象。不要把精力花在瀏覽幾百條完全一致的響應(yīng)上。第二個(gè)維度是響應(yīng)體的內(nèi)容差異。很多時(shí)候響應(yīng)狀態(tài)碼都一樣但響應(yīng)體里的關(guān)鍵字微妙不同比如有的提示文件擴(kuò)展名不允許有的提示上傳成功還有的提示內(nèi)容不合法。用Grep-Match標(biāo)記后你會(huì)看到一小撮請求的命中特征與其他請求不同這些就是要繼續(xù)驗(yàn)證的目標(biāo)。4.4 驗(yàn)證與利用Fuzz成功后的收尾Intruder跑出的結(jié)果只是候選成功項(xiàng)一定要用Repeater手工驗(yàn)證。我會(huì)把Fuzz結(jié)果里響應(yīng)出現(xiàn)異常的請求全部發(fā)送到Repeater逐個(gè)手工重放確認(rèn)再發(fā)一次仍然能復(fù)現(xiàn)排除Intruder并發(fā)請求帶來的偶發(fā)問題。確認(rèn)后還有兩件事要做文件是否真正落到了服務(wù)器目錄以及文件是否能被外部訪問并執(zhí)行。落地驗(yàn)證通?？宽憫?yīng)里返回的URL或文件名如果沒有URL回顯可以參考目標(biāo)站點(diǎn)同功能之前正常上傳文件時(shí)暴露的存儲(chǔ)路徑把上傳文件名替換上去訪問。執(zhí)行驗(yàn)證是文件上傳測試的終點(diǎn)如果上傳的是探針文件且能通過URL訪問并看到執(zhí)行結(jié)果那這個(gè)漏洞就不是看起來能傳而是實(shí)實(shí)在在可利用的狀態(tài)。在這一步我嚴(yán)格執(zhí)行授權(quán)范圍約束只拿無公害的探針內(nèi)容驗(yàn)證可執(zhí)行性整個(gè)過程和測試數(shù)據(jù)只在授權(quán)測試環(huán)境內(nèi)使用。5. 常見問題排查與效率提升實(shí)錄5.1 測試結(jié)果誤判的三種典型場景用Intruder做文件上傳Fuzz最多見的不是沒跑出結(jié)果而是跑出一堆結(jié)果卻沒有一個(gè)能復(fù)現(xiàn)或者相反——所有請求返回完全一致你認(rèn)為沒有漏洞其實(shí)工具配置有問題。第一種誤判所有請求響應(yīng)一字不差。排查順序是先確認(rèn)標(biāo)記位置是否正確是不是把整個(gè)請求體都標(biāo)記進(jìn)去了再確認(rèn)Payload是不是真的被放進(jìn)了標(biāo)記位置可以在Request預(yù)覽里檢查某一輪請求的實(shí)際內(nèi)容最后看看是不是目標(biāo)對異常請求統(tǒng)一返回固定頁面比如一個(gè)通用錯(cuò)誤頁讓所有響應(yīng)看起來都一樣。第二種誤判響應(yīng)長度差異來自多余空格或隨機(jī)時(shí)間戳而不是漏洞。文件上傳場景響應(yīng)體被判定的特征往往包含日期、用戶名、隨機(jī)URL這些動(dòng)態(tài)內(nèi)容會(huì)讓響應(yīng)長度整體變化。解決方法是不要只看長度要配合Grep-Match關(guān)鍵字命中觀察或者把關(guān)鍵差異響應(yīng)導(dǎo)入Comparer逐字節(jié)對比。第三種誤判Payload被Burp或目標(biāo)自動(dòng)轉(zhuǎn)義。比如你在文件名里寫了一個(gè)%00如果不小心設(shè)置了URL編碼規(guī)則發(fā)送到目標(biāo)時(shí)可能被轉(zhuǎn)成%2500繞了一圈變成字面字符等于沒測。建議在Payload Processing里禁用自動(dòng)URL編碼或者對字典做一次原始字節(jié)預(yù)覽。5.2 資源控制與任務(wù)調(diào)度的實(shí)操經(jīng)驗(yàn)Fuzz測試的本質(zhì)是海量HTTP請求資源控制做不好就很容易出事故或者被防護(hù)封掉。我的建議是字典在500條以內(nèi)時(shí)線程可以開到20超過2000條建議回落到10到15超過1萬條要么分塊執(zhí)行要么限制到5到8線程。原因很簡單文件上傳接口往往涉及磁盤寫入和文件類型解析并發(fā)太高時(shí)目標(biāo)會(huì)變慢甚至超時(shí)大批請求超時(shí)會(huì)觸發(fā)重試重試又放大流量最后得到的響應(yīng)數(shù)據(jù)幾乎沒有參考價(jià)值。超時(shí)設(shè)置不要低于10秒。文件上傳接口處理時(shí)間通常比普通JSON接口長我見過默認(rèn)3秒超時(shí)導(dǎo)致幾乎所有請求都顯示超時(shí)然后誤以為目標(biāo)把請求全攔截了。重試次數(shù)建議控制在2次以內(nèi)因?yàn)檫@里的重試是面向網(wǎng)絡(luò)層異常的不是面向應(yīng)用層拒絕的。如果你擔(dān)心被封IP可以在Intruder Options里給每個(gè)請求加Delay毫秒級隨機(jī)延遲或者把一輪大字典拆成幾個(gè)小任務(wù)分時(shí)段跑。雖然慢一點(diǎn)但數(shù)據(jù)干凈、不驚動(dòng)目標(biāo)端防護(hù)的收益遠(yuǎn)大于速度。真正有價(jià)值的結(jié)果往往來自慢而全的測試而不是快到把目標(biāo)打掛的暴力發(fā)送。5.3 幾個(gè)提升效率的實(shí)用配置高效測試不只靠鼠標(biāo)點(diǎn)幾個(gè)配置能讓你的Intruder工作流提升一個(gè)檔次。第一個(gè)是使用Payload Processing的規(guī)則組合。我常用Add prefix在字典值前面拼文件名前綴實(shí)現(xiàn)快速變體擴(kuò)展再用Add suffix拼后綴兩者配合可以把一個(gè)核心字典表擴(kuò)展成覆蓋幾十種組合形式的完整測試列表而不用真的在文件里寫幾百行。第二個(gè)是Grep-Match和Grep-Extract的配合。Grep-Match標(biāo)記響應(yīng)里出現(xiàn)特定關(guān)鍵字的請求Grep-Extract則可以提取響應(yīng)中的動(dòng)態(tài)內(nèi)容比如上傳后的文件URL。配置好之后Intruder結(jié)果列表會(huì)多出提取到的URL一列你可以直接看到成功了哪些請求并且拿到訪問路徑省掉了手動(dòng)從Response里翻URL的工夫。第三個(gè)是在Intruder跑完后把結(jié)果導(dǎo)出按響應(yīng)長度、狀態(tài)碼、關(guān)鍵字命中率做二次排序。這個(gè)習(xí)慣能讓我快速聚焦到響應(yīng)異常且命中關(guān)鍵字的那一小撮數(shù)據(jù)而這些數(shù)據(jù)往往就是上傳繞過成功的直接候選。最后聊幾句實(shí)在話文件上傳Fuzz這門手藝說到底拼的不是工具用得多花哨而是你對校驗(yàn)邏輯的拆解深度和你的字典積累厚度。Burp Suite Intruder只是把發(fā)很多請求這件事自動(dòng)化了決定測試質(zhì)量的核心還是你知不知道在哪個(gè)位置放什么Payload、看到結(jié)果后往哪個(gè)方向繼續(xù)挖。踩過幾次坑之后我的習(xí)慣是先花十分鐘理清楚目標(biāo)校驗(yàn)的層次再花五分鐘準(zhǔn)備小字典驗(yàn)證管道通暢然后才放開跑大字典。這個(gè)流程救過我好幾次避免了被幾百條無差異響應(yīng)淹沒還自以為在測試的窘境。最后再補(bǔ)一句Intruder跑出來的候選清單務(wù)必用Repeater逐一手測確認(rèn)因?yàn)镕uzz測試的大前提永遠(yuǎn)是——你得知道自己請求里到底發(fā)了什么而不是讓工具替你思考。