文章总结： 本文介绍利用AI技术挖掘前端JS文件中隐藏的敏感信息（如云服务AccessKey、数据库密码等）的方法。作者通过设计特定Prompt让AI理解代码语义，能识别被拆分、编码或隐藏的密钥，并给出Python脚本框架和三个实战案例。文章强调该方法比传统正则表达式更高效准确，同时提醒注意数据泄露风险及防御措施。 综合评分： 85 文章分类： 渗透测试,WEB安全,代码审计,安全工具,实战经验
我用AI把前端JS扫了个遍，挖出37个AccessKey——原来这些密钥一直躺在你眼皮底下
原创
昆仑AI安全实验室 昆仑AI安全实验室
昆仑AI安全实验室
2026年6月17日 14:18 广东
在小说阅读器读本章
去阅读
去年在某大厂SRC，我靠信息泄露漏洞拿了年度Top 10。其中最大的单笔赏金来自一个藏在JS里的OSS密钥——这个密钥权限大到可以读写所有生产环境的Bucket，里面装着几百万用户的身份证和合同照片。发现它的方法，不是手工翻代码，不是正则匹配，而是我让AI帮我读完了二十万个JS文件。
别人用grep搜accessKey，我直接用AI一行一行看，把那些故意拆开、改名字、藏在注释里的密钥全揪了出来。本文完整拆解这套AI辅助JS敏感信息挖掘的方案，从工具到Prompt到脚本到实战案例，全给你。
一、为什么grep找不全？因为开发者比你更会藏
传统挖JS敏感信息，基本就靠正则表达式。搜accessKeyId、secretKey、AKID，匹配到就捞出来。但这套方法漏掉的东西太多了。
我见过最狠的一次隐藏，开发者把密钥拆成了三段放在不同文件里，文件名没有任何规律，代码里也没有任何关键字，只有用AI全局串联上下文才找得到。其他常见绕过姿势包括：
- 变量名故意避开关键词：
const a = 'AKID'，然后用a + 'xxxx'拼接。 - 藏在注释里的“示例代码”：
// TODO: 上线前删除 AKIDxxxxx。 - Base64编码后拆开放：
atob('QUtJRA==') + atob('eHh4eA==')。 - 用数组下标拼：
arr[3] + arr[7]。 - 放在JSON配置文件里，字段名叫
appKey，看起来人畜无害。
正则表达式在这些场景面前基本是盲的。因为它不理解代码的语义，不认识变量引用，不知道拼接结果，更不会跨文件追踪。
二、AI怎么做：把每个JS文件当成一个“人”来审
我用的方案是：先把全站JS文件爬下来，然后逐个喂给AI，让它以“安全审计员”的身份告诉我里面有没有密钥。
核心Prompt设计：
你是一名资深安全审计工程师，正在审查前端JavaScript代码。请分析以下JS代码，提取所有可能包含的敏感信息：- 云服务AccessKey（如阿里云、腾讯云、AWS的AKID形式）- SecretKey或Token- API密钥、私钥、证书- 数据库连接字符串- JWT签名密钥- 内网IP或内部API地址- 其他你认为可能被攻击者利用的信息
要求：1. 即使密钥被拆分、编码、拼接，也尝试还原。2. 给出原始代码片段、还原后的密钥值、风险评估。3. 如果没有发现，直接返回“无发现”。4. 用JSON格式返回，方便程序解析。
代码：{file_content}
这个Prompt的精髓在于：让AI理解变量的生命周期和跨行上下文。它看到var a = 'AKID'和后面的a + 'Sk123'，能自动拼接成AKIDSk123。而正则只看一行，根本不知道这个a是什么。
脚本框架很简单，用Python遍历JS目录，调用大模型API（我用的是DeepSeek和Claude，你也可以换成本地模型），把返回的JSON解析入库：
import os, json, requests
AI_API = "https://api.deepseek.com/v1/chat/completions"HEADERS = {"Authorization": "Bearer sk-xxx"}
def analyze_js(file_path): with open(file_path, 'r', encoding='utf-8', errors='ignore') as f: code = f.read() if len(code) < 100: return None # 跳过太小的文件
prompt = PROMPT_TEMPLATE.format(file_content=code[:8000]) # 截断长文件 resp = requests.post(AI_API, headers=HEADERS, json={ "model": "deepseek-chat", "messages": [{"role": "user", "content": prompt}], "temperature": 0.1 }, timeout=60) return resp.json()["choices"][0]["message"]["content"]
results = {}for root, dirs, files in os.walk("js_files"): for file in files: if file.endswith('.js'): path = os.path.join(root, file) result = analyze_js(path) if result and "无发现" not in result: results[path] = result
实际跑一轮，一个中大型网站几千个JS文件，大概半小时跑完，成本几块钱。比人眼快百倍，比正则准十倍。
三、实战案例：三个被AI揪出来的“隐形”密钥
案例一：某电商平台OSS全权限密钥
AI在一个叫common.chunk.js的文件里发现了一行奇怪的代码：var _0x4f2a=['\x41\x4b\x49\x44']。它识别出这是十六进制编码的AKID，然后追踪变量引用，在文件末尾找到了拼接逻辑，还原出完整的AccessKey。手工翻根本看不出这串十六进制是什么。
这个AK拥有整个公司OSS的管理权限，所有商品图片、用户上传的身份证照片、交易合同全在里面。高危漏洞，赏金6000元。
案例二：某政府网站数据库密码
AI在一个配置文件里发现注释掉的代码：// dbConfig: { host: '10.23.45.67', user: 'admin', password: 'Gov@2023!secure' }。开发者以为注释掉就安全了，但JS文件还是原样发到了客户端。直接连内网MySQL，查出数十万市民个人信息。
案例三：某金融APP的加密密钥
AI从两个不同JS文件里各取了一行代码拼在一起，还原出AES加密密钥和IV。这个密钥用来加密用户登录密码，拿到后可以离线破解所有用户密码。高危，赏金8000元。
四、注意事项：别让AI把你的密钥也泄露了
用第三方API分析JS文件，相当于把你的代码传给了大模型厂商。涉及敏感项目时，有几个选择：
- 用本地部署的开源模型（如CodeLlama、DeepSeek-Coder），数据不出本机。
- 对代码做预处理，把公司名、特殊域名替换成占位符再发给API。
- 只截取包含可疑关键词（如
key、token）的片段发给AI，而不是整个文件。
另外，AI偶尔会“幻觉”，编造不存在的密钥。所有AI返回的结果都必须手工验证，我一般是拿AK去云平台SDK里实际调一次GetCallerIdentity确认有效性。
五、防御：前端不应该有任何密钥
不管AI挖不挖得出来，前端代码里根本不应该出现密钥。所有云服务调用必须走后端中转，前端拿到的只应该是STS临时凭证，或者带有效期的预签名URL。
如果你在自家产品的JS里发现了AccessKey，不管它权限多小，立刻删除并轮换。因为攻击者早晚会用同样的方法找到它。
六、写在最后
传统的JS安全审计靠grep + 肉眼，在2026年已经不够用了。开发者藏密钥的手法越来越花，只有AI的语义理解能力能跟得上。
把AI当成你的代码审计助手，把每个JS文件都当成人来审查。当你看到AI返回的一长串AccessKey列表时，你就会明白：原来这些密钥一直躺在前端代码里，只是没人去认真读。
下次挖SRC时，别只盯着HTML和API。把全站JS爬下来，让AI帮你读一遍。你可能就找到了别人漏掉的那个高危。此技术仅用于合法授权的安全测试，未授权爬取他人网站源码属于违法行为。所有案例均已脱敏，仅保留技术原理供学习参考。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 昆仑AI安全实验室 昆仑AI安全实验室《我用AI把前端JS扫了个遍，挖出37个AccessKey——原来这些密钥一直躺在你眼皮底下》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论