最近在一个大型SRC项目里我遇到一个巨无霸级的目标——单页面应用Webpack打包JS文件超过20MB混淆压缩到完全不可读。传统的手工翻源码根本行不通我干脆写了个脚本用AI把整个JS Bundle拆开自动提取出所有API端点、请求参数、认证方式一次性输出了800多个后端接口。靠这份接口清单我半小时内就发现了三个未授权API其中一个直接返回了全量用户数据。今天把这套AI自动分析JS的方法完整公开用什么工具拆包、怎么让AI准确提取API、如何批量验证。再也不用熬夜翻源码了。一、为什么手工翻JS越来越不现实现代前端应用有几个趋势让传统信息收集方式彻底失效打包体积爆炸Webpack、Vite等工具把所有JS、CSS、甚至图片都打包进几个巨大的bundle文件动辄十几MB。代码混淆与压缩变量名被替换为单字母函数名完全不可读字符串被编码所有换行和空格被移除。动态导入与代码拆分很多API调用藏在懒加载的chunk里不在主bundle中更难被完整覆盖。接口定义方式多样化Axios、Fetch、GraphQL、gRPC-Web等混用参数构造逻辑分散在各处。即使你用LinkFinder或JSFinder这类正则工具它们只能匹配简单的URL模式面对复杂的封装调用如request.post(/api/user, data)往往漏掉一大片更无法提取参数和认证信息。手工翻JS的时代已经结束了。AI是唯一能理解复杂代码语义的工具。二、AI分析JS Bundle的完整工作流我的方法分三步拆包提取原始JS → AI分析提取API清单 → 自动验证和分类。第一步拆包提取JS文件对于Webpack打包的应用直接用Chrome DevTools的Sources面板可以看到原始的模块文件但手动导出太慢。我用一个Python脚本自动化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等工具还原模块结构但这一步不是必须的。直接把原始bundle扔给AI它也能处理。第二步用AI提取API端点这是核心步骤。我用的Prompt经过了多次优化最终版本如下你是一个资深安全审计专家。请分析以下JavaScript代码提取所有后端API调用的信息。对于每个API请提供 1. HTTP方法GET/POST/PUT/DELETE等 2. 完整的URL路径如果是相对路径请结合上下文还原绝对路径 3. 请求参数query string或request body中的字段名和类型 4. 认证方式是否在请求头中携带Cookie、Authorization、Token等 5. 该API可能的业务功能描述 6. 在代码中的调用位置文件名和大致行号 要求 - 不要遗漏任何API调用包括那些隐藏在被封装函数里的调用。 - 对于动态拼接的URL尝试推理出完整的模式。 - 以JSON格式输出结果。 - 如果没有发现API返回空JSON。 代码片段 {code_chunk}我把每个JS文件切分成8K大小的chunk避免超过token限制然后用DeepSeek API逐一分析。关键技巧把常见的请求库Axios、Fetch、request等的封装函数定义一并提供给AI帮助它理解调用链。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第三步批量验证拿到API清单后还需要验证哪些接口可以被未授权访问。我写了个Burp插件自动把AI提取的端点导入Intruder用不同的认证token空、低权限、高权限分别测试对比响应码和内容。重点标记出返回200且包含敏感数据的接口。实际测试中这套流程处理一个20MB的JS bundle大约需要20分钟成本大约0.5美元。它比手工翻代码快几十倍而且准确率极高——我手工验证了AI提取的前100个接口只有3个是误报把前端路由误判为API漏报只有1个。三、实战案例从一个JS Bundle到三个高危漏洞以最近测试的一个SaaS平台为例。信息收集该平台使用Next.js主JS bundle大小18MB。我用上述脚本下载了所有JS文件共12个。AI分析AI从这些文件里提取出了812个API端点涵盖了用户、订单、支付、管理后台等所有模块。部分结果示例{ method: GET, path: /api/v2/users/{id}/profile, params: [id], auth: Bearer token, description: 获取用户个人资料 }发现漏洞在清单中我注意到三个接口/api/internal/export_users—— 没有出现在前端路由中显然是隐藏的内部接口。/api/v1/admin/orders—— 参数userId可传入任意值且无权限校验。/api/v3/upload—— 上传文件接口接受Content-Type: multipart/form-data但后端不校验文件类型。验证结果接口1直接返回全量用户数据18万条无需认证。接口2可以通过遍历userId获取所有用户的订单详情包括收货地址。接口3可上传任意WebShell拿到服务器权限。三个漏洞打包提交总赏金超过2万。如果没有AI自动提取这些接口可能永远藏在那20MB的乱码里。四、工具与技巧如何让AI更准确使用更强的模型我测试了Claude Sonnet 4.5、DeepSeek-Chat和GPT-5.5其中GPT-5.5对混淆代码的理解最好。本地模型如CodeLlama 34B也能用但准确率略低。为常见框架定制Prompt如果你的目标大量使用Axios可以在Prompt里加入Axios的用法示例告诉AI如何解析.get()、.post()的参数。处理动态URL对于/api/${env}/users这样的动态拼接AI通常会输出模式/api/{env}/users。可以进一步搜索代码中的env变量定义还原可能的值。结合Source Map如果目标应用提供了Source Map文件.js.map先用工具还原源码再让AI分析效果更好。增量分析与去重一个API可能在多个chunk中出现需要根据URLMethod去重合并参数信息。五、防御建议不要信任客户端隐藏对于开发者不要在JS中保留任何内部API的路径。后端接口设计应遵循“除非公开否则不可见”的原则。对管理类API加严格的认证和授权不依赖“没人知道这个URL”来保证安全。定期审查前端代码检查是否泄露了敏感接口。可用类似的AI工具自动扫描。对于安全测试者将AI辅助JS分析纳入常规渗透流程尤其是面对大型SPA应用时。提取后的API清单可以导入到YAML文件中作为后续自动化扫描的种子。注意API参数的组合逻辑——许多漏洞出现在参数组合而非单一接口。六、写在最后AI没有魔法但它把原先需要几天几夜的枯燥劳动压缩到了几十分钟。渗透测试的核心竞争力正在从“能熬夜翻代码”转变为“能设计出高效的AI工作流”。如果你还在手工从JS里挖接口不妨试试让AI代劳——你会发现原来那些藏得再深的未授权API在AI面前都是透明的。严正声明本文所述技术仅用于合法授权的安全测试所有案例均已脱敏。未经授权分析他人网站的前端代码可能违反相关服务条款请务必在授权范围内进行安全研究。遵守法律守住底线。
