1. 项目概述为什么JS信息打点是安全测试的“富矿”干了这么多年渗透测试和安全评估我越来越觉得前端代码尤其是JavaScript简直就是一个被很多人忽略的“信息金矿”。很多人一提到信息收集脑子里蹦出来的就是端口扫描、目录爆破、子域名枚举这些“传统手艺”。当然这些很重要但如果你只做到这一步那可能连目标系统的“前厅”都没逛完更别说发现那些藏在“书房”和“保险柜”里的关键信息了。“JS信息打点”这个说法听起来有点专业其实说白了就是系统性地去分析目标网站或Web应用前端加载的所有JavaScript文件从中挖掘对后续渗透测试有价值的信息。这些信息五花八门可能是硬编码在JS里的API密钥、后端接口地址、内部功能路径、甚至是调试接口和敏感的逻辑注释。我遇到过不少案例一个看似固若金汤的系统就因为一个前端JS文件泄露了内部API的路径和参数格式直接被长驱直入。所以今天我想结合自己踩过的坑和总结的经验跟你详细聊聊怎么系统化、高效地进行JS信息打点。这不仅仅是跑个工具那么简单它考验的是你对前端代码的理解、对信息的敏感度以及将零散线索拼凑成攻击路径的能力。无论你是刚入门的安全爱好者还是想拓宽攻击面的职业渗透测试人员这套方法都能让你眼前一亮。2. JS信息打点的核心价值与目标解析在开始动手之前我们必须先搞清楚我们到底要从这些JS文件里找什么漫无目的地翻代码效率极低。我的经验是带着明确的目标去狩猎成功率会高得多。2.1 核心目标一发现隐藏的API接口与端点这是JS信息打点最直接、也最常见的收获。现代Web应用特别是前后端分离的单页应用SPA前端JavaScript里充斥着对后端API的调用。这些接口地址往往不会在robots.txt或sitemap.xml中暴露但却明明白白地写在JS文件的fetch、axios、$.ajax请求里。接口路径你会找到像/api/v1/admin/users、/internal/config、/graphql这样的路径。有些甚至是开发环境、测试环境专用的接口其安全防护可能比生产环境弱得多。参数结构JS代码会告诉你调用某个API需要传哪些参数参数名是什么是什么格式JSON、FormData。知道了这些你就能构造出合法的请求去测试。请求方法是GET、POST还是PUT、DELETE这直接关系到你测试时选择的攻击向量。实操心得不要只盯着明显的/api路径。有些接口可能伪装成静态资源路径比如/static/data.json或者通过WebSocket连接ws://或wss://。在搜索时要结合正则表达式灵活匹配。2.2 核心目标二挖掘硬编码的敏感凭证与配置这是最“低级”但也最致命的错误偏偏在现实中屡见不鲜。开发图省事把一些本该放在后端或环境变量里的信息直接写死在了前端JS里。API Keys / Tokens像第三方地图服务、短信服务、云存储服务的API密钥。我曾经在一个网站的JS里找到了完整的阿里云OSS的AccessKeyId和AccessKeySecret这意味着我可以直接操作对方的存储桶。后端数据库/服务地址内网IP、数据库连接字符串虽然少见但真有、Redis地址等。加密密钥或盐值用于前端数据加密、哈希运算的密钥。如果找到这个或许就能解密一些传输中的数据或者伪造签名。调试标志或功能开关比如debug: trueenableAdminPanel: false。将其改为true可能会开启隐藏的管理功能或输出详细的错误信息。2.3 核心目标三理解应用逻辑与攻击面通过阅读JS代码你可以反向推导出应用的功能模块、业务逻辑和潜在的攻击面。功能点映射JS中会有大量的路由定义如果你用的是Vue Router或React Router、事件监听函数、按钮点击处理函数。分析这些你能画出一个比爬虫更精准的网站功能结构图。输入点识别哪些函数处理用户输入是直接拼接进HTML可能导致XSS还是发送到后端输入校验的逻辑是怎样的是前端简单校验还是前后端都校验找到这些地方就是找到了测试的入口。权限控制逻辑前端如何判断用户是普通用户还是管理员是不是仅仅靠一个叫isAdmin的变量这个变量是如何被设置和校验的能否被篡改很多越权漏洞的根源就在前端逻辑的不严谨。2.4 核心目标四寻找源代码映射与未压缩代码在开发过程中开发者通常会使用Webpack等工具打包压缩代码但同时可能会生成一个.map文件Source Map。这个文件包含了压缩代码到原始源代码的映射关系。如果这个.map文件被错误地部署到了生产环境那么攻击者就可以利用它还原出几乎完整的、可读性极高的原始源代码包括变量名、函数名和注释这无疑是一场灾难。查找.map文件在JS文件同目录下或通过JS文件末尾的//# sourceMappingURL注释来定位。分析未压缩/开发版JS有些网站在某些环境下比如通过特定子域名、或带特定参数会加载未压缩的、带注释的JS文件。这种文件的信息密度是压缩版的十倍以上。3. 高效JS信息收集与提取方法论知道了找什么下一步就是“去哪儿找”和“怎么找”。这个过程可以大致分为两个阶段首先是尽可能全地收集目标域名的所有JS文件然后才是从这些文件中提取信息。3.1 阶段一全面收集JS文件资源你不能只分析首页加载的那几个JS很多关键信息藏在那些按需加载、异步加载的脚本里。3.1.1 浏览器开发者工具手动收集这是最基本也是理解原理最好的方式。打开目标网站按F12打开开发者工具。切换到Network网络面板。刷新页面并在筛选器中选择JS。你会看到页面加载过程中请求的所有JavaScript文件。你可以一个一个点开查看或者右键选择“Save all as HAR with content”将整个会话保存下来里面包含了所有请求和响应内容。3.1.2 使用爬虫工具自动化收集手动收集对于大型站点不现实必须借助自动化工具。Katana一个速度极快的爬虫可以深度爬取并指定只爬取JS链接。命令示例katana -u https://target.com -js-crawl -depth 3 -o js_urls.txt。它会输出所有发现的JS文件URL。Gau / Waybackurls这些工具不是实时爬虫而是从历史档案如Wayback Machine、Common Crawl等来源获取目标域名曾经出现过的所有URL。这对于发现那些已被删除但档案中仍有记录的JS文件特别有用。echo target.com | gau | grep -iE \.js$。爬虫框架配合使用gospider、hakrawler等爬虫先获取大量URL再用grep过滤出JS文件。3.1.3 从页面源代码中提取有些JS文件的链接并不直接通过网络请求加载而是动态生成的。你需要分析HTML源码。在页面源代码中搜索script src标签。注意那些带有integrity和crossorigin属性的CDN资源虽然它们通常都是公共库但也要记录。不要忽略内联JS写在script标签里的代码这里面也可能包含关键信息。注意事项收集阶段要力求全面。除了主域名别忘了相关的子域名、关联的第三方域名如cdn.target.com,static.target.com。一个子域名下的JS可能会引用或泄露主域名的接口信息。3.2 阶段二静态分析与信息提取收集到一堆JS文件URL后接下来就是下载并分析它们的内容。这里我们主要使用静态分析即不运行代码而是通过文本搜索、正则匹配、AST抽象语法树分析等方式来提取信息。3.2.1 基础关键字搜索正则表达式为王这是最快速、最直接的方法。你可以写一个脚本或者用grep命令配合强大的正则表达式批量处理下载的JS文件。下面是一个实用的命令集合可以保存为一个脚本#!/bin/bash # 假设所有JS文件都下载到了 ./js_files/ 目录下 SEARCH_DIR./js_files echo 搜索API端点 grep -r -E (https?:\\/\\/|\\/)(api|v1|v2|graphql|rest|ajax|fetch|axios|endpoint|controller)\\/[a-zA-Z0-9_\\/\\-\\?\\.]* $SEARCH_DIR --include*.js | head -20 echo -e \\n 搜索硬编码密钥简易版 grep -r -i -E (api[_-]?key|auth[_-]?token|secret|password|credential|access[_-]?key|secret[_-]?key)[\\\][a-zA-Z0-9_\\-]{10,}[\\\] $SEARCH_DIR --include*.js | head -20 echo -e \\n 搜索URL和路径 grep -r -E [\\\](https?:\\/\\/|\\/)[^\\\]*[\\\] $SEARCH_DIR --include*.js | grep -v http[s]?:\\/\\/cdn\\.|http[s]?:\\/\\/ajax\\.googleapis | head -30 echo -e \\n 搜索邮箱和手机号国内 grep -r -E [a-zA-Z0-9._%-][a-zA-Z0-9.-]\\.[a-zA-Z]{2,6} $SEARCH_DIR --include*.js grep -r -E 1[3-9][0-9]{9} $SEARCH_DIR --include*.js echo -e \\n 搜索可能的内网IP grep -r -E (10\\.|172\\.(1[6-9]|2[0-9]|3[0-1])|192\\.168)\\.[0-9]{1,3}\\.[0-9]{1,3} $SEARCH_DIR --include*.js3.2.2 使用专用工具进行深度分析手动写正则很灵活但不够系统。有一些优秀的开源工具专门为此而生LinkFinderPython工具专门用于在JS文件中查找端点endpoints。它比简单的正则更智能能处理字符串拼接等情况。python3 linkfinder.py -i https://target.com/script.js -o cli。JSFinder另一个功能类似的工具支持从JS中提取URL、子域名等。SecretFinder专注于查找JS中的敏感信息如API密钥、令牌等它集成了多种正则模式并会验证一些常见密钥的格式。TruffleHog / Gitleaks虽然这两个工具主要用于扫描Git仓库但其检测敏感信息的引擎非常强大。你可以把下载的JS文件当作一个本地目录用它们来扫描效果拔群。3.2.3 人工代码审计关注特定函数和模式工具能解决80%的问题但剩下的20%需要靠你的眼睛和经验。关注fetch/axios/$.ajax调用这是API调用的明显标志。仔细看它的URL参数、请求头Headers、请求体Body。关注window.location/document.cookie操作这里可能涉及跳转逻辑或令牌处理。关注eval()、setTimeout()、setInterval()中动态拼接的字符串这里可能隐藏了经过混淆或加密的代码逻辑。关注注释开发者留下的注释是宝藏。// TODO:、// FIXME:、// HACK:后面往往跟着未完成的功能、临时的解决方案或已知的问题这些都是潜在的突破口。关注配置对象搜索const config 、var settings 这样的代码块里面往往集中了各种配置信息。4. 实战流程从信息收集到漏洞假设光说不练假把式我们用一个模拟的实战流程把上面的方法串起来。假设我们的目标是example.com。4.1 第一步资产发现与JS文件收集子域名枚举使用subfinder、assetfinder等工具获取所有子域名。subfinder -d example.com -o subdomains.txt。爬取所有URL对主域名和发现的子域名进行爬取。cat subdomains.txt | httpx -silent | gospider -s -d 2 -t 20 -o urls_raw.txt。过滤JS文件从爬取结果中提取JS文件链接。cat urls_raw.txt | grep -iE \\.js($|\\?) | sort -u js_urls.txt。历史档案补充使用waybackurls和gau获取历史JS链接。cat subdomains.txt | waybackurls | grep -iE \\.js($|\\?) js_urls.txt。去重与下载对js_urls.txt去重后使用wget或httpx批量下载。cat js_urls.txt | httpx -silent -mc 200 | xargs -I{} wget -q -P ./js_files {}。4.2 第二步批量分析与信息提取使用LinkFinder批量提取端点for js in ./js_files/*.js; do echo 分析文件: $js python3 linkfinder.py -i $js -o cli | grep -v Empty || true done endpoints_raw.txt然后对endpoints_raw.txt进行整理去重分类如/api/,/admin/,/internal/。使用正则进行广度搜索运行我们在3.2.1中编写的那个bash脚本将结果输出到keywords_found.txt。使用SecretFinder查找密钥python3 SecretFinder.py -i ./js_files -o cli | tee secrets.txt4.3 第三步人工分析与深度挖掘工具跑出来的结果是“线索”不是“答案”。你需要像侦探一样去分析这些线索。关联分析查看提取到的端点它们是否属于同一功能模块例如发现了/api/user/profile和/api/admin/list那么/api/admin/下很可能还有其他接口。参数推断从JS代码中找出调用这些端点的函数观察它们传递的参数。比如发现一个函数调用了/api/resetPassword并传递了{email: userEmail}对象。那么你就可以尝试构造请求测试是否存在邮箱枚举漏洞。逻辑梳理如果找到了权限判断的代码比如if (user.role super_admin) { // 显示超级管理面板 showSuperAdminPanel(); }那么你就需要思考这个user.role是从哪里来的是后端返回的令牌JWT解码得到的吗能否伪造还是存在本地存储中可以被直接修改测试假设基于分析形成漏洞假设。例如“目标应用的前端JS泄露了/internal/exportData接口该接口未在前端路由中显示可能缺乏权限校验。” 接下来你就可以直接访问这个接口进行测试。4.4 第四步信息整理与报告将发现的信息有条理地整理出来这不仅是给客户或团队的报告也是你后续深入测试的路线图。信息类型具体内容来源文件潜在风险/下一步动作API端点POST /api/v1/user/registerapp.main.js测试账号批量注册、参数污染API端点GET /internal/healthvendor.chunk.js可能泄露服务器信息直接访问测试API端点GET /admin/api/logs?dateadmin.bundle.js尝试未授权访问测试日期参数注入硬编码密钥awsAccessKey: AKIA...config.js高危验证该Key是否有效及权限内网地址dbHost: 10.10.1.23dev.config.js记录用于后续内网渗透假设调试接口debugMode: trueutils.js尝试修改请求参数或Cookie启用调试注释信息// TODO: 移除测试账号 admin/123456login.js高危直接尝试使用此凭证登录5. 常见问题、难点与高级技巧在实际操作中你肯定会遇到各种问题。这里分享一些我踩过的坑和总结的技巧。5.1 如何处理代码混淆与压缩这是最大的挑战之一。经过Webpack、UglifyJS等工具压缩混淆后的代码变量名变成a、b、c几乎不可读。技巧1利用Source Map这是“后悔药”。首先全力搜索.map文件。如果找到可以使用source-map等库或在线工具将压缩代码还原。技巧2美化代码即使没有Source Map用浏览器的开发者工具Sources面板或本地工具如js-beautify对代码进行格式化也能极大提升可读性。虽然变量名没变但结构清晰了。js-beautify ugly.js -o pretty.js。技巧3关注字符串常量混淆工具通常不会压缩字符串常量。所以API路径、错误信息、固定的URL等依然会以明文存在。你的正则表达式搜索依然有效。技巧4动态调试对于特别复杂的逻辑可以尝试将关键部分的JS代码剥离出来在Node.js环境或浏览器控制台中动态运行、打断点观察输入输出。这需要较高的JS功底。5.2 如何区分有用信息与噪音收集到的信息可能非常多尤其是大型站点。建立过滤规则优先过滤掉常见的第三方库jQuery, React, Vue, Bootstrap等的JS文件。虽然它们也可能被修改但概率较低。可以通过文件路径包含node_modules、vendor、lib或文件内容包含特定版权声明来过滤。优先级排序专属文件优先以目标域名命名的、看起来是自定义打包的JS文件如app.[hash].jsmain.bundle.js价值最高。内容密度优先文件大小适中几十KB到几百KB内容看起来不像最小化库没有大段连续的单字母变量这类文件值得细看。路径关键词优先在提取的端点中优先关注包含admininternalconfigapiv1secret等关键词的路径。5.3 如何验证找到的信息找到线索不等于漏洞。必须验证。端点访问测试对找到的API端点直接使用浏览器、Postman或curl进行访问。测试不同HTTP方法GET, POST, PUT, DELETE。观察返回状态码200, 403, 404, 500和响应内容。密钥有效性验证对于找到的API密钥必须在授权测试范围内并获得明确书面授权后才能尝试在对应的服务平台如AWS CLI, SendGrid Dashboard进行低权限的验证操作确认其是否有效及权限范围。切勿进行任何破坏性操作。逻辑漏洞测试对于前端权限校验逻辑尝试通过修改本地存储LocalStorage、Cookie、或拦截修改API响应包使用Burp Suite或浏览器插件来绕过前端的控制看后端是否还有真正的校验。5.4 高级技巧AST抽象语法树分析入门当正则表达式和字符串搜索遇到瓶颈时AST分析是降维打击。你可以使用像esprima、acorn这样的JavaScript解析器将JS代码转换成一颗结构化的语法树然后编写程序遍历这棵树精准地找到函数调用、变量赋值、字符串字面量等节点。例如你可以写一个Node.js脚本专门找出所有调用fetch或axios时传入的URL参数。这种方法能100%准确地找到信息不受代码格式和部分混淆的影响但需要一定的编程能力。对于追求极致和自动化的红队来说这是必备技能。JS信息打点是一个从“粗筛”到“精炼”从“自动化”到“人工研判”的过程。它没有一招制敌的秘籍更多的是耐心、细心和对前端技术的理解。把它作为你信息收集环节的固定动作持之以恒你会发现目标的攻击面远比想象中宽广。每次审计前花上几个小时好好翻翻目标的JavaScript这时间投资回报率往往高得惊人。