分析實戰(zhàn))
很多剛接觸Web方向CTF的同學(xué)看到題目標(biāo)簽寫著“爆破”第一反應(yīng)就是打開Burp Suite把字典往Intruder里一甩然后盯著進(jìn)度條等結(jié)果。我剛開始也是這樣但結(jié)局通常比較尷尬要么幾千條記錄跑完全是同一個狀態(tài)碼要么正確結(jié)果淹沒在一堆長響應(yīng)里根本認(rèn)不出來。后來我才意識到CTF里的爆破尤其是入門階段的爆破真正考的從來不是“跑得快”而是“看得懂”——你得先弄清楚這個登錄邏輯有沒有校驗、哪個參數(shù)參與了判斷、返回包給了你什么信號然后才知道該不該爆、怎么爆、用什么字典爆。這篇內(nèi)容主要圍繞ctfshow這類Web入門靶場的“爆破”專題展開適合剛接觸Web題、想系統(tǒng)搞懂Burp Intruder用法、以及卡在爆破題不知道如何分析響應(yīng)結(jié)果的初學(xué)者。我會從題目邏輯、工具配置、實戰(zhàn)場景、響應(yīng)分析、字典構(gòu)造這幾個維度拆開講最后再把那些讓我白跑過N次的坑一并列出來。讀完不敢說你立刻能打穿所有爆破題但至少遇到“爆破”標(biāo)簽時你不會再像個沒頭蒼蠅一樣亂撞。1. 爆破題到底在考什么先看清題目再說跑不跑1.1 遇到“爆破”標(biāo)簽先別急著上字典很多人拿到題的第一步就錯了。看到標(biāo)簽寫“爆破”下意識覺得“這不就是暴力破解嗎”于是趕緊加載字典開始跑。但CTF的出題思路和現(xiàn)實滲透不一樣它更看重你對邏輯的理解而不是計算速度。爆破標(biāo)簽往往只代表“你需要通過枚舉某個參數(shù)來得到答案”至于這個參數(shù)是密碼、驗證碼、token還是某個隱藏文件名題目不會直接告訴你。拿最典型的登錄爆破來說一個看起來普普通通的登錄框可能藏了三種完全不同的考法第一種就是純?nèi)蹩诹钭值淅镉芯统龅诙N是密碼雖然弱但服務(wù)端對用戶名和密碼分別返回不同提示比如“用戶名不存在”和“密碼錯誤”這時候你不需要暴力破解密碼先把用戶名枚舉出來就贏了一大半第三種是整個登錄邏輯有缺陷密碼參數(shù)壓根沒參與校驗?zāi)汶S便填個密碼都能過。所以我的習(xí)慣是拿到爆破題先別開Intruder先手動拿Burp抓一次包仔細(xì)看請求參數(shù)、響應(yīng)內(nèi)容、有沒有奇怪的頭再決定下一步。這個習(xí)慣讓我少跑了很多冤枉字典。1.2 入門爆破題的三種常見隱藏邏輯我刷入門題刷多了之后發(fā)現(xiàn)所謂“爆破”基本可以歸納成三種隱藏邏輯你可以在做題時照著這個思路去套。第一種是“弱口令即答案”。出題人把密碼設(shè)成admin、123456、password這類常見值然后故意不告訴你讓你用字典去試。這種題最單純但坑在于它可能在某個請求頭里加了一個自定義字段或者在表單里藏了一個默認(rèn)值你沒注意到就會一直失敗。第二種是“條件差異暴露信息”。服務(wù)端邏輯寫得不嚴(yán)謹(jǐn)比如登錄失敗時對“用戶不存在”和“密碼錯誤”返回兩套不同的響應(yīng)文案。這種題考的其實是信息收集和差異比對而不是真正的窮舉。你只需要把常見用戶名跑一遍通過響應(yīng)差異找到存在的用戶然后再針對這個用戶枚舉密碼工作量直接小一個數(shù)量級。第三種是“校驗參數(shù)可繞過”。最常見的就是驗證碼只在頁面前端做了校驗或者驗證碼參數(shù)根本沒傳到后端也有的是token參數(shù)固定不變甚至刪掉token請求照樣成功。這類題表面看需要爆破實際考的是你有沒有認(rèn)真看請求包和響應(yīng)包。邏輯一旦被你識破甚至不需要跑字典手改一個包就能出結(jié)果。1.3 為什么爆破題適合Web入門階段練手說實話爆破專題放在入門階段是有道理的。它不像注入、反序列化那樣需要大量底層知識鋪墊你只要會用Burp抓包、能看懂HTTP請求和響應(yīng)就能動手做。而恰恰是這個過程能幫你快速建立起一個非常重要的思維閉環(huán)抓包、改包、看響應(yīng)、判斷結(jié)果。這個閉環(huán)幾乎是所有Web題的基礎(chǔ)能力。刷完爆破題之后你再看別的題目至少知道“登錄框不一定只是登錄框”“響應(yīng)包里的每個字段都有可能是信號”。所以別小看爆破專題它不只是讓你學(xué)會點Intruder的按鈕而是在幫你建立Web題最基本的分析習(xí)慣。2. 工具準(zhǔn)備Burp Suite Intruder 的四種攻擊模式怎么選2.1 為什么首選Burp Intruder而不是一把梭Python入門階段我強烈推薦先把Burp Intruder用熟而不是一上來就寫Python腳本。原因很簡單Intruder把“導(dǎo)入字典、標(biāo)記參數(shù)、跑請求、看響應(yīng)”整個流程做成了可視化操作前后對比非常直觀。你用Python的話光是處理會話、編碼、請求頭、響應(yīng)過濾就要寫一大堆代碼如果某個地方寫錯了還不好排查很容易把精力耗在調(diào)試腳本上而不是題目本身。等把Intruder的套路玩明白了再上手Python腳本會輕松很多。因為那時候你已經(jīng)清楚“我需要循環(huán)替換哪個參數(shù)、響應(yīng)里什么樣的特征代表成功”寫腳本就只是把工具里的邏輯翻譯成代碼而已。而且Python有一說一在處理動態(tài)token、復(fù)雜加解密、自定義編碼這些場景時確實比Intruder靈活得多。所以順序應(yīng)該是先用工具建立思路再用腳本解決進(jìn)階問題。2.2 Sniper、Battering Ram、Pitchfork、Cluster Bomb 的實際適用場景Intruder的Attack Type有四種很多人從來只用Sniper遇到需要多參數(shù)組合的題就懵了。我直接說結(jié)論怎么選其實只看一件事你有幾組需要枚舉的數(shù)據(jù)它們之間是什么關(guān)系。Sniper狙擊手是單payload模式。你只標(biāo)記一個位置用一個字典去跑。適合枚舉密碼、枚舉用戶名、枚舉目錄名這種場景。注意如果你標(biāo)記了兩個位置它也只會一個一個輪流跑不是同時替換兩個位置這個細(xì)節(jié)經(jīng)常有人搞混。Battering Ram撞錘是同一個payload同時替換多個位置。適合那種多個參數(shù)取值必須一致的場景比如用戶名和密碼都是同一個值或者請求里有兩個字段需要保持同步變化。Pitchfork草叉是多組payload按行并行。它要求每個字典的行數(shù)一致第一組的第一行配第二組的第一行第一組的第二行配第二組的第二行。適合“用戶名密碼”的組合枚舉前提是你已經(jīng)整理好了一一對應(yīng)的賬號密碼列表而不是兩堆獨立字典交叉匹配。Cluster Bomb集束炸彈是笛卡爾積。它會拿第一組字典的每一行分別去配第二組字典的所有行產(chǎn)生的請求數(shù)量是兩組字典行數(shù)相乘。適合你既不知道用戶名也不知道密碼只能從兩組字典里交叉試的情況。但代價是請求量爆炸比如100個用戶名乘1000個密碼就是10萬次請求做這道題前先想想適不適合。為了方便你記憶我整理了下面這個表攻擊模式payload組數(shù)組合邏輯典型場景Sniper1逐個替換單個參數(shù)枚舉Battering Ram1但替換多個位置同值替換賬號密碼相同Pitchfork多組按行一一對應(yīng)已知賬號密碼對應(yīng)關(guān)系Cluster Bomb多組笛卡爾積完全未知的組合枚舉2.3 使用Intruder前必須確認(rèn)的三件事工具配置不難但有幾個細(xì)節(jié)搞錯了會浪費大量時間。第一確認(rèn)請求包完整。有些登錄接口需要特定的Cookie、Referer或者Content-Type如果直接抓包后丟進(jìn)Intruder可能會因為缺少某個請求頭而全部失敗。我建議在Proxy History里找到那條登錄請求右鍵Send to Intruder不要自己手敲請求包。第二確認(rèn)變量標(biāo)記的邊界。雙擊選中參數(shù)值時要精確比如password123456只需要標(biāo)記123456這六個字符不要把password也框進(jìn)去。如果框錯了服務(wù)端收到的是password123456這種畸形數(shù)據(jù)你跑一整天也不會有結(jié)果。第三確認(rèn)線程數(shù)。別一上來就開50個線程很多入門靶場都有簡單防護跑太快直接給你返回429或者封IP后面什么都做不了。一般先從1到5個線程開始跑一個小字典確認(rèn)流程能通再慢慢加。速度不是爆破題的核心穩(wěn)定才是。3. 實戰(zhàn)場景拆解從登錄表單到token驗證3.1 場景一最樸素的賬號密碼枚舉先講最常規(guī)的登錄爆破。假設(shè)你抓到的登錄請求長這樣POST /login HTTP/1.1 Host: target Content-Type: application/x-www-form-urlencoded usernameadminpassword123456這種題的正解流程是先把payload標(biāo)記在password后面加載一個常見弱口令字典用Sniper模式跑一遍然后重點看響應(yīng)狀態(tài)碼和長度。手動先發(fā)一次錯誤密碼請求記住響應(yīng)長度是多少跑完后凡是長度跟基線不一樣的基本都是重點觀察對象。如果跑完所有密碼都沒看到差異那就要回頭想是不是用戶名不是admin。有些題故意把用戶名藏在一個備注里或者要你先通過用戶名枚舉找出存在的賬號再回來爆破密碼。別死磕一個點多換幾個思路。3.2 場景二驗證碼形同虛設(shè)的登錄接口入門爆破題特別喜歡在驗證碼上做文章。你以為有驗證碼就不能爆破了但實際上很多靶場的驗證碼只是前端畫了個圖后端根本沒校驗或者校驗邏輯只在某個本地JS函數(shù)里。判斷方法很簡單抓登錄請求看提交的參數(shù)里有沒有驗證碼字段。如果頁面顯示驗證碼但請求包里壓根沒這個參數(shù)那說明驗證碼就是個擺設(shè)直接忽略就行。如果請求包里有captcha參數(shù)你隨意填一個值響應(yīng)里如果只提示“用戶名或密碼錯誤”而沒提示“驗證碼錯誤”那同樣說明它沒參與真正的認(rèn)證邏輯。這種題真正要爆破的依然是密碼不是驗證碼。千萬別傻到去搞OCR識別驗證碼那就完全跑偏了。這類題隱藏的邏輯本質(zhì)是你以為有兩道鎖其實第二把鎖是塑料做的掰開就行。3.3 場景三token參與校驗時怎么爆破稍微進(jìn)階一點有些題會在登錄邏輯里加入token參數(shù)每次訪問登錄頁會返回一個隨機token提交登錄時必須帶上。這類題如果用Intruder直接跑大概率全軍覆沒因為token已經(jīng)過期了。面對這種情況入門階段更多考的其實是“你有沒有發(fā)現(xiàn)token能刪掉”。很多靶場雖然生成了token但后端代碼壓根沒校驗?zāi)阍囍裻oken參數(shù)從請求里去掉發(fā)現(xiàn)照樣能登錄那token就只是個心里安慰。真正的隱藏邏輯就又回到了“參數(shù)是否參與校驗”上。如果刪掉token確實會報錯那我會選擇用Python腳本先請求登錄頁提取token再帶著新token去提交密碼循環(huán)這個過程。核心代碼不復(fù)雜就是requests加正則提取import requests import re url http://target/login data {username: admin, password: guess, token: } for pwd in [admin, 123456, password]: resp requests.get(url) token re.search(rnametoken value(.*?), resp.text).group(1) data[token] token data[password] pwd r requests.post(url, datadata) if success in r.text: print(pwd) break當(dāng)然這只是個示意實際提取規(guī)則要看你抓到的HTML結(jié)構(gòu)。重點在于思路動態(tài)參數(shù)不能靠固定包硬跑要么找到它的規(guī)律要么讓它每次請求都重新獲取。3.4 場景四靠狀態(tài)碼和響應(yīng)內(nèi)容區(qū)分的題目還有一些題爆破的結(jié)果不是返回到頁面正文里而是藏在狀態(tài)碼或者響應(yīng)頭里。比如密碼正確時返回302跳轉(zhuǎn)到首頁密碼錯誤時返回200并顯示錯誤信息又比如正確時會set一個Cookie錯誤時則沒有。這種題交給Intruder跑不要只看最后一條要學(xué)會用排序和過濾。跑完之后點擊Status列或者Length列排序異常值一眼就能看出來。如果響應(yīng)頭里的Set-Cookie算是成功標(biāo)志那就在Columns里把Response Header那部分展開來看耐心一點答案就是那個和別人不一樣的包。4. 響應(yīng)分析的判斷邏輯別被200迷惑也別放過3024.1 狀態(tài)碼不是唯一標(biāo)準(zhǔn)剛開始刷題的人有個通病只盯著狀態(tài)碼200看以為返回200就是成功。其實在爆破場景里200恰恰是最大的干擾項。錯誤密碼返回200正確密碼可能也返回200只是頁面文案不同有些靶場正確密碼會返回302跳轉(zhuǎn)有些則干脆返回404來迷惑你。我的建議是把狀態(tài)碼當(dāng)成參考信號之一而不是唯一標(biāo)準(zhǔn)。每次爆破前先手動提交一次錯誤密碼記錄“錯誤基線”也手動提交一次你覺得可能是密碼的值記錄對照然后看這兩者之間到底哪些字段不同。不同點就是你的篩選依據(jù)它可能是狀態(tài)碼、響應(yīng)長度、返回頭、Set-Cookie甚至是響應(yīng)時間。先把差異找出來再決定怎么看Intruder的結(jié)果。4.2 響應(yīng)長度排序是最快的篩選手段當(dāng)你跑完幾千條請求最直觀的篩選方式就是看Length列。大多數(shù)錯誤響應(yīng)的內(nèi)容都是同一個模版長度完全一致。只要有一條響應(yīng)長度跟其他都不一樣十有八九就是正確答案。比如錯誤密碼的響應(yīng)長度穩(wěn)定在600字節(jié)左右突然有一條跑到800字節(jié)那多出來的200字節(jié)大概率就是登錄成功后的歡迎語或者flag信息。反過來也一樣如果正確密碼返回的是一個極簡的302頁面長度比所有錯誤響應(yīng)都短那短的那條就是目標(biāo)。所以在Intruder結(jié)果頁里我第一個看的列永遠(yuǎn)是Length其次才看Status。4.3 用Grep-Match鎖定關(guān)鍵回顯除了手動看長度你還可以在Intruder的Attack Configuration里加Grep-Match選項匹配一些你認(rèn)為成功時會出現(xiàn)的關(guān)鍵詞比如“success”“flag”“welcome”“登錄成功”之類。跑完之后結(jié)果頁會多出一列直接顯示每條響應(yīng)是否包含這些關(guān)鍵詞一眼就能定位答案。不過這里有個細(xì)節(jié)關(guān)鍵詞別選太泛的詞比如“error”因為錯誤響應(yīng)里可能全是“error”你等于沒篩。最好先隨便發(fā)一個正確請求從響應(yīng)里復(fù)制一段獨一無二的文本作為匹配目標(biāo)。還有一種情況是flag本身就是動態(tài)的比如只告訴你“密碼為8位數(shù)字”成功后會直接返回flag那你就用Grep-Match匹配“flag{”不管后面內(nèi)容是什么只要響應(yīng)里出現(xiàn)這個前綴就是成功。5. 字典與Payload構(gòu)造為什么你爆破失敗而別人能出結(jié)果5.1 字典不是越大越好關(guān)鍵詞優(yōu)先很多人解題失敗總覺得是字典不夠大于是去網(wǎng)上找那種幾十GB的超大字典。真實情況是入門靶場的口令大概率就在一個很小的范圍里你拿超大字典不僅慢還容易因為請求量太大觸發(fā)限制。相反一個幾百條精心整理的常見密碼表往往就夠了。我自己的習(xí)慣是先準(zhǔn)備一份“入門級弱口令表”里面包含admin、123456、password、admin123、123456789、qwerty、000000、888888、666666、test、root這類高頻弱口令再補充一些跟題目場景相關(guān)的詞比如題面提到“生日”就加日期格式提到“手機號”就加手機號段。先拿小范圍跑通再用大字典兜底效率高得多。5.2 根據(jù)題目提示“定制”你的字典這里說的定制是指根據(jù)題面信息生成精確的payload集合。很多爆破題會給你暗示比如“密碼是6位數(shù)字”“密碼是姓名的拼音”“密碼是4位小寫字母”。這種題用通用字典反而低效直接用腳本生成才是正解。如果是6位數(shù)字范圍就是000000到999999一百萬條。有些人嫌多但你可以先跑000000-099999這一段因為大部分人設(shè)置六位密碼時不會以0開頭這樣其實可以先測一部分概率高的。生成數(shù)字字典用Python非常簡單with open(digits_6.txt, w) as f: for i in range(1000000): f.write(f{i:06d}\n)如果是拼音就把常見人名拼音和拼音加數(shù)字組合生成一版。比如題目提示“密碼是管理員名字的拼音加123”那字典核心就是zhangsan123、lisi123這種。說白了定制字典靠的是讀題和耐心不是靠工具魔法。5.3 參數(shù)變形與編碼處理的幾個細(xì)節(jié)同一個參數(shù)值經(jīng)過大小寫變化、URL編碼、加前綴后綴之后含義可能完全不一樣。有些題目不會直接驗證你提交的明文而是先做一層轉(zhuǎn)換這時候你就需要用到Burp的Payload Processing。比如你在字典里加了admin但服務(wù)端可能把密碼轉(zhuǎn)成大寫后再比對那你就需要在Payload Processing里添加“Convert to uppercase”規(guī)則又比如接口對某些特殊字符敏感你得添加URL-encode規(guī)則。不過入門階段這種題不算多更常見的是你需要在payload前后加固定前綴比如密碼統(tǒng)一是“abc數(shù)字”的組合這時可以用“Add prefix”和“Add suffix”規(guī)則不用手動改字典。還有個小技巧如果字典里的詞都試過了沒結(jié)果可以試試在Burp的Payload Processing里加“Toggle case”規(guī)則把每個詞的大小寫變體都跑一遍。有些出題人就喜歡把admin改成Admin或者ADMIN來增加一點干擾。6. 比爆破更快的思路先找漏洞入口再動手6.1 翻源碼、看JS、抓接口三步快速偵察每次拿到爆破題我建議你先做一輪快速偵察右鍵查看頁面源代碼翻一翻有沒有注釋把頁面引用的JS文件打開看看經(jīng)常有登錄邏輯寫在前端再到F12的Network面板里過一遍請求看看有沒有更多接口。這一輪偵察可能只需要兩三分鐘但經(jīng)常能省下跑字典的十幾分鐘。我印象里有個典型的例子頁面登錄框下面藏著一行注釋寫著“for test: admin/admin888”這題其實就變成了一道填空題。你甚至都不需要Intruder手動輸進(jìn)去就出了。所以爆破題的答案有時候不在字典里而在你看沒看頁面。除了看注釋還要關(guān)注接口。很多登錄頁不止有/login一個接口可能還有/api/debug、/init、/getflag這類隱藏接口。如果你發(fā)現(xiàn)某個接口直接返回了敏感信息那爆破就更沒必要了。做Web題最怕的就是“只會按部就班跑爆破”一點信息收集意識都沒有。6.2 能繞就繞前端校驗、默認(rèn)憑證、接口泄露爆破題的“爆破”有時候只是標(biāo)簽實際上的正解是繞過。比如驗證碼只在前端校驗后端不管你把驗證碼參數(shù)直接刪了就行。再比如密碼雖然設(shè)置了弱口令但你先試admin/admin、admin/123456這種默認(rèn)憑證很可能一把就過。這些思路不是偷懶而是做題效率的體現(xiàn)。當(dāng)然也要強調(diào)一下這些技巧只在CTF靶場和自己搭的實驗環(huán)境里用。放在真實系統(tǒng)上是違規(guī)行為而且現(xiàn)實中的系統(tǒng)遠(yuǎn)沒有這么好說話。CTF題本身就是設(shè)計出來讓你找邏輯漏洞的這跟真實世界的滲透測試完全是兩碼事。6.3 從“爆破失敗”反推題目設(shè)計者的意圖跑完一輪字典沒有任何一個響應(yīng)出現(xiàn)異常這時候該怎么辦我的建議是別急著換大字典先停下來反推。第一檢查請求參數(shù)名。題目可能真正接收的是passwd字段而不是password你爆了一晚上password當(dāng)然沒反應(yīng)。第二檢查是否缺少某個必填參數(shù)。有的登錄接口除了用戶名密碼還必須傳一個固定的hidden字段這個字段往往在登錄頁面的HTML里你沒帶上就會一直登錄失敗。第三考慮題目是否根本不是“爆破密碼”而是“爆破文件名”或“爆破目錄”。你要用Intruder去試的東西可能不是密碼而是某個路徑。一句話爆破失敗通常不是因為運氣差而是因為思路沒對齊?;▋煞昼姍z查一下請求包和目標(biāo)頁面比盲目堆字典有用的多。7. 實操中容易踩的坑與我的習(xí)慣性檢查清單7.1 四個讓我白跑N次的坑第一個坑是請求頻率太高。有一段時間我跑爆破題習(xí)慣性開50個線程結(jié)果跑了不到一百條請求后面全部變成403。后來我學(xué)乖了線程降到3到5個問題立刻消失。CTF靶場雖然有防護邏輯但不是用來攔住所有人它只是希望你像個正常人一樣發(fā)請求。第二個坑是忘記處理Cookie。有些登錄題的第一步是先訪問登錄頁拿一個Session Cookie你再攜帶這個Cookie去登錄。如果你直接抓包也不帶Cookie或者Cookie已經(jīng)過期那Intruder里所有請求都進(jìn)不了正常邏輯你怎么跑都沒用。第三個坑是攻擊模式選錯。我見過有人把兩個參數(shù)都標(biāo)記了然后用Sniper跑結(jié)果發(fā)現(xiàn)每次只有一個參數(shù)在變另一個始終保持初始值。還有用Pitchfork跑了兩組長度不一樣的字典結(jié)果跑完第一組就停了。模式選錯不是工具的問題是沒理解每種模式的組合邏輯建議對照我前面那個表重新讀一遍。第四個坑是只盯著響應(yīng)正文不看響應(yīng)頭。有些題目的成功標(biāo)志是Set-Cookie或者Location變化正文內(nèi)容反而不變。如果你只看Length和正文就會完美錯過正確答案。7.2 我每次跑爆破前的固定檢查流程我現(xiàn)在跑爆破題已經(jīng)形成了一套固定流程基本不會再出現(xiàn)“跑完一臉懵”的情況。這套流程很簡單但每一步都繞不開抓包后先手動發(fā)一次錯誤請求記錄返回的狀態(tài)碼、長度和關(guān)鍵文案。在瀏覽器里或者通過抓包檢查頁面上有沒有隱藏字段、注釋、JS邏輯。確認(rèn)要爆破的參數(shù)在請求中的位置標(biāo)記準(zhǔn)確。根據(jù)題目提示選擇字典有提示就生成定制字典沒提示就先跑常見弱口令。選擇攻擊模式單參數(shù)用Sniper多參數(shù)組合才考慮Cluster Bomb。線程數(shù)設(shè)置在5以內(nèi)先放一個只包含幾條payload的小字典驗證流程能不能跑通。跑完后先按Length排序再看Status最后用Grep-Match對敏感關(guān)鍵詞做二次篩選。如果所有結(jié)果看起來都一樣回到第一步重新檢查請求包是否少了參數(shù)或者題目思路是不是真的需要爆破。這套流程真正花時間的只有跑字典那一步前面所有檢查加起來不過幾分鐘。大多數(shù)爆破題卡住人卡的都是前期的信息判斷而不是字典本身。7.3 給小白的最后建議如果讓我給正在刷爆破題的人一個建議我會說做完一道題別急著下一道回頭把整個流程再走一遍想想哪些步驟是真正讓你出結(jié)果的。尤其是那種你跑了很久、最后發(fā)現(xiàn)其實跟爆破無關(guān)的題一定要好好復(fù)盤因為你可能從中學(xué)到的不是工具用法而是一種“不要被標(biāo)簽帶偏”的審題意識。我自己刷CTF的體會是爆破專題是所有Web方向題目里最不吃天賦、最吃細(xì)心的一塊。它不像逆向或者密碼學(xué)那樣需要大量數(shù)學(xué)功底你只要養(yǎng)成抓包、改包、看響應(yīng)的習(xí)慣多踩幾次坑之后自然就會了。字典可以慢慢積累工具快捷鍵可以慢慢記憶但“先分析后動手”這個習(xí)慣一定要從一開始就刻意練習(xí)。希望這篇內(nèi)容能幫你少走一些彎路。如果你正在刷ctfshow的Web入門爆破專題遇到某道具體題目卡住了不妨按我前面說的流程走一遍大概率問題不在字典而在你沒注意到的某個參數(shù)上。