1. 項(xiàng)目概述與測(cè)試環(huán)境準(zhǔn)備1.1 為什么選身份驗(yàn)證攻防作為切入點(diǎn)身份驗(yàn)證是所有 Web 應(yīng)用的命門。打靶場(chǎng)和實(shí)戰(zhàn)項(xiàng)目里幾乎每個(gè)系統(tǒng)都掛著登錄框但真正能把認(rèn)證邏輯吃透的測(cè)試者并不多。多數(shù)人停留在看到登錄框就試弱口令的階段遇到驗(yàn)證碼、雙因子認(rèn)證2FA、密碼重置流程就無(wú)從下手。我這次基于 PortSwigger 的認(rèn)證專題實(shí)驗(yàn)挑了幾條有代表性的攻擊鏈路做了系統(tǒng)性復(fù)測(cè)。核心目標(biāo)是搞清楚三件事用戶名枚舉能側(cè)信道泄露多少信息、2FA 的繞過(guò)思路有哪些、Burp Suite 的宏功能如何把復(fù)雜爆破流程自動(dòng)化。如果你正準(zhǔn)備入門 Web 安全或者已經(jīng)在做滲透測(cè)試但缺乏認(rèn)證邏輯的系統(tǒng)性思路這份實(shí)操筆記可以直接當(dāng)參考手冊(cè)用。先說(shuō)明實(shí)驗(yàn)環(huán)境全部用例來(lái)自 PortSwigger 靶場(chǎng)模擬項(xiàng)目 X本地調(diào)試用社區(qū)版 Burp Suite。整個(gè)測(cè)試從信息收集到 2FA 宏自動(dòng)化一共走了七輪完整測(cè)試中間踩了不少坑后面展開細(xì)說(shuō)。1.2 身份驗(yàn)證體系的技術(shù)棧拆解要測(cè)透認(rèn)證邏輯先得知道它由哪些組件拼起來(lái)?，F(xiàn)代 Web 應(yīng)用的認(rèn)證體系通常有四層結(jié)構(gòu)每一層都有獨(dú)立的風(fēng)險(xiǎn)面第一層是憑據(jù)校驗(yàn)層。用戶名和密碼的存儲(chǔ)方式?jīng)Q定了這一層的風(fēng)險(xiǎn)等級(jí)。明文存儲(chǔ)是最糟糕的哈希加鹽是底線像 bcrypt、scrypt 這類自適應(yīng)哈希算法才算合格。測(cè)試時(shí)需要特別注意響應(yīng)時(shí)間差異——如果系統(tǒng)用明文比對(duì)輸入錯(cuò)誤密碼時(shí)校驗(yàn)時(shí)間和正確密碼接近但如果用了哈希計(jì)算碰撞耗時(shí)可能暴露更多信息。第二層是會(huì)話管理層。登錄成功后服務(wù)端發(fā)什么憑證是 Cookie、JWT 還是 Session IDToken 里有沒(méi)有簽名保護(hù)過(guò)期時(shí)間怎么設(shè)置這些參數(shù)直接決定會(huì)話固定攻擊、Token 猜測(cè)攻擊的可行性。第三層是流程控制層。密碼重置、賬號(hào)鎖定、驗(yàn)證碼發(fā)送、2FA 綁定這些都涉及多步驟狀態(tài)流轉(zhuǎn)。很多系統(tǒng)的校驗(yàn)漏洞恰恰不在密碼強(qiáng)度上而在流程跳轉(zhuǎn)上——能不能跳過(guò)某一步、能不能重復(fù)提交某個(gè)請(qǐng)求、能不能在狀態(tài)未更新時(shí)操作下一步。第四層是審計(jì)與日志層。這個(gè)最容易被忽略。登錄失敗次數(shù)限制、IP 封禁閾值、異常登錄提醒決定了攻擊者的枚舉行為會(huì)不會(huì)被攔截。但注意審計(jì)機(jī)制本身也能被濫用——比如通過(guò)錯(cuò)誤信息區(qū)分用戶不存在和密碼錯(cuò)誤就是典型的用戶名枚舉。我在實(shí)驗(yàn)里把這四層全部過(guò)了一遍每一層都找到了對(duì)應(yīng)的實(shí)戰(zhàn)用例。下面的內(nèi)容按攻擊鏈路展開從最基礎(chǔ)的枚舉探測(cè)到 2FA 宏爆破一步步還原完整測(cè)試過(guò)程。2. 用戶名枚舉探測(cè)從響應(yīng)差異到自動(dòng)化識(shí)別2.1 響應(yīng)差異分析——先別急著上工具用戶名枚舉的核心不是工具是觀察差異。我在模擬項(xiàng)目 X 的測(cè)試中用 Intruder 同時(shí)對(duì)登錄接口跑了兩個(gè)用戶字典一個(gè)混合了常見(jiàn)用戶名和隨機(jī)字符串另一個(gè)是純隨機(jī)字符串。關(guān)鍵在于對(duì)比不同用戶名提交后的響應(yīng)細(xì)節(jié)。第一層看狀態(tài)碼。部分系統(tǒng)對(duì)存在和不存在的用戶名返回不同 HTTP 狀態(tài)碼比如 200 和 302 的區(qū)別。第二層看響應(yīng)體長(zhǎng)度可以用 Burp 的Length列排序差異值。第三層看響應(yīng)時(shí)間如果系統(tǒng)對(duì)不存在用戶提前結(jié)束查詢響應(yīng)時(shí)間會(huì)出現(xiàn)微妙差異。第四層看響應(yīng)體內(nèi)容錯(cuò)誤信息里的細(xì)節(jié)最容易泄露信息——用戶名不存在和密碼錯(cuò)誤是最高危的寫法甚至有些系統(tǒng)還會(huì)把密碼錯(cuò)誤的原因?qū)懗鰜?lái)比如密碼與用戶名不匹配。測(cè)試時(shí)用 Intruder 的Grep-Extract功能提取響應(yīng)中的錯(cuò)誤信息然后對(duì)結(jié)果做一次分組統(tǒng)計(jì)。我在模擬項(xiàng)目 X 中找到了一個(gè)有趣的現(xiàn)象用戶不存在時(shí)響應(yīng)體固定為 62 個(gè)字節(jié)用戶存在時(shí)是 68 個(gè)字節(jié)這個(gè) 6 字節(jié)的差距來(lái)自錯(cuò)誤描述中的微調(diào)。這個(gè)差異非常穩(wěn)定可以直接自動(dòng)化識(shí)別。但別忽略響應(yīng)時(shí)間這個(gè)維度。很多系統(tǒng)為了防止時(shí)序攻擊故意對(duì)用戶不存在和密碼錯(cuò)誤做了相同邏輯處理響應(yīng)體完全一致。這時(shí)候時(shí)間差就成了突破口。我在模擬項(xiàng)目 X 的某一版實(shí)驗(yàn)中用存在用戶的登錄請(qǐng)求平均耗時(shí) 128ms不存在用戶平均耗時(shí) 91ms37ms 的差距足夠被請(qǐng)求組統(tǒng)計(jì)捕捉到。提示枚舉結(jié)果必須做一個(gè)二次確認(rèn)。單純響應(yīng)體長(zhǎng)度差異可能來(lái)自緩存、隨機(jī) token 等因素建議至少用 3 組不同的用戶名字典做交叉驗(yàn)證誤差率低于 5% 才認(rèn)定為有效差異。2.2 自動(dòng)化識(shí)別腳本實(shí)操光靠手工看響應(yīng)太慢我寫了段 Python 腳本配合 Burp 的導(dǎo)出功能做批量識(shí)別。完整邏輯是先用 Intruder 跑一輪全字典枚舉把結(jié)果導(dǎo)出為 CSV再腳本統(tǒng)計(jì)長(zhǎng)度分布、時(shí)間分布和錯(cuò)誤信息關(guān)鍵詞分布。import csv import statistics def analyze_responses(file_path): length_groups {} time_values [] keyword_hits {} with open(file_path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: length len(row[Response].encode(utf-8)) if length not in length_groups: length_groups[length] [] length_groups[length].append(row[Payload]) time_ms int(row[Time]) time_values.append((row[Payload], time_ms)) for keyword in [不存在, Not Found, invalid user, incorrect password]: if keyword in row[Response]: if keyword not in keyword_hits: keyword_hits[keyword] [] keyword_hits[keyword].append(row[Payload]) print( 長(zhǎng)度分組 ) for length, users in sorted(length_groups.items()): print(f長(zhǎng)度 {length}: {len(users)} 個(gè)樣本, 示例: {users[:5]}) print(\n 時(shí)間統(tǒng)計(jì) ) times [t[1] for t in time_values] avg_time statistics.mean(times) print(f平均響應(yīng)時(shí)間: {avg_time:.2f}ms) for payload, t in time_values: if t avg_time * 1.5 or t avg_time * 0.6: print(f異常耗時(shí): {payload} - {t}ms) print(\n 關(guān)鍵詞命中 ) for keyword, users in keyword_hits.items(): print(f關(guān)鍵詞 [{keyword}]: {len(users)} 個(gè), 示例: {users[:5]})這段腳本的核心邏輯不復(fù)雜但處理 CSV 時(shí)有幾個(gè)細(xì)節(jié)值得注意CSV 導(dǎo)出時(shí) Burp 會(huì)把響應(yīng)體里的逗號(hào)和引號(hào)做轉(zhuǎn)義直接用 csv 模塊讀取可能導(dǎo)致截?cái)嘟ㄗh導(dǎo)出時(shí)選CSV without header選項(xiàng)或者改用 Burp 的Copy all粘貼后保存成文本再逐行解析。另外響應(yīng)體里的非 ASCII 字符比如中文錯(cuò)誤信息在 CSV 里可能顯示為轉(zhuǎn)義序列腳本里最好統(tǒng)一做 Unicode 解碼否則長(zhǎng)度統(tǒng)計(jì)會(huì)偏。實(shí)測(cè)數(shù)據(jù)模擬項(xiàng)目 X 的登錄接口跑完 500 組用戶名后長(zhǎng)度分組出現(xiàn)了兩個(gè)異常聚集區(qū)——62 字節(jié)出現(xiàn) 417 次68 字節(jié)出現(xiàn) 83 次。結(jié)合時(shí)間統(tǒng)計(jì)我把 83 個(gè)候選用戶名全部標(biāo)記出來(lái)隨機(jī)抽了 10 個(gè)做了手工驗(yàn)證全部確認(rèn)存在。這個(gè)結(jié)果直接指導(dǎo)了后續(xù)密碼噴灑的目標(biāo)集。2.3 枚舉防護(hù)與反制策略測(cè)完靶場(chǎng)得聊聊實(shí)際生產(chǎn)環(huán)境中會(huì)遇到的情況?，F(xiàn)實(shí)中枚舉防護(hù)基本有三道防線每一道都能讓上面的腳本失效大半。第一道是行為限制。登錄失敗次數(shù)超過(guò)閾值就鎖定賬號(hào)或 IP這個(gè)最直接但應(yīng)對(duì)手段也多——分布式代理池、慢速輪換、每次請(qǐng)求隨機(jī)延時(shí)就繞過(guò)去了。不過(guò)注意鎖定策略本身也可能被濫用有些系統(tǒng)會(huì)以賬號(hào)已鎖定作為額外信息反而暴露了用戶名的有效性。第二道是響應(yīng)混淆。用固定的錯(cuò)誤消息、隨機(jī)的 Token 追加、時(shí)間戳擾動(dòng)來(lái)抹平響應(yīng)差異。這種防御對(duì)自動(dòng)化識(shí)別影響很大我在模擬項(xiàng)目 X 的后續(xù)版本里加了隨機(jī) 2-9ms 的響應(yīng)時(shí)間抖動(dòng)腳本的時(shí)間維度識(shí)別率立刻下降了大半。第三道是接口監(jiān)控。異常的高頻請(qǐng)求、行為模式識(shí)別這類通常在 WAF 層做目標(biāo)不是阻止枚舉而是記錄攻擊者 IP 和手法。測(cè)試時(shí)要注意在合法的授權(quán)范圍內(nèi)操作別碰生產(chǎn)環(huán)境否則容易被誤判為真實(shí)攻擊。注意枚舉探測(cè)的邊界是只探測(cè)不攻擊。識(shí)別出有效用戶名后不要在未授權(quán)系統(tǒng)上繼續(xù)嘗試登錄這會(huì)直接觸發(fā)賬號(hào)鎖定也可能構(gòu)成越權(quán)行為。我在所有實(shí)驗(yàn)中只在靶場(chǎng)環(huán)境做完整鏈路測(cè)試現(xiàn)實(shí)項(xiàng)目只做防御驗(yàn)證不做真實(shí)攻擊。3. 密碼策略分析與弱口令入口3.1 密碼策略的探測(cè)方法識(shí)別出有效用戶名后下一步是密碼測(cè)試。但直接盲目爆破會(huì)觸發(fā)鎖定機(jī)制——我見(jiàn)過(guò)太多人在這一步栽跟頭了。正確做法是先探測(cè)系統(tǒng)的密碼策略搞清楚它強(qiáng)制了什么、沒(méi)強(qiáng)制什么。探測(cè)密碼策略有幾個(gè)入口可以試。第一個(gè)是注冊(cè)頁(yè)面如果系統(tǒng)開放注冊(cè)直接在注冊(cè)表單里提交不同復(fù)雜度的密碼看校驗(yàn)邏輯報(bào)什么錯(cuò)。第二個(gè)是密碼重置流程重置頁(yè)面通常會(huì)說(shuō)明密碼要求比如8-30 位需包含大小寫和數(shù)字。第三個(gè)是修改密碼接口請(qǐng)求里通常帶著密碼復(fù)雜度校驗(yàn)參數(shù)。第四個(gè)是響應(yīng)體里的 Score 字段有些系統(tǒng)的密碼強(qiáng)度是前端計(jì)算的把請(qǐng)求里的 score 改成 100 就能繞過(guò)前端校驗(yàn)這個(gè)在 JS 安全檢查不嚴(yán)的應(yīng)用里特別常見(jiàn)。我在模擬項(xiàng)目 X 中測(cè)到一個(gè)典型案例注冊(cè)頁(yè)面的密碼規(guī)則要求至少 8 位包含字母和數(shù)字但重置密碼流程的校驗(yàn)邏輯比注冊(cè)頁(yè)寬松——只查長(zhǎng)度、不查字符組合。這直接導(dǎo)致攻擊面擴(kuò)大因?yàn)槿蹩诹钊?password123 在注冊(cè)時(shí)會(huì)被拒但在重置流程里卻能通過(guò)驗(yàn)證。這種跨流程校驗(yàn)不一致的問(wèn)題在大型系統(tǒng)里很普遍因?yàn)樽?cè)、登錄、重置往往是不同團(tuán)隊(duì)不同時(shí)期開發(fā)的。3.2 基于策略的密碼字典定制密碼策略探測(cè)不是白做的它直接指導(dǎo)字典構(gòu)建。如果系統(tǒng)要求8-16 位必須有大寫字母和數(shù)字你直接用 rockyou 暴力嘗試肯定浪費(fèi)大量請(qǐng)求。正確做法是定制一個(gè)合規(guī)弱密碼字典?；诿艽a策略構(gòu)建字典的核心思路是在滿足規(guī)則的前提下用最弱的密碼組合。比如系統(tǒng)要求包含大寫字母和數(shù)字那首字母大寫加上數(shù)字尾巴的組合就值得優(yōu)先試——Password1、Admin123、Welcome1這些是最容易出現(xiàn)的合規(guī)弱密碼。我寫了一個(gè)簡(jiǎn)單的生成腳本先按通行的弱密碼清單做模板替換再用密碼策略做過(guò)濾base_words [password, admin, welcome, letmein, qwerty, test] common_patterns [ lambda w: w.capitalize() 1, lambda w: w.capitalize() 123, lambda w: w.capitalize() !, lambda w: w.capitalize() 2024, lambda w: w.upper() 123, ] def generate_passwords(required_length8, need_upperTrue, need_digitTrue): candidates [] for word in base_words: for pattern in common_patterns: pwd pattern(word) if len(pwd) required_length: continue if need_upper and not any(c.isupper() for c in pwd): continue if need_digit and not any(c.isdigit() for c in pwd): continue candidates.append(pwd) return candidates實(shí)際跑下來(lái)模擬項(xiàng)目 X 的密碼策略要求最少 8 位、必須有數(shù)字這個(gè)生成器產(chǎn)出的 30 個(gè)密碼里命中了 2 個(gè)比直接跑大字典效率高很多。但要注意一點(diǎn)靶場(chǎng)環(huán)境密碼基本都在常規(guī)弱口令池里生產(chǎn)環(huán)境有鎖策略的話單賬號(hào)不能連猜太多次密碼噴灑需要把用戶名和密碼的配對(duì)順序隨機(jī)打散降低觸發(fā)風(fēng)控的概率。3.3 常見(jiàn)密碼策略漏洞挖掘密碼策略本身也有漏洞可挖不只是防御方的設(shè)定問(wèn)題。我在測(cè)試中發(fā)現(xiàn)三種典型的策略漏洞。第一種是策略版本不統(tǒng)一。系統(tǒng)在普及強(qiáng)密碼規(guī)則前就存在的舊賬號(hào)不會(huì)被強(qiáng)制更新密碼這些歷史遺留賬號(hào)可能還用著老弱密碼。可以通過(guò)注冊(cè)頁(yè)面的忘記密碼流程探測(cè)——如果重置流程要求驗(yàn)證舊密碼而驗(yàn)證規(guī)則比當(dāng)前策略寬松就能反推出該賬號(hào)創(chuàng)建時(shí)代的策略版本。第二種是密碼歷史檢查繞過(guò)。有些系統(tǒng)在修改密碼時(shí)禁止重復(fù)使用最近 3 次的密碼但最近 3 次的記錄可能只在密碼修改成功時(shí)更新。如果連續(xù)修改兩次讓校驗(yàn)邏輯覆蓋的窗口錯(cuò)位就能用回最初的舊密碼。第三種是密碼提示語(yǔ)的泄露。系統(tǒng)安全知識(shí)問(wèn)答密保問(wèn)題的設(shè)計(jì)缺陷比如問(wèn)題是你的出生城市答案在社交平臺(tái)上可能被公開。密保問(wèn)題本來(lái)就比密碼弱一旦攻擊者拿到用戶名和密保答案重置密碼流程直接就能攻破。生產(chǎn)環(huán)境里認(rèn)證流程是串聯(lián)的密碼策略只是一個(gè)環(huán)節(jié)。攻擊者真正要找的不是最強(qiáng)策略而是從注冊(cè)到修改到重置這一整條鏈路里最薄弱的一環(huán)。所以做測(cè)試時(shí)別只盯著登錄框密碼重置頁(yè)、賬號(hào)恢復(fù)流程、API 接口里的密碼字段全都要測(cè)一遍。4. 2FA 繞過(guò)鏈路實(shí)戰(zhàn)——從邏輯缺陷到宏爆破4.1 2FA 機(jī)制的分類與薄弱點(diǎn)2FA 的設(shè)計(jì)初衷是增加攻擊者的成本但實(shí)現(xiàn)不當(dāng)反而可能降低整體安全性。核心問(wèn)題在于2FA 的校驗(yàn)位置、次數(shù)限制、狀態(tài)管理、時(shí)間窗口哪個(gè)環(huán)節(jié)先被突破整個(gè)機(jī)制就形同虛設(shè)。從實(shí)現(xiàn)角度分類常見(jiàn)的 2FA 有三種形態(tài)。第一種是驗(yàn)證碼型短信或郵件發(fā)送一次性驗(yàn)證碼用戶手動(dòng)輸入。這種形態(tài)的薄弱點(diǎn)在于驗(yàn)證碼的位數(shù)4 位只有 10000 種組合可爆破和校驗(yàn)邏輯服務(wù)端校驗(yàn)和客戶端校驗(yàn)混合處理有時(shí)圖形驗(yàn)證碼只是前端裝飾。第二種是 TOTP 型基于時(shí)間的一次性密碼典型的如 Google Authenticator。TOTP 本身密碼空間很大6 位數(shù)字但只有 30 秒有效期有防爆破設(shè)計(jì)但實(shí)現(xiàn)混亂時(shí)可能出現(xiàn)時(shí)間窗口漂移、碼復(fù)用。第三種是推送確認(rèn)型用戶必須在手機(jī)上手動(dòng)點(diǎn)擊確認(rèn)。這種形態(tài)的主要風(fēng)險(xiǎn)是會(huì)話固定和綁定流程繞過(guò)——比如攻擊者提前做好綁定受害者確認(rèn)的其實(shí)是攻擊者的會(huì)話。我這次實(shí)驗(yàn)重點(diǎn)做的是驗(yàn)證碼型 2FA 的繞過(guò)。PortSwigger 的靶場(chǎng)給出了典型的缺陷場(chǎng)景2FA 驗(yàn)證碼限制在 4 位數(shù)字且服務(wù)端關(guān)閉了請(qǐng)求頻率限制。這種情況下驗(yàn)證碼的唯一保護(hù)就只剩爆破難度。4 位數(shù)字的組合是 0000-9999用 Burp Intruder 全量跑一輪只需要幾分鐘配合后面的宏功能就能完全自動(dòng)化。但如果驗(yàn)證碼是 6 位數(shù)字全量爆破需要 100 萬(wàn)次請(qǐng)求沒(méi)有繞過(guò)手段的情況下基本不可行。4.2 手工繞過(guò)鏈路復(fù)現(xiàn)先說(shuō)靶場(chǎng)標(biāo)準(zhǔn)場(chǎng)景的完整繞過(guò)鏈路。這個(gè)流程我建議每個(gè)人都手工復(fù)現(xiàn)一遍因?yàn)楹罄m(xù)的宏自動(dòng)化邏輯完全建立在這個(gè)手動(dòng)流程之上。第一步正常登錄。輸入有效用戶名和密碼如果你之前枚舉出了有效賬號(hào)這一步順理成章。登錄成功后服務(wù)端返回一個(gè) Login Token通常是 Cookie 里的 session 標(biāo)識(shí)。第二步觸發(fā) 2FA 驗(yàn)證。系統(tǒng)向預(yù)設(shè)的郵箱發(fā)送 4 位驗(yàn)證碼同時(shí)頁(yè)面跳轉(zhuǎn)到驗(yàn)證碼輸入框。這個(gè)階段的關(guān)鍵觀察點(diǎn)驗(yàn)證碼請(qǐng)求成功后服務(wù)端是否更新了 Token有的系統(tǒng)在發(fā)送驗(yàn)證碼時(shí)重置了會(huì)話標(biāo)識(shí)有的保持不變——這決定了后續(xù)能否用舊 Token 直接繞過(guò)驗(yàn)證。第三步攜帶 Token 提交驗(yàn)證碼。發(fā)送 POST 請(qǐng)求body 里帶驗(yàn)證碼字段和會(huì)話 Token。如果驗(yàn)證碼正確服務(wù)端頒發(fā)新的會(huì)話標(biāo)識(shí)如果錯(cuò)誤返回校驗(yàn)失敗信息。第四步在 Burp 里開啟 Intruder設(shè)置驗(yàn)證碼字段為 payload 位置payload 類型選Numbers從 0000 到 9999步長(zhǎng) 1。線程數(shù)建議控制在 1避免因并發(fā)導(dǎo)致驗(yàn)證碼被請(qǐng)求風(fēng)暴淹沒(méi)。第五步執(zhí)行爆破。全部 10000 個(gè)組合跑完大概需要幾分鐘通過(guò)響應(yīng)長(zhǎng)度或狀態(tài)碼變化鎖定成功請(qǐng)求。實(shí)測(cè)中我發(fā)現(xiàn)一個(gè)細(xì)節(jié)靶場(chǎng)的驗(yàn)證碼校驗(yàn)失敗時(shí)返回的響應(yīng)長(zhǎng)度是固定的成功時(shí)響應(yīng)里帶一個(gè) Set-Cookie 指令。所以一眼就能從 Intruder 的結(jié)果列表里找到唯一長(zhǎng)的那個(gè)條目。4.3 Burp Macros 實(shí)現(xiàn) 2FA 宏爆破手工流程可行的前提是每次驗(yàn)證碼校驗(yàn)失敗后Token 保持不變。如果系統(tǒng)在每次校驗(yàn)失敗后都刷新 Token手工 Intruder 爆破就會(huì)失效——因?yàn)槊看翁峤或?yàn)碼用的都是舊 Token服務(wù)端直接拒絕。模擬項(xiàng)目 X 的進(jìn)階版本就做了這樣的防護(hù)每次提交驗(yàn)證碼失敗后服務(wù)端會(huì)刷新 Login Token舊 Token 作廢。這時(shí)候手工爆破完全沒(méi)法執(zhí)行。解決方案就是 Burp Suite 的 Session Handling Rules Macros。Macro 的核心能力是在每次請(qǐng)求前自動(dòng)執(zhí)行一組預(yù)定義請(qǐng)求并把響應(yīng)中的關(guān)鍵值提取出來(lái)替換到待發(fā)請(qǐng)求中。針對(duì) 2FA 爆破的場(chǎng)景我配置了一個(gè)三步宏第一步向驗(yàn)證碼發(fā)送接口發(fā)起請(qǐng)求用新鮮 Cookie 觸發(fā)新的驗(yàn)證碼下發(fā)這一步模擬用戶重新觸發(fā) 2FA 驗(yàn)證碼發(fā)送。第二步從響應(yīng)中提取新的 CSRF Token 和 Login Token。第三步把提取值替換進(jìn)爆破請(qǐng)求。這個(gè)宏的執(zhí)行周期是每請(qǐng)求執(zhí)行一次也就是爆破 10000 次驗(yàn)證碼宏也會(huì)同步執(zhí)行 10000 次驗(yàn)證碼發(fā)送請(qǐng)求。開銷看起來(lái)大但因?yàn)槭潜镜氐桨袌?chǎng)請(qǐng)求延時(shí)可控實(shí)測(cè)全流程跑完比手工快得多且不需要人工干預(yù)。具體配置步驟先建宏。在 Burp 的 Project Options - Sessions - Macros 里點(diǎn) Add錄一個(gè) POST 請(qǐng)求到發(fā)送驗(yàn)證碼接口。關(guān)鍵參數(shù)是請(qǐng)求里帶當(dāng)前 Cookie 和 CSRF Token響應(yīng)里用 Session Handling Rules 提取 CSRF Token 和新的 Login Token。提取規(guī)則用正則解析響應(yīng)體里的 name 屬性和 Cookie 頭里的 session 標(biāo)識(shí)。再建 Session Handling Rule。在 Sessions - Session Handling Rules 里添加規(guī)則Scope 選擇 Intruder 要爆破的驗(yàn)證碼提交接口Action 里選 Run a macro選剛才建好的宏并設(shè)置更新請(qǐng)求中的 Cookie/CSRF 參數(shù)選項(xiàng)。最后是 Intruder 配置。Payload 還是 0000-9999但線程數(shù)可以調(diào)高到 5-10因?yàn)楹陼?huì)保證每次請(qǐng)求都是新鮮 Token。我實(shí)際測(cè)試用 10 線程跑了 10000 個(gè)組合大概 20 分鐘跑完成功命中驗(yàn)證碼。經(jīng)驗(yàn)分享宏里請(qǐng)求的 Cookie 更新這塊最容易被忽略。如果宏執(zhí)行后提取到的 Cookie 沒(méi)有替換到主請(qǐng)求中爆破請(qǐng)求永遠(yuǎn)是舊 Session服務(wù)端照樣拒絕。配置完規(guī)則后必須先在 Repeater 里做一次手動(dòng)驗(yàn)證確認(rèn)宏能正常刷新 Token再開 Intruder 跑全量。4.4 繞過(guò) 2FA 的擴(kuò)展思路宏爆破只是 2FA 繞過(guò)的其中一條路子。模擬項(xiàng)目 X 里我還驗(yàn)證了幾種無(wú)需爆破的繞過(guò)方式其中一種特別有意思——直接跳過(guò)驗(yàn)證步驟。有些系統(tǒng)把 2FA 的校驗(yàn)狀態(tài)寫在請(qǐng)求參數(shù)里比如step字段或authenticated標(biāo)志位。如果服務(wù)端對(duì)狀態(tài)參數(shù)的取值沒(méi)做嚴(yán)格校驗(yàn)攻擊者可以直接修改該類參數(shù)跳轉(zhuǎn)到已認(rèn)證狀態(tài)。我在測(cè)試中復(fù)現(xiàn)過(guò)一個(gè)場(chǎng)景驗(yàn)證碼校驗(yàn)請(qǐng)求的響應(yīng)里帶了一個(gè)2FA_Status: pending頭改成passed后服務(wù)端直接發(fā)放了完整登錄態(tài)驗(yàn)證碼環(huán)節(jié)完全被跳過(guò)。另一種思路是暴力替換會(huì)話 Cookie。有些應(yīng)用在觸發(fā) 2FA 時(shí)會(huì)同時(shí)下發(fā)臨時(shí)會(huì)話 Cookie和完整會(huì)話 Cookie完整 Cookie 存儲(chǔ)在響應(yīng)頭但前端不讀取。測(cè)試時(shí)重點(diǎn)關(guān)注響應(yīng)里的 Set-Cookie 指令看看是不是已經(jīng)有預(yù)先認(rèn)證的 Cookie被下發(fā)出來(lái)了。還有一種繞法叫并行會(huì)話。同一個(gè)賬號(hào)在設(shè)備 A 上只完成了密碼登錄、還沒(méi)輸入驗(yàn)證碼在設(shè)備 B 上直接發(fā)起新的登錄請(qǐng)求——如果系統(tǒng)沒(méi)有全局會(huì)話鎖定理論上可以通過(guò)多個(gè)并行登錄請(qǐng)求來(lái)混淆服務(wù)端的狀態(tài)追蹤。這個(gè)我沒(méi)在靶場(chǎng)里完全復(fù)現(xiàn)但實(shí)際滲透測(cè)試中見(jiàn)過(guò)類似問(wèn)題值得列為排查項(xiàng)。繞過(guò) 2FA 的測(cè)試思路本質(zhì)是驗(yàn)證碼本身只是一個(gè)校驗(yàn)點(diǎn)真正的安全邊界應(yīng)該是會(huì)話狀態(tài)的變化路徑。測(cè)試階段要把關(guān)注點(diǎn)從驗(yàn)證碼能不能爆破轉(zhuǎn)向會(huì)話從待驗(yàn)證到已驗(yàn)證的轉(zhuǎn)變受哪些參數(shù)控制、有沒(méi)有被意外修改的漏洞。5. 宏爆破的配置細(xì)節(jié)與參數(shù)調(diào)優(yōu)5.1 Session Handling 規(guī)則配置詳解宏爆破聽(tīng)起來(lái)簡(jiǎn)單實(shí)際配置時(shí)容易卡住全卡在 Session Handling 的參數(shù)替換上。我把每一處配置細(xì)節(jié)展開說(shuō)明你照做基本能一次跑通。第一步明確宏的作用域。Session Handling Rule 有一個(gè) Scope 設(shè)置我建議精確指定 Intruder 要打的驗(yàn)證碼提交接口不要用所有請(qǐng)求這類寬泛范圍。因?yàn)楹昝空?qǐng)求執(zhí)行一次如果作用域過(guò)寬Repeater 里的每一個(gè)手工請(qǐng)求也會(huì)觸發(fā)宏直接把你正在用的會(huì)話擠掉測(cè)試直接翻車。第二步抓取發(fā)送驗(yàn)證碼的請(qǐng)求。在登錄后手動(dòng)點(diǎn)擊發(fā)送驗(yàn)證碼從 HTTP History 里找到對(duì)應(yīng)的 POST 請(qǐng)求。這個(gè)請(qǐng)求必須包含三個(gè)關(guān)鍵部分會(huì)話 Cookie、CSRF Token、目標(biāo)郵箱地址。有些系統(tǒng)的驗(yàn)證碼發(fā)送接口還需要確認(rèn)當(dāng)前用戶身份的 Token一并帶上。第三步創(chuàng)建宏并配置提取規(guī)則。在 Macro Editor 里選中剛抓取的發(fā)送驗(yàn)證碼請(qǐng)求點(diǎn) Configure Item 進(jìn)入?yún)?shù)提取配置。提取規(guī)則有幾個(gè)類型Cookie 提取、請(qǐng)求頭提取、響應(yīng)體參數(shù)提取、正則提取。我需要提取兩類數(shù)據(jù)CSRF Token通常在響應(yīng)體或響應(yīng)頭里、新頒發(fā)的 Login Token通常在 Set-Cookie 里。正則表達(dá)式要根據(jù)靶場(chǎng)的實(shí)際響應(yīng)格式來(lái)寫建議先用 Repeater 手工發(fā)一次請(qǐng)求觀察響應(yīng)格式再寫正則。第四步配置宏輸出映射。在 Session Handling Rule 的 Action 設(shè)置里宏執(zhí)行完后需要把提取的值映射到主請(qǐng)求中。這里有三個(gè)關(guān)鍵映射更新主請(qǐng)求的 Cookie 頭、更新主請(qǐng)求的 CSRF Token 參數(shù)、替換或附加自定義請(qǐng)求頭。映射錯(cuò)誤的主因是用錯(cuò)了參數(shù)名比如系統(tǒng)用的字段是 loginToken 而不是 token映射關(guān)系必須和實(shí)際請(qǐng)求體嚴(yán)格一致。第五步驗(yàn)證配置。完成規(guī)則配置后先在 Repeater 里手動(dòng)發(fā)一個(gè)驗(yàn)證碼提交請(qǐng)求帶著舊的登錄 Token觀察宏是否自動(dòng)執(zhí)行了發(fā)送新驗(yàn)證碼的預(yù)請(qǐng)求、是否更新了 Token。如果響應(yīng)還是校驗(yàn)失敗多半是宏沒(méi)被觸發(fā)或提取規(guī)則沒(méi)匹配上。這時(shí)打開 Burp 的 Logs - Session Handling查看宏執(zhí)行記錄。注意宏的觸發(fā)條件是主請(qǐng)求發(fā)出前不是主請(qǐng)求響應(yīng)后。如果配成響應(yīng)后執(zhí)行Token 會(huì)更新的太晚——下一次請(qǐng)求已經(jīng)用舊 Token 發(fā)出去了。這條規(guī)則我踩過(guò)坑配錯(cuò)之后爆破測(cè)試一直沒(méi)有結(jié)果看日志才發(fā)現(xiàn)執(zhí)行順序搞反了。5.2 并發(fā)與頻率控制策略宏爆破時(shí)并發(fā)控制直接決定成敗。線程數(shù)設(shè)置太保守10000 個(gè)組合要跑幾個(gè)小時(shí)太激進(jìn)可能觸發(fā)服務(wù)端的請(qǐng)求頻率限制或者目標(biāo)系統(tǒng)直接拒絕服務(wù)。先做一輪簡(jiǎn)單的延遲測(cè)試。用 Repeater 手動(dòng)發(fā) 10 次驗(yàn)證碼提交請(qǐng)求記錄每次的響應(yīng)時(shí)間。模擬項(xiàng)目 X 的靶場(chǎng)單次驗(yàn)證碼校驗(yàn)響應(yīng)在 30-50ms發(fā)送驗(yàn)證碼的宏請(qǐng)求在 80-120ms所以單線程單次宏請(qǐng)求的完整耗時(shí)任在 130ms 左右。理論上 20 個(gè)線程跑完 10000 個(gè)組合只需 5-6 秒但實(shí)際不能這么暴力——因?yàn)楹旰椭髡?qǐng)求是串行的同一線程的宏執(zhí)行不會(huì)中斷但多個(gè)線程同時(shí)觸發(fā)宏等于同時(shí)請(qǐng)求驗(yàn)證碼發(fā)送接口目標(biāo)系統(tǒng)的郵件系統(tǒng)可能扛不住。我的實(shí)測(cè)配置10 線程每線程執(zhí)行完宏主請(qǐng)求后加 100ms 隨機(jī)延遲。這樣整體速度仍很快同時(shí)避免宏請(qǐng)求突發(fā)頻率過(guò)高。跑下來(lái)的耗時(shí)約 18 分鐘比單線程快了 10 倍而且沒(méi)有觸發(fā)任何頻率限制。再補(bǔ)充一個(gè)判斷頻率是否過(guò)高的方法觀察 Intruder 的Errors列。如果宏請(qǐng)求失敗Errors 會(huì)持續(xù)累加。同時(shí)觀察目標(biāo)系統(tǒng)返回的響應(yīng)狀態(tài)碼分布——如果出現(xiàn)大量 429、503說(shuō)明需要降低線程數(shù)和加大延遲。推薦參數(shù)組合 - 線程數(shù)5-15視目標(biāo)響應(yīng)速度和頻率限制而定 - 延遲設(shè)置100-300ms 隨機(jī)延遲比固定延遲更難被識(shí)別 - 失敗重試宏失敗則重試 2 次主請(qǐng)求不重試 - 請(qǐng)求超時(shí)10-15 秒防止慢響應(yīng)拖死線程5.3 宏的調(diào)試與日志排查宏配置完成后必須先做一輪小規(guī)模驗(yàn)證。我習(xí)慣的做法是先用 Intruder 限制 payload 范圍為 0000-0009只跑 10 個(gè)請(qǐng)求全部跑完后逐一檢查響應(yīng)。如果 10 個(gè)請(qǐng)求的響應(yīng)體長(zhǎng)度完全一致說(shuō)明宏沒(méi)有生效——Token 沒(méi)被刷新或者刷新后沒(méi)替換進(jìn)去。排查步驟按優(yōu)先級(jí)排列第一步看 Session Handling Rule 的 Scope 是否正確匹配到目標(biāo)接口。第二步檢查宏執(zhí)行日志Burp 的 Dashboard - Event Log 里能看到每條請(qǐng)求的宏執(zhí)行記錄如果提示 macro failed 就是宏請(qǐng)求本身出錯(cuò)。第三步檢查提取規(guī)則把宏在Options - Sessions - Macros里選中點(diǎn)Test按鈕看它的實(shí)際請(qǐng)求和提取結(jié)果這一步能直接看到提取出來(lái)的值長(zhǎng)什么樣。還有一個(gè)高頻坑宏里的請(qǐng)求用的 Cookie 是過(guò)期的。創(chuàng)建宏時(shí)抓的請(qǐng)求帶的是當(dāng)時(shí)的 Cookie但宏實(shí)際執(zhí)行時(shí)用的是當(dāng)前會(huì)話的 Cookie如果沒(méi)配置更新宏請(qǐng)求的 Cookie宏請(qǐng)求可能在未登錄狀態(tài)下執(zhí)行得不到有效的驗(yàn)證碼發(fā)送結(jié)果。這種情況需要在宏配置里開啟Update Cookie from current context讓宏自動(dòng)繼承當(dāng)前會(huì)話的認(rèn)證狀態(tài)。日志排查的最后一步是抓包對(duì)比。在 Intruder 跑爆破時(shí)同時(shí)用 Wireshark 或者 Burp 的 8080 代理抓流量看每個(gè)主請(qǐng)求發(fā)出前是否有一個(gè)宏請(qǐng)求先發(fā)出。如果在流量里看到宏請(qǐng)求后緊跟著主請(qǐng)求且主請(qǐng)求的 Cookie 值確實(shí)發(fā)生了變化那宏就正常工作了。我在模擬項(xiàng)目 X 的最終配置里就是這么確認(rèn)的。6. 防御視角如何加固身份驗(yàn)證體系6.1 枚舉與爆破的檢測(cè)機(jī)制設(shè)計(jì)攻擊鏈路測(cè)完切換成防御視角聊聊怎么加固。身份驗(yàn)證的防護(hù)不能靠單點(diǎn)要靠縱深防御。我在測(cè)試中把攻擊鏈路每一環(huán)都想了對(duì)應(yīng)的防御方案按優(yōu)先級(jí)排序如下第一優(yōu)先級(jí)是阻斷枚舉側(cè)信道。最有效的手段是統(tǒng)一錯(cuò)誤消息——無(wú)論用戶名是否存在、密碼是否正確返回完全相同的響應(yīng)體和狀態(tài)碼。響應(yīng)延遲也要盡量抹平可以在后端對(duì)不存在的用戶做一次虛擬哈希計(jì)算確保耗時(shí)接近真實(shí)的密碼校驗(yàn)。我在模擬項(xiàng)目 X 中對(duì)比過(guò)加上這層延遲均衡之后響應(yīng)時(shí)間維度的枚舉識(shí)別直接失效。第二優(yōu)先級(jí)是限制爆破頻率。傳統(tǒng)的賬號(hào)鎖定是最基礎(chǔ)的手段但會(huì)引入賬號(hào)被惡意鎖定的風(fēng)險(xiǎn)。更合理的是 IP 維度限速加賬號(hào)維度異常檢測(cè)——單 IP 每分鐘請(qǐng)求超過(guò)閾值則驗(yàn)證碼升級(jí)從普通問(wèn)題升級(jí)到圖形驗(yàn)證碼或行為驗(yàn)證。同時(shí)設(shè)置登錄失敗次數(shù)的動(dòng)態(tài)閾值同一賬號(hào)短時(shí)間連續(xù)失敗達(dá)到 N 次強(qiáng)制進(jìn)入慢速校驗(yàn)?zāi)Ｊ健５谌齼?yōu)先級(jí)是驗(yàn)證碼加固。驗(yàn)證碼位數(shù)至少 6 位數(shù)字或 4 位字母數(shù)字組合并且設(shè)置有效期和校驗(yàn)次數(shù)上限。每次校驗(yàn)失敗都應(yīng)該刷新驗(yàn)證碼避免暴力重放。我測(cè)試的模擬項(xiàng)目 X 進(jìn)階版做了失敗即刷新 Token的方案這直接廢掉了手工 Intruder 爆破只能靠宏來(lái)對(duì)抗防御效果非常明顯。第四優(yōu)先級(jí)是流程狀態(tài)保護(hù)。2FA 驗(yàn)證碼通過(guò)后服務(wù)端必須重新頒發(fā)完整會(huì)話 Token而不是沿用發(fā)送驗(yàn)證碼時(shí)的 Token。同時(shí)對(duì)整個(gè) 2FA 驗(yàn)證流程做狀態(tài)機(jī)管理拒絕跳過(guò)步驟、拒絕重復(fù)提交、拒絕跨會(huì)話復(fù)用。狀態(tài)變化要用服務(wù)端存儲(chǔ)不能只依賴請(qǐng)求參數(shù)。6.2 測(cè)試報(bào)告與修復(fù)清單模板每次做完整測(cè)試后都需要輸出一份專項(xiàng)報(bào)告便于開發(fā)團(tuán)隊(duì)直接照著修。我在模擬項(xiàng)目 X 的測(cè)試結(jié)束后整理了一份修復(fù)清單這里直接給模板風(fēng)險(xiǎn)等級(jí)問(wèn)題描述復(fù)現(xiàn)路徑修復(fù)建議高用戶名枚舉響應(yīng)體差異登錄接口枚舉 500 組用戶名68 字節(jié)響應(yīng)長(zhǎng)度異常聚類統(tǒng)一錯(cuò)誤消息后端消除響應(yīng)差異化高密碼策略跨流程不一致注冊(cè)要求 8 位含字母數(shù)字重置流程接受 12345678統(tǒng)一密碼校驗(yàn)組件全流程復(fù)用嚴(yán)重2FA 驗(yàn)證碼可爆破4 位數(shù)字Intruder 跑 0000-9999 全量組合命中提高驗(yàn)證碼位數(shù)、失敗即刷新、設(shè)置請(qǐng)求頻率上限嚴(yán)重會(huì)話 Token 在校驗(yàn)失敗時(shí)未刷新手工爆破期間舊 Token 持續(xù)有效每次校驗(yàn)失敗后強(qiáng)制刷新 Token中宏可對(duì)抗動(dòng)態(tài) Token 的條件宏自動(dòng)發(fā)送新驗(yàn)證碼號(hào)并替換 Token驗(yàn)證碼發(fā)送接口也要限頻、二次驗(yàn)證、綁定設(shè)備指紋修復(fù)清單的輸出要包含兩個(gè)層面一是風(fēng)險(xiǎn)復(fù)現(xiàn)的條件和過(guò)程讓開發(fā)一眼明白問(wèn)題原理二是修復(fù)的具體方案和驗(yàn)證方式說(shuō)明修復(fù)后應(yīng)該怎么做回歸測(cè)試。比如 2FA 驗(yàn)證碼修復(fù)后重新跑一輪 10000 組枚舉確認(rèn)無(wú)法在限速條件下完成爆破。6.3 安全測(cè)試邊界與合規(guī)提醒測(cè)試方法論說(shuō)完必須強(qiáng)調(diào)最后一條底線。身份驗(yàn)證攻防的測(cè)試方式有一條明確的邊界只能在你自己負(fù)責(zé)的、有書面授權(quán)的系統(tǒng)里做全鏈路測(cè)試。靶場(chǎng)、測(cè)試環(huán)境、模擬項(xiàng)目隨便測(cè)。生產(chǎn)環(huán)境沒(méi)有授權(quán)連用戶名枚舉都不該碰。授權(quán)測(cè)試和無(wú)授權(quán)測(cè)試的界限不只是法律問(wèn)題也是職業(yè)道德問(wèn)題。我見(jiàn)過(guò)有人拿著公司的內(nèi)部系統(tǒng)練手結(jié)果觸發(fā)了安全事件響應(yīng)流程差點(diǎn)被開除。所以每次開測(cè)前先確認(rèn)這個(gè)系統(tǒng)有授權(quán)嗎授權(quán)范圍涵蓋了用戶枚舉嗎涵蓋了密碼爆破嗎涵蓋了 2FA 繞過(guò)嗎如果某個(gè)行為不在授權(quán)范圍內(nèi)主動(dòng)放棄。紅線提醒如果團(tuán)隊(duì)沒(méi)有完善的授權(quán)測(cè)試流程建議先推動(dòng)建立規(guī)范的滲透測(cè)試授權(quán)書明確測(cè)試時(shí)間、測(cè)試范圍、測(cè)試手段和應(yīng)急聯(lián)系人。寧可多做文檔流程也不要因?yàn)樯賹懸恍惺跈?quán)而把安可活動(dòng)變成安全事故。7. 常見(jiàn)問(wèn)題速查與經(jīng)驗(yàn)總結(jié)7.1 枚舉和爆破階段常見(jiàn)問(wèn)題我在整套測(cè)試流程里收集了一堆問(wèn)題都是從自己和同事的實(shí)際踩坑中總結(jié)出來(lái)的。挑高頻的分享。問(wèn)題一Intruder 跑完所有 payload響應(yīng)體長(zhǎng)度全部一色找不到差異。這種狀況大概率是目標(biāo)系統(tǒng)做了響應(yīng)混淆或者你只用的長(zhǎng)度維度不夠。解決辦法切到時(shí)間維度看看或者抓響應(yīng)體的 Set-Cookie 差異。實(shí)在不行把響應(yīng)體內(nèi)容做一次 MD5 哈希分組哈希值不同的分組可能藏著答案。問(wèn)題二爆破過(guò)程中連續(xù)收到 302 重定向。302 說(shuō)明請(qǐng)求被跳轉(zhuǎn)到了另一個(gè)頁(yè)面通常是登錄成功后跳到主頁(yè)或者被安全機(jī)制踢到了驗(yàn)證頁(yè)。需要看 Location 頭的目標(biāo)路徑根據(jù)路徑區(qū)分成功和失敗兩類 302。問(wèn)題三枚舉到的用戶名會(huì)觸發(fā)驗(yàn)證碼驗(yàn)證。部分系統(tǒng)在多次失敗后會(huì)升級(jí)到驗(yàn)證碼校驗(yàn)這會(huì)干擾響應(yīng)一致性的判斷。處理方式讓 Intruder 每 5 個(gè)請(qǐng)求后暫停 2 秒降低觸發(fā)概率或者在條件允許時(shí)測(cè)一次就撤不追求全量覆蓋。問(wèn)題四Macro 里的驗(yàn)證碼發(fā)送請(qǐng)求失敗。大概率是 Cookie 過(guò)期或者 CSRF Token 不匹配。檢查宏配置里的更新 Cookie選項(xiàng)同時(shí)確認(rèn)宏請(qǐng)求的頻率不超過(guò)目標(biāo)系統(tǒng)的限速閾值。問(wèn)題五2FA 爆破過(guò)程中郵件塞爆了受害者的郵箱。宏每執(zhí)行一次就觸發(fā)一封新驗(yàn)證碼郵件跑 10000 次就是 10000 封郵件。靶場(chǎng)環(huán)境沒(méi)影響但生產(chǎn)環(huán)境絕對(duì)不允許這么做。測(cè)試 2FA 爆破前先確認(rèn)目標(biāo)環(huán)境對(duì)測(cè)試郵件的容忍度必要情況下讓開發(fā)提供繞過(guò)郵件發(fā)送的測(cè)試接口。7.2 完整測(cè)試流程復(fù)盤最后復(fù)盤一下這次模擬項(xiàng)目 X 身份驗(yàn)證攻防的完整鏈路。整個(gè)測(cè)試可以拆成六個(gè)階段每個(gè)階段都要留下一份結(jié)果記錄方便回溯和復(fù)現(xiàn)。第一階段信息收集。抓主域、抓登錄接口、抓可能的注冊(cè)和重置入口梳理出認(rèn)證鏈路的所有 HTTP 端點(diǎn)。重點(diǎn)是標(biāo)記出各接口之間的狀態(tài)參數(shù)傳遞關(guān)系比如登錄 Token 怎么傳到驗(yàn)證碼接口。第二階段枚舉探測(cè)。用響應(yīng)長(zhǎng)度、時(shí)間、關(guān)鍵詞三個(gè)維度做用戶名枚舉交叉驗(yàn)證后鎖定有效賬號(hào)。產(chǎn)出物是一份有效用戶名清單。第三階段密碼策略分析。注冊(cè)、重置、修改密碼三個(gè)入口全部做策略探測(cè)找出跨流程校驗(yàn)不一致的問(wèn)題。產(chǎn)出物是密碼規(guī)則差異清單。第四階段密碼測(cè)試?；诓呗远ㄖ谱值渥龆ㄏ蛎艽a噴灑。確保在賬號(hào)鎖定的閾值內(nèi)完成測(cè)試。產(chǎn)出物是有效憑據(jù)清單。第五階段2FA 校驗(yàn)與分析。用有效憑據(jù)登錄分析 2FA 的 Token 生成邏輯、校驗(yàn)邏輯和會(huì)話變化。手工嘗試跳過(guò)和重放判斷是否有邏輯漏洞。產(chǎn)出物是2FA 缺陷分析報(bào)告。第六階段宏自動(dòng)化爆破。配置 Session Handling Rule 和 Macro應(yīng)對(duì)動(dòng)態(tài)刷新 Token 的防護(hù)完成全量驗(yàn)證碼爆破。產(chǎn)出物是驗(yàn)證碼爆破復(fù)現(xiàn)記錄。每一階段我都在虛擬環(huán)境里完整跑完并且保留了 Burp 的項(xiàng)目文件和導(dǎo)出報(bào)告。安全測(cè)試最重要的不只是結(jié)果是可復(fù)現(xiàn)性。別人拿到你的報(bào)告照著操作步驟能重新跑出一遍相同的結(jié)果這才算一份合格的測(cè)試成果。最后再說(shuō)一句身份驗(yàn)證的攻防對(duì)抗是不斷抬升攻擊成本的過(guò)程。防御方每多一層校驗(yàn)攻擊者就要多走一段鏈路、多費(fèi)一份工夫。測(cè)試者的價(jià)值不在于把某一次攻擊打到成功而在于用系統(tǒng)的角度幫防御方看到薄弱點(diǎn)在哪然后封住它。搞明白攻擊怎么打順手也就明白了防守怎么守。這本來(lái)就是同一枚硬幣的兩面。