最近在一個(gè)大型SRC項(xiàng)目里我遇到一個(gè)巨無霸級的目標(biāo)——單頁面應(yīng)用Webpack打包JS文件超過20MB混淆壓縮到完全不可讀。傳統(tǒng)的手工翻源碼根本行不通我干脆寫了個(gè)腳本用AI把整個(gè)JS Bundle拆開自動(dòng)提取出所有API端點(diǎn)、請求參數(shù)、認(rèn)證方式一次性輸出了800多個(gè)后端接口。靠這份接口清單我半小時(shí)內(nèi)就發(fā)現(xiàn)了三個(gè)未授權(quán)API其中一個(gè)直接返回了全量用戶數(shù)據(jù)。今天把這套AI自動(dòng)分析JS的方法完整公開用什么工具拆包、怎么讓AI準(zhǔn)確提取API、如何批量驗(yàn)證。再也不用熬夜翻源碼了。一、為什么手工翻JS越來越不現(xiàn)實(shí)現(xiàn)代前端應(yīng)用有幾個(gè)趨勢讓傳統(tǒng)信息收集方式徹底失效打包體積爆炸Webpack、Vite等工具把所有JS、CSS、甚至圖片都打包進(jìn)幾個(gè)巨大的bundle文件動(dòng)輒十幾MB。代碼混淆與壓縮變量名被替換為單字母函數(shù)名完全不可讀字符串被編碼所有換行和空格被移除。動(dòng)態(tài)導(dǎo)入與代碼拆分很多API調(diào)用藏在懶加載的chunk里不在主bundle中更難被完整覆蓋。接口定義方式多樣化Axios、Fetch、GraphQL、gRPC-Web等混用參數(shù)構(gòu)造邏輯分散在各處。即使你用LinkFinder或JSFinder這類正則工具它們只能匹配簡單的URL模式面對復(fù)雜的封裝調(diào)用如request.post(/api/user, data)往往漏掉一大片更無法提取參數(shù)和認(rèn)證信息。手工翻JS的時(shí)代已經(jīng)結(jié)束了。AI是唯一能理解復(fù)雜代碼語義的工具。二、AI分析JS Bundle的完整工作流我的方法分三步拆包提取原始JS → AI分析提取API清單 → 自動(dòng)驗(yàn)證和分類。第一步拆包提取JS文件對于Webpack打包的應(yīng)用直接用Chrome DevTools的Sources面板可以看到原始的模塊文件但手動(dòng)導(dǎo)出太慢。我用一個(gè)Python腳本自動(dòng)化import os, re, requests from bs4 import BeautifulSoup def download_js_files(base_url): # 獲取頁面HTML提取所有JS鏈接 html requests.get(base_url).text soup BeautifulSoup(html, html.parser) js_links [script[src] for script in soup.find_all(script) if script.get(src)] # 下載所有JS文件 for link in js_links: if link.startswith(//): link https: link elif link.startswith(/): link base_url link content requests.get(link).text filename link.split(/)[-1].split(?)[0] with open(fjs_files/{filename}, w, encodingutf-8) as f: f.write(content)對于打包后的bundle需要先用source-map-explorer或unwebpack等工具還原模塊結(jié)構(gòu)但這一步不是必須的。直接把原始bundle扔給AI它也能處理。第二步用AI提取API端點(diǎn)這是核心步驟。我用的Prompt經(jīng)過了多次優(yōu)化最終版本如下你是一個(gè)資深安全審計(jì)專家。請分析以下JavaScript代碼提取所有后端API調(diào)用的信息。對于每個(gè)API請?zhí)峁?1. HTTP方法GET/POST/PUT/DELETE等 2. 完整的URL路徑如果是相對路徑請結(jié)合上下文還原絕對路徑 3. 請求參數(shù)query string或request body中的字段名和類型 4. 認(rèn)證方式是否在請求頭中攜帶Cookie、Authorization、Token等 5. 該API可能的業(yè)務(wù)功能描述 6. 在代碼中的調(diào)用位置文件名和大致行號 要求 - 不要遺漏任何API調(diào)用包括那些隱藏在被封裝函數(shù)里的調(diào)用。 - 對于動(dòng)態(tài)拼接的URL嘗試推理出完整的模式。 - 以JSON格式輸出結(jié)果。 - 如果沒有發(fā)現(xiàn)API返回空J(rèn)SON。 代碼片段 {code_chunk}我把每個(gè)JS文件切分成8K大小的chunk避免超過token限制然后用DeepSeek API逐一分析。關(guān)鍵技巧把常見的請求庫Axios、Fetch、request等的封裝函數(shù)定義一并提供給AI幫助它理解調(diào)用鏈。import openai, json, os def analyze_js(file_path): with open(file_path, r, encodingutf-8) as f: code f.read() # 分塊 chunk_size 8000 chunks [code[i:ichunk_size] for i in range(0, len(code), chunk_size)] all_apis [] for chunk in chunks: response openai.ChatCompletion.create( modelgpt-5.5, messages[{role: user, content: prompt.format(code_chunkchunk)}], temperature0.1, response_format{type: json_object} ) apis json.loads(response.choices[0].message.content) all_apis.extend(apis) return all_apis第三步批量驗(yàn)證拿到API清單后還需要驗(yàn)證哪些接口可以被未授權(quán)訪問。我寫了個(gè)Burp插件自動(dòng)把AI提取的端點(diǎn)導(dǎo)入Intruder用不同的認(rèn)證token空、低權(quán)限、高權(quán)限分別測試對比響應(yīng)碼和內(nèi)容。重點(diǎn)標(biāo)記出返回200且包含敏感數(shù)據(jù)的接口。實(shí)際測試中這套流程處理一個(gè)20MB的JS bundle大約需要20分鐘成本大約0.5美元。它比手工翻代碼快幾十倍而且準(zhǔn)確率極高——我手工驗(yàn)證了AI提取的前100個(gè)接口只有3個(gè)是誤報(bào)把前端路由誤判為API漏報(bào)只有1個(gè)。三、實(shí)戰(zhàn)案例從一個(gè)JS Bundle到三個(gè)高危漏洞以最近測試的一個(gè)SaaS平臺(tái)為例。信息收集該平臺(tái)使用Next.js主JS bundle大小18MB。我用上述腳本下載了所有JS文件共12個(gè)。AI分析AI從這些文件里提取出了812個(gè)API端點(diǎn)涵蓋了用戶、訂單、支付、管理后臺(tái)等所有模塊。部分結(jié)果示例{ method: GET, path: /api/v2/users/{id}/profile, params: [id], auth: Bearer token, description: 獲取用戶個(gè)人資料 }發(fā)現(xiàn)漏洞在清單中我注意到三個(gè)接口/api/internal/export_users—— 沒有出現(xiàn)在前端路由中顯然是隱藏的內(nèi)部接口。/api/v1/admin/orders—— 參數(shù)userId可傳入任意值且無權(quán)限校驗(yàn)。/api/v3/upload—— 上傳文件接口接受Content-Type: multipart/form-data但后端不校驗(yàn)文件類型。驗(yàn)證結(jié)果接口1直接返回全量用戶數(shù)據(jù)18萬條無需認(rèn)證。接口2可以通過遍歷userId獲取所有用戶的訂單詳情包括收貨地址。接口3可上傳任意WebShell拿到服務(wù)器權(quán)限。三個(gè)漏洞打包提交總賞金超過2萬。如果沒有AI自動(dòng)提取這些接口可能永遠(yuǎn)藏在那20MB的亂碼里。四、工具與技巧如何讓AI更準(zhǔn)確使用更強(qiáng)的模型我測試了Claude Sonnet 4.5、DeepSeek-Chat和GPT-5.5其中GPT-5.5對混淆代碼的理解最好。本地模型如CodeLlama 34B也能用但準(zhǔn)確率略低。為常見框架定制Prompt如果你的目標(biāo)大量使用Axios可以在Prompt里加入Axios的用法示例告訴AI如何解析.get()、.post()的參數(shù)。處理動(dòng)態(tài)URL對于/api/${env}/users這樣的動(dòng)態(tài)拼接AI通常會(huì)輸出模式/api/{env}/users。可以進(jìn)一步搜索代碼中的env變量定義還原可能的值。結(jié)合Source Map如果目標(biāo)應(yīng)用提供了Source Map文件.js.map先用工具還原源碼再讓AI分析效果更好。增量分析與去重一個(gè)API可能在多個(gè)chunk中出現(xiàn)需要根據(jù)URLMethod去重合并參數(shù)信息。五、防御建議不要信任客戶端隱藏對于開發(fā)者不要在JS中保留任何內(nèi)部API的路徑。后端接口設(shè)計(jì)應(yīng)遵循“除非公開否則不可見”的原則。對管理類API加嚴(yán)格的認(rèn)證和授權(quán)不依賴“沒人知道這個(gè)URL”來保證安全。定期審查前端代碼檢查是否泄露了敏感接口。可用類似的AI工具自動(dòng)掃描。對于安全測試者將AI輔助JS分析納入常規(guī)滲透流程尤其是面對大型SPA應(yīng)用時(shí)。提取后的API清單可以導(dǎo)入到Y(jié)AML文件中作為后續(xù)自動(dòng)化掃描的種子。注意API參數(shù)的組合邏輯——許多漏洞出現(xiàn)在參數(shù)組合而非單一接口。六、寫在最后AI沒有魔法但它把原先需要幾天幾夜的枯燥勞動(dòng)壓縮到了幾十分鐘。滲透測試的核心競爭力正在從“能熬夜翻代碼”轉(zhuǎn)變?yōu)椤澳茉O(shè)計(jì)出高效的AI工作流”。如果你還在手工從JS里挖接口不妨試試讓AI代勞——你會(huì)發(fā)現(xiàn)原來那些藏得再深的未授權(quán)API在AI面前都是透明的。嚴(yán)正聲明本文所述技術(shù)僅用于合法授權(quán)的安全測試所有案例均已脫敏。未經(jīng)授權(quán)分析他人網(wǎng)站的前端代碼可能違反相關(guān)服務(wù)條款請務(wù)必在授權(quán)范圍內(nèi)進(jìn)行安全研究。遵守法律守住底線。