FindSomething：前端敏感信息泄漏实时扫描工具

1. 这不是普通浏览器插件FindSomething 的真实定位与误用风险“FindSomething”这个名字听起来像一个泛泛而谈的搜索工具但结合它在技术社区中反复出现的上下文——尤其是与“信息泄漏检测”“chrome/firefox插件”“代码诊断”高频共现——它实际指向的是一个面向前端开发者与安全审计人员的轻量级客户端侧敏感信息暴露扫描工具。它不提供网页浏览、视频下载或页面美化功能也不具备AI代码补全、翻译或笔记管理能力那些在热搜词里混杂出现的“pycharm ai插件”“zotero翻译插件”“obsidian插件推荐”本质上是用户在搜索引擎中因关键词联想产生的噪声而非FindSomething的真实能力边界。我第一次接触它是在帮一家做政企SaaS系统的客户做上线前合规检查时。他们要求所有前端资源必须通过自动化手段排查是否存在硬编码密钥、调试日志、未脱敏的用户标识如手机号、身份证号片段、内部API路径等敏感内容。当时团队试了三套方案一是用Webpack插件在构建阶段做静态扫描但漏掉了动态拼接的字符串二是用Burp Suite抓包分析响应体但无法覆盖前端JS运行时生成的DOM节点三是人工Review三天没翻完200多个JS文件。直到同事甩来一个GitHub链接——FindSomething说“它能直接在浏览器里跑看到什么就扫什么”。实测下来它确实做到了打开DevTools → 切到Console → 执行一行脚本3秒内就能高亮出当前页面DOM树中所有疑似泄露的文本节点并按置信度分级标注。比如divDEBUG: api-key-xxx123/div会被标为“高危”而spanuser_idU87654321/span则标为“中危”并附带正则匹配路径和上下文快照。这不是靠关键词字面匹配而是基于一套预置的多层语义规则引擎第一层是基础正则如/api[_-]?key/i第二层是上下文语义判断是否出现在script标签内、是否被console.log包裹、是否在># 1. 克隆仓库非ZIP下载 git clone https://github.com/FindSomething/FindSomething.git cd FindSomething # 2. 安装依赖注意必须用npmyarn会因lockfile不兼容报错 npm install # 3. 构建Chrome扩展输出到dist/chrome npm run build:chrome # 4. 构建Firefox扩展输出到dist/firefox npm run build:firefox构建成功后你会看到dist/chrome/目录下有manifest.json、popup.html、content.js、rules.min.js等完整文件dist/firefox/目录结构类似但manifest.json中applications.gecko.id已填入唯一UUID。如果遇到Error: Cannot find module webpack说明npm未全局安装webpack——执行npm install -g webpack5.90.0必须5.x6.x不兼容即可。这是该项目构建链中唯一需要全局安装的依赖。3.3 Chrome浏览器加载绕过“未列在应用商店”的警告Chrome的加载流程分三步缺一不可开启开发者模式地址栏输入chrome://extensions/→ 右上角开关“开发者模式”首次开启会提示“已开启开发者模式”加载已解压的扩展点击“加载已解压的扩展程序”按钮 → 选择dist/chrome/目录不是整个FindSomething根目录处理安全警告此时页面顶部会出现黄色横幅“此扩展程序未列在 Chrome 应用商店中……”。不要点“移除”这是正常现象。点击横幅右侧的“详情” → 滚动到底部 → 勾选“允许访问文件网址”否则无法扫描本地HTML文件→ 关闭该页面。关键细节加载后扩展图标一个放大镜锁形图标会出现在Chrome右上角地址栏右侧。点击它会弹出Popup窗口显示“Ready”状态若图标灰色不可点说明content.js未注入成功。检查dist/chrome/manifest.json中content_scripts.matches是否为[all_urls]默认是并确认run_at为document_idle首次加载后务必刷新一次当前页面如chrome://extensions/否则部分权限可能未生效。3.4 Firefox ESR 115加载ZIP格式扩展的正确用法Firefox ESR对扩展签名要求更宽松但需注意其特殊流程地址栏输入about:debugging#/runtime/this-firefox→ 点击“临时载入附加组件”选择dist/firefox/目录下的manifest.json文件不是整个目录Firefox会自动打包该目录下所有文件加载成功后页面会显示“FindSomething (临时)”及ID下方有“卸载”按钮。这里有个高频误区热搜词里提到“firefox zip格式的扩展怎么用”其实FindSomething并不提供ZIP包。如果你从非官方渠道下载了ZIP解压后得到的是manifest.json一堆JS文件不能直接拖入Firefox。正确做法是将解压后的整个文件夹含manifest.json用系统自带压缩工具Windows右键“发送到→压缩(zipped)文件夹”macOS右键“压缩”生成ZIP再通过about:debugging的“临时载入”选择该ZIP文件。注意Firefox ESR 115默认禁用非签名扩展。若加载失败需在about:config中搜索xpinstall.signatures.required双击将其设为false。这是ESR版本的合法配置项不影响浏览器安全。4. 规则库深度解析如何读懂、修改与定制自己的检测逻辑FindSomething的威力70%来自其规则库rules/default.json。它不是一堆正则的简单堆砌而是一个结构化的威胁模型映射。理解规则语法是你从“使用者”升级为“定制者”的分水岭。4.1 规则结构解剖一个典型规则的逐字段解读以规则API_KEY_EXPOSURE为例已简化{ id: API_KEY_EXPOSURE, pattern: sk_live_[0-9a-zA-Z]{24}, context: { inScriptTag: true, inConsoleLog: false, inDataAttr: true }, severity: high, description: 检测Stripe Live API密钥硬编码, remediation: 将密钥移至服务端前端仅调用代理接口 }id唯一标识符用于日志和过滤pattern核心正则此处匹配Stripe Live密钥格式sk_live_前缀24位Base64字符context上下文约束这才是精度保障的关键。inScriptTag:true表示只在script标签内匹配避免误报HTML注释中的测试密钥inConsoleLog:false表示排除console.log(sk_live_xxx)这类调试残留——因为开发者通常知道这是临时的severity风险等级影响UI高亮颜色high红色medium橙色low黄色description中文描述直接显示在扫描结果中remediation修复建议点击结果项时展开显示。对比另一个规则PHONE_NUMBER_LEAK{ id: PHONE_NUMBER_LEAK, pattern: (1[3-9]\\d{9}|0\\d{2,3}-\\d{7,8}), context: { inInnerText: true, inInputValue: false, minLength: 11 } }这里inInnerText:true确保只扫描可见文本inInputValue:false避免误报表单输入框的placeholder值minLength:11过滤掉短数字串如房间号。这种细粒度控制让FindSomething远超grep式扫描。4.2 自定义规则实战为公司内部系统添加专属检测项假设你所在公司使用自研的X-Auth-Token头认证且前端偶尔会将token写入meta nameauth-token contentxxx。你需要添加一条规则专门捕获这种泄露。步骤如下在rules/custom.json中新建规则官方预留了custom目录{ id: COMPANY_AUTH_TOKEN_LEAK, pattern: X-Auth-Token:\\s*[A-Za-z0-9/]{32,}, context: { inMetaTag: true, attrName: content, tagName: meta }, severity: critical, description: 检测X-Auth-Token在meta标签中的硬编码, remediation: 改用JavaScript动态注入或通过HTTP-only Cookie传递 }修改rules/index.js在export const rules [...defaultRules, ...customRules];中引入新规则重新运行npm run build:chrome构建后规则即生效。关键点在于context.inMetaTag:true和attrName:content——这告诉引擎只检查meta标签的content属性值而非整个HTML源码。实测中这条规则能精准捕获meta nameauth-token contenteyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...而不会误报meta nameviewport contentwidthdevice-width。4.3 规则禁用与过滤如何避免干扰性告警并非所有规则都适用于每个项目。例如DEBUG_CONSOLE_LOG规则会标记所有console.log(debug info)但在开发环境这是合理行为。FindSomething提供了两种过滤方式运行时禁用点击扩展Popup右上角齿轮图标 → “规则设置” → 取消勾选DEBUG_CONSOLE_LOG→ 点击“保存”。此设置保存在浏览器本地存储不影响其他用户。构建时剔除编辑webpack.config.js在plugins中找到new CopyPlugin将其patterns数组中./rules/debug.json的路径注释掉再重新构建。这样生成的扩展包里根本不存在该规则。我建议采用前者。因为后者需要每次构建都手动操作而前者只需一次设置且可随时恢复。更重要的是DEBUG_CONSOLE_LOG在生产环境扫描时仍有价值——它能帮你发现那些忘记删除的console.table()调用这些调用可能暴露完整的用户对象。5. 实战排查链路一次真实信息泄露事件的完整溯源过程理论终需落地。我以去年协助某电商平台排查“用户收货地址意外泄露”事件为例完整复现FindSomething如何介入、定位、验证闭环。5.1 问题浮现监控告警与初步现象该平台接入了第三方CDN日志分析服务某日凌晨收到告警“检测到大量/api/user/address请求返回200但响应体中包含完整身份证号”。运维团队第一时间封禁了相关IP但问题未根除。前端团队自查代码确认所有地址接口均做了脱敏返回idCard: 1101**********1234且无前端直接调用该接口的逻辑。5.2 FindSomething介入从DOM中锁定泄露源头我拿到问题页面URL后执行以下操作Chrome中打开该页面 → 按F12打开DevTools → 切换到Console执行fetch(https://cdn.example.com/js/app.js).then(rr.text()).then(console.log)确认前端JS未被篡改点击FindSomething图标 → 弹出Popup → 点击“扫描当前页面”3秒后结果列表出现一条高危项ID_CARD_FULL_EXPOSURE匹配文本为div classhidden># .husky/pre-commit #!/bin/sh npx findsomething --file ./src/index.html --fail-on high || exit 1这样任何含高危泄露的HTML文件都无法提交。比Code Review更早拦截问题。6.7 最后一道防线扫描结果导出与审计留痕Popup界面右上角有“Export Results”按钮导出CSV包含url、ruleId、matchedText、context、timestamp。我要求团队每次上线前将此CSV存入审计系统作为安全合规证据。它比截图更权威且可编程解析。这些技巧没有一条来自官方文档全部源于真实项目中的反复试错。当你把FindSomething从“偶尔用用的插件”变成“开发流程中呼吸般自然的存在”才算真正掌握了它的价值。