最近有朋友問我CTFshow的web入門系列到底該怎么刷尤其卡在了爆破專題的web21到web28。這個專題我前前后后刷了兩遍第一遍是硬啃第二遍是系統(tǒng)整理完爆破方法論之后回去重做很多當(dāng)時覺得莫名其妙的題其實就那幾類考法。爆破Brute Force說白了就是在有限信息里用盡量規(guī)整的字典去撞那個唯一的正確值但CTF里的爆破和平常說的“暴力破解”不太一樣它更考驗?zāi)銓φ埱蟾袷?、編碼方式、服務(wù)端校驗邏輯的理解。這篇東西就圍繞web21到web28這套題聊聊爆破類題目背后的通用套路、工具配置和腳本思路適合剛開始接觸Web安全、準備系統(tǒng)刷CTF的入門選手也適合那些Burp Suite只會點幾下鼠標、遇到需要寫腳本就發(fā)怵的朋友。1. 從web21到web28這組題到底在訓(xùn)練什么1.1 爆破在Web入門中的定位不是“撞庫”而是“理解請求”很多人一聽到爆破第一反應(yīng)就是拿字典瘋狂打一個登錄接口跑幾百萬次直到撞出密碼。這種認知不能說錯但放在CTF題目里容易跑偏。CTF里的爆破題目設(shè)計者真正想考察的往往不是你的機器性能而是你對“一個HTTP請求從頭到尾是由哪些部分構(gòu)成的、服務(wù)器到底依據(jù)哪些字段做校驗”這件事有沒有清醒的認知。拿web21到web28這組題來說表面上都是爆破考點卻各不相同。有的題在傳輸層做了編碼處理直接拿明文密碼去撞根本沒用你得先看請求包里的參數(shù)長什么樣再決定載荷該不該做二次處理有的題頁面上掛了個驗證碼你以為需要識別圖片實際上服務(wù)端壓根沒校驗這個參數(shù)只是用來嚇唬你的還有的題限定了嘗試次數(shù)逼著你從源碼里找規(guī)律而不是無腦灌字典。這些場景拆開來看每一道都在訓(xùn)練一個獨立的技能點讀懂請求、識別編碼、分析校驗邏輯、選擇合適的爆破工具、必要時自己寫腳本。1.2 從機械爆破到邏輯爆破的難度梯度這套題最讓我覺得舒服的一點是難度梯度設(shè)計得比較自然。前面的題基本屬于“你只要會抓包、會配置Intruder、會用字典就能做出來”的機械階段目的是讓你熟悉工具本身做到后面幾道裸奔的字典逐漸失效你被迫開始分析返回報文之間的差異、考慮參數(shù)變換規(guī)則甚至要臨時寫一個幾十行的Python腳本去解決問題。這個梯度其實就是真實安全測試工作的縮影。早期階段你面對一個系統(tǒng)大部分時間確實是在用工具做重復(fù)嘗試但到了中后期能不能從響應(yīng)差異里讀出服務(wù)器的“性格”能不能把一段手工流程腳本化才是效率分水嶺。所以如果你發(fā)現(xiàn)自己在某道題上卡住了別急著懷疑題目太偏先問問自己是不是還在用第一題的思維做后面的題。2. 動手之前先把HTTP的“鑰匙”和“鎖芯”看清楚2.1 Basic認證、表單登錄、Cookie會話到底有什么不一樣爆破之前先得知道你撞的是什么“門”。這組題里有不少陷阱其實都是靠在認證方式上做文章。最基礎(chǔ)的是Basic認證。服務(wù)端返回一個401狀態(tài)碼響應(yīng)頭里帶著WWW-Authenticate: Basic realm...瀏覽器會彈出一個原生對話框讓你輸用戶名和密碼。這個對話框提交之后瀏覽器會把用戶名:密碼拼在一起做Base64編碼塞進請求頭Authorization: Basic xxxx里。很多剛?cè)腴T的朋友第一次抓包看到一長串看不懂的字符串就懵了其實你只要把那一串拿去Base64解碼里面就是admin:123456這種格式。反向操作也一樣如果題目要求你爆破這種認證你的載荷就應(yīng)該先拼成用戶名:密碼再做Base64編碼最后放進Authorization頭里。表單登錄則是另一套邏輯。輸入的用戶名和密碼會被作為請求體參數(shù)發(fā)送常見格式是usernameadminpassword123456服務(wù)端校驗之后返回一個會話標識通常是個Cookie后續(xù)請求帶著這個Cookie就能保持登錄狀態(tài)。爆破這類接口時你需要關(guān)注的是請求體里的字段名以及登錄成功后Set-Cookie的變化。Cookie會話的坑在于有些服務(wù)端不校驗用戶名密碼對不對它只校驗?zāi)闾峤坏哪硞€固定Token或者Session值。遇到這種題爆破的對象根本不是密碼而是那個Token或者Session。如果你盯著密碼字段猛打就會陷入死循環(huán)。我之前在給朋友講這組題時習(xí)慣讓他們先做一個動作拿到題目后先開Burp的Repeater手動發(fā)幾個請求把整個流程的請求包和響應(yīng)包都看一遍確認當(dāng)前題目屬于哪種認證模型再決定爆破載荷往哪里放。這個判斷只要十秒鐘但能幫你省下半小時的無效爆破。2.2 爆破成功的信號狀態(tài)碼、報文長度和返回文本爆破是一場“大部分時間都在失敗”的活動所以你得給“成功”定義好信號。最常用的信號有三個響應(yīng)狀態(tài)碼、響應(yīng)包長度、響應(yīng)文本特征。狀態(tài)碼最容易理解登錄失敗返回200登錄成功返回302跳轉(zhuǎn)這是教科書式的區(qū)分。但現(xiàn)實題目里經(jīng)常反著來所有請求都返回200服務(wù)器只是在頁面文本里區(qū)別對待。這時候你就得看報文長度同一個密碼長度不同響應(yīng)頁面的長度曲線會出現(xiàn)一個明顯的異類點那就是正確密碼所在的位置。響應(yīng)文本特征是最穩(wěn)妥的判斷方式比如登錄成功之后頁面出現(xiàn)“Welcome”或者“flag”字樣你可以給Burp設(shè)置一個正則匹配規(guī)則自動標記所有包含這個特征的響應(yīng)。我見過很多新手在爆破完成之后盯著幾千條記錄翻來翻去找“長得不一樣”的那個其實用Grep Match功能提前標好整個過程會輕松得多。3. 8道題里的高頻爆破場景逐個拆解3.1 對編碼后的參數(shù)爆破Base64只是最簡單的第一層web21到web28里面我印象最深的一類題就是“載荷不按原樣發(fā)送”。你以為爆破就是把字典里的明文密碼逐條填進password字段但抓包一看提交的參數(shù)是一段經(jīng)過編碼的字符串明文密碼被轉(zhuǎn)化成了另一種形態(tài)。最典型的例子就是Basic認證里的Base64編碼。假如服務(wù)端期望的Authorization頭是Basic YWRtaW46cGFzcw那你的爆破載荷就不能直接填pass而要先把它構(gòu)造成admin:pass的格式再進行Base64編碼最后把編碼后的結(jié)果替換到標記位置。這里有個容易踩的坑你需要在Intruder的Payload Processing里加一條“Encode: Base64-encode”規(guī)則而不是手動去編碼每一個字典項。再往后還會遇到URL編碼、十六進制字符串、甚至自定義的字符變換規(guī)則。處理思路是完全一致的先分析提交格式反推出服務(wù)器對載荷的“期望形態(tài)”然后在工具里配置對應(yīng)的編碼處理鏈。記住一個原則爆破載荷永遠要長成服務(wù)器期望的樣子而不是字典本身的樣子。3.2 固定驗證碼騙局別讓前端元素干擾你的判斷有幾次做題時頁面里明明畫著一個四位驗證碼我當(dāng)時還認真思考要不要接個打碼平臺結(jié)果后來才發(fā)現(xiàn)整個請求包里壓根沒有驗證碼這個字段。這就是典型的“假驗證碼”陷阱——驗證碼只是前端頁面上的一個裝飾服務(wù)端根本沒有去校驗它。這種題的解題思路反而簡單把驗證碼參數(shù)忽略掉直接對真正的密碼字段做爆破即可。但這道題在訓(xùn)練上的價值很好它提醒我永遠不要被“看起來需要某種能力”的假象攔住。做題時多問自己一句請求包里到底有哪幾個有效參數(shù)哪些參數(shù)是服務(wù)端真正會讀取的哪些只是前端用來障眼的同類陷阱還包括故意給你一個固定的錯誤Cookie、在請求里塞一個無意義的Token字段、讓你以為需要對Session做某種操作。識別方法其實就一條把請求包精簡到不能再精簡刪掉所有可疑參數(shù)后看看服務(wù)端還認不認這個請求認那它們就是假的不認再逐個加回來看是哪個參數(shù)觸發(fā)了變化。3.3 字典選擇策略你撞不開門可能是鑰匙串不對爆破的效率和字典質(zhì)量呈強相關(guān)這一組題也充分證明了這一點。有的題你拿弱口令字典就能輕松過因為它考的就是默認口令有的題密碼必須滿足特定長度或字符集比如純六位數(shù)字這種時候去跑幾萬的常用密碼字典反而會漏掉正確值。我的習(xí)慣是準備三個層級的字典第一層是常用弱口令小字典幾百條到幾千條用于快速排除最簡單的情況第二層是通用大字典覆蓋常見詞匯、姓名拼音、數(shù)字組合用于一般場景第三層是按規(guī)則生成的字典比如全數(shù)字的六位到八位組合、日期格式等用于匹配題目給出的明確約束。除此之外Payload Processing里還可以做多種變形大小寫轉(zhuǎn)換、末端追加年份、替換字符。有時正確答案就是admin有時是Admin2021字典質(zhì)量決定了你是否能一擊命中。但也要注意不要過度依賴字典很多題目其實會在源碼注釋或響應(yīng)頭里留下密碼的線索先找線索再跑字典遠比上來就全量掃描高效。3.4 當(dāng)一道題要求你寫腳本突破工具邊界刷到這套題后半段Burp的Intruder已經(jīng)能解決大部分問題但有幾道題你會明顯感覺到工具“擰巴”不是請求流程太重就是存在校驗上下文再或者需要根據(jù)服務(wù)器返回動態(tài)調(diào)整下一次請求的參數(shù)。這種時候就得拿起Python寫腳本了。我印象里這類題常見的要求是先登錄拿到一個動態(tài)Token再攜帶Token去爆破同時還要處理Cookie的會話保持。Burp雖然可以通過多個Intruder階段串聯(lián)來實現(xiàn)但配置起來繞來繞去遠不如腳本直白。這其實是個很關(guān)鍵的轉(zhuǎn)折點從“會用工具”到“工具用得不爽時能自己造輪子”。如果你立志走安全這條路腳本能力早晚要補起來與其等到工作中臨時學(xué)不如借著CTF題目的東風(fēng)順手練了。4. Burp Suite Intruder從能用用到好用4.1 一個Intruder請求的完整配置流程拿Intruder做爆破我相信大多數(shù)人都會但很多人的配置習(xí)慣是“能跑就行”忽略了一些影響效率和正確性的細節(jié)。我一般的流程是這樣的先把請求包從Repeater轉(zhuǎn)到Intruder在需要爆破的參數(shù)處添加§標記然后到Payloads面板選擇字典文件再從Options面板設(shè)置線程數(shù)和失敗重試規(guī)則最后先跑一條測試請求確認標記位置正確、字典能正常加載再啟動完整攻擊。這里最容易忽視的是Payload Processing很多人不知道這個面板的存在。它可以對每個載荷做前置處理比如字符串拼接、Base64編碼、大小寫替換、加前綴后綴。比如你要爆破的是Basic認證頭直接在原始載荷前后拼上admin:再做一次Base64編碼Intruder會自動生成完整的Authorization值你就不用先處理字典文件了這能省下大量時間。還有一個小細節(jié)是Sniper和Cluster Bomb的選擇。單參數(shù)爆破用Sniper就夠了多參數(shù)需要笛卡爾積組合時用Cluster Bomb。Cluster Bomb一旦參數(shù)多了并發(fā)是指數(shù)級增長的一定要控制集數(shù)量和線程否則本地資源會被打滿。4.2 用響應(yīng)長度分組和正則匹配快速鎖定答案爆破跑完之后幾百上千條結(jié)果怎么快速定位正確答案我看很多新手的做法是逐條點開看響應(yīng)包這種效率實在堪憂。正確姿勢是讓工具幫你做初篩Intruder的結(jié)果列表里默認就有Length列你只需要按長度排序一眼就能看到那個與眾不同的值。大多數(shù)情況下正確密碼觸發(fā)的響應(yīng)頁面長度會和其他失敗請求差出幾十上百字節(jié)。如果長度維度區(qū)分不明顯就啟用Grep Match功能把登錄成功后頁面會出現(xiàn)的特征詞——比如flag、success、welcome——填進去。跑完后每一行都會標記是否命中關(guān)鍵詞答案自動浮出水面。這一招在處理響應(yīng)內(nèi)容高度相似的題目時特別好使。4.3 并發(fā)、延時和資源的取舍并發(fā)調(diào)高爆破速度確實快但也容易出問題。有的CTF題目服務(wù)器很脆弱或者做了簡單的訪問頻率限制你開50線程去打跑完一輪所有請求都返回超時或者503反而浪費時間。我后來學(xué)乖了先用默認線程跑一個幾十條的小字典探一下服務(wù)端的承受閾值如果響應(yīng)都正常再逐漸加線程如果出現(xiàn)大量超時就降到5線程并在Intruder里設(shè)置失敗重試次數(shù)。另外要養(yǎng)成一個好習(xí)慣爆破前把Project Options里的Connections設(shè)置調(diào)整一下適當(dāng)減小響應(yīng)超時時間。CTF平臺通常響應(yīng)都很快把超時從默認的30秒改短可以避免某個卡死請求拖住整個線程池。5. 手寫Python爆破腳本的實用思路5.1 先用requests把完整流程復(fù)現(xiàn)出來開始寫腳本之前我強烈建議先用Postman或者Burp把目標接口的完整請求流程梳理清楚從最開始的GET請求頁面開始到提交登錄POST再到后續(xù)請求需要帶什么Cookie中間有沒有跳轉(zhuǎn)。然后把整個流程用Python的requests庫逐行復(fù)現(xiàn)出來。這一步做完你的爆破腳本其實已經(jīng)完成了一半。requests庫本身足夠簡單會話保持直接用一個requests.Session()對象就能搞定。遇到302跳轉(zhuǎn)設(shè)置allow_redirectsTrue模擬瀏覽器的自動跟隨遇到需要手動維持的Cookie直接從Session對象里讀出來。我一直認為寫爆破腳本最忌諱的是上來就寫循環(huán)核心流程還沒走通就想著并發(fā)后面的bug會讓人崩潰。5.2 解析響應(yīng)中的關(guān)鍵標記并自動判定成功爆破腳本里最實用的一個功能就是在每輪請求后自動判斷是否成功。我通常是寫一段簡單的響應(yīng)解析邏輯如果返回內(nèi)容里包含某個特定字符串就把當(dāng)前密碼寫入結(jié)果文件并終止循環(huán)如果響應(yīng)長度明顯偏離平均值也單獨記錄下來。這比把所有響應(yīng)都堆內(nèi)存里再人工查看要高效得多。這里有個經(jīng)驗判斷成功條件一定要寫在“服務(wù)器實際返回的東西”上而不是你想當(dāng)然的東西。比如你以為登錄成功會跳轉(zhuǎn)但服務(wù)器可能只是返回一個200 JSON你以為失敗了一定會返回error但頁面可能統(tǒng)一返回一個固定的HTML。寫腳本前先手動驗證一下成功和失敗兩種情況的響應(yīng)差異這比事后調(diào)試腳本少受罪。5.3 線程池并發(fā)與平穩(wěn)控制的平衡單線程腳本遇到大字典會跑得很慢我給這套題寫腳本時通常會用concurrent.futures.ThreadPoolExecutor做并發(fā)。線程數(shù)放20到30一般比較合適既能明顯提速也不會給服務(wù)器造成太大壓力。并發(fā)腳本里有個容易忽略的問題共享變量的線程安全。如果你在多個線程里同時寫同一個日志文件或結(jié)果列表最后數(shù)據(jù)可能丟或者錯亂。我的做法是每個線程返回獨立的結(jié)果主線程等所有任務(wù)結(jié)束之后再統(tǒng)一做篩選和落盤避免了加鎖的麻煩。另外如果目標接口有頻率限制可以在兩次請求之間加上短睡眠比如0.1秒雖然慢了一點但會把誤封的概率降下來。6. 做題順序、字典策略和我踩過的坑6.1 每道題開始之前先做一次手動驗證可能有很多人覺得爆破題目一上來就應(yīng)該開工具跑字典但我見過太多人在錯誤的方向上浪費了大量時間。我的建議是拿到題目后先用瀏覽器打開目標頁面然后用Burp攔截一次正常登錄手動提交一個錯誤的用戶名密碼看看響應(yīng)是什么樣再試一次正確的看看區(qū)別在哪里。這個“手動驗證”的過程看起來很笨卻能讓你對題目里到底哪個字段會觸發(fā)服務(wù)端校驗形成直觀判斷。更重要的是手動驗證能幫你發(fā)現(xiàn)題目的真正邏輯。有的題你輸入admin和123456頁面回顯“密碼錯誤”但回顯只針對用戶名說明用戶名已被預(yù)置有的題無論輸入什么都回顯“用戶名不存在”這時候你可能得先對用戶名做條目枚舉再對密碼做第二層爆破。沒有這個過程盲目用Intruder打密碼大概率會栽在第一步。6.2 從哪找字典、如何搭建自己的小型字典字典的選擇是個經(jīng)驗活。我自己的字典庫里弱口令字典基本來自CTF平臺和公開的安全測試字典庫但我不會原封不動直接用而是會抽出一個“高頻小抄”版本包含admin、root、123456、password、qwerty這些以及它們的變形。平時做題先用這份小抄探路跑不出結(jié)果再換大號字典。做這套爆破題時我還養(yǎng)成了按場景自定義字典的習(xí)慣。比如題目提示密碼是六位數(shù)字我就用Python一行代碼生成所有六位數(shù)字組合題目提示密碼是某個英文單詞加數(shù)字就先從推薦詞表里組合備選。這里用Python的itertools.product會很方便生成完直接導(dǎo)出成txt就能喂給Burp或者直接在腳本里迭代。6.3 最容易忽視的響應(yīng)差異陷阱最后聊一個我實際踩過的坑爆破結(jié)果里出現(xiàn)“異常”響應(yīng)時不一定是正確密碼也可能是觸發(fā)了服務(wù)端限制。有一次跑題看到一個響應(yīng)長度異常大的條目我滿心歡喜地復(fù)制去提交結(jié)果發(fā)現(xiàn)那是服務(wù)器返回的“請求頻率過高請稍后再試”錯誤頁。實際上正確密碼對應(yīng)的響應(yīng)長度并沒那么顯眼混在普通失敗響應(yīng)里毫不起眼。從那以后我學(xué)到一個教訓(xùn)不要只看長度差異要結(jié)合響應(yīng)內(nèi)容一起判斷。把可疑條目放到Repeater里手動重放一次確認它呈現(xiàn)的確實是“登錄成功”的特征再作為最終結(jié)果使用。重放這一步也很有價值因為很多時候正確密碼能被暴力跑出來但你需要驗證它是不是當(dāng)前的唯一有效值以及登錄之后能觸發(fā)的后續(xù)邏輯是什么。還有一個小提醒爆破過程中不停刷新頁面或重復(fù)提交請求會把自己的會話擠掉或觸發(fā)防護機制有時題目本身還會在服務(wù)端記錄嘗試次數(shù)次數(shù)一到封鎖IP。遇到這種情況最有效的方法是等幾分鐘再繼續(xù)或者直接換一個網(wǎng)絡(luò)出口重新開始。心態(tài)穩(wěn)一點不要因為幾次失敗就頻繁重試反而把自己逼進死胡同。