1. 破题这不是攻击教程而是防御者的资产排查清单看到Google/GitHub Hacking这个标题可能有人会下意识认为这是攻击者的技巧合集。我先说清楚我的立场我在这里讲的是防御视角的主动暴露面排查——也就是用搜索语法去发现“自家或客户公司有哪些敏感信息被公开到了互联网上”然后做收敛、处置、持续监控。这个思路在甲方安全团队里叫暴露面管理在乙方叫红队信息收集本质殊途同归如果你不主动发现这些入口真正有恶意的人就会替你发现。我先用一个具体的例子说明这件事有多现实。假设某个公司有一台面向公网的备份服务器运维图省事把一份数据库备份压缩包放在站点根目录的/backup/路径下文件名叫db_backup_2024.zip。如果没有搜索语法这个文件可能一直躺在那里不被人注意但只要用site:example.com filetype:zip这类指令扫一下它就会暴露在结果里。你问一个普通运维你们公司有没有这种情况他大概率摇头但你去搜索引擎里查一下往往能查到意外惊喜。这个内容适合谁来学我认为最值得花时间的是三类人甲方安全工程师、运维工程师需要定期梳理公司数字资产暴露面做上线前安全自检。开发工程师想知道自己的代码提交、测试配置、注释里的账号密码会不会被公开搜索引擎收录。做威胁情报和安全研究的朋友用自动化监控的方式跟踪外部针对特定关键词的泄露线索。这篇文章的核心就一句话搜索语法的本质是你用公开的数据源换取暴露面情报。而自动化监控是把“查一次”变成“每天查”“每次发布都查”从一次性的信息猎捕进化成长效的资产哨兵机制。后面我会陆续展开搜索语法怎么用、怎么组合出高精度查询、怎么用脚本做成定时巡检以及在落地过程中容易踩的坑。2. 整体思路为什么搜索引擎能成为暴露面情报源2.1 搜索引擎收录的不仅是网页更是资产指纹大多数人对搜索引擎的理解是“找网页的”。但从安全工作者的视角来看搜索引擎其实是一个巨大的被动资产测绘数据库。只要某个资源被爬虫抓取过并且没有被robots.txt明确屏蔽它的 URL、标题、文件类型、部分正文文本就可能被索引。我习惯把被索引的内容分成三类显性资产公司官网、帮助中心、开发者文档、开放 API 页面。这些本来就是公开给用户看的暴露不叫泄露。半显性资产带参数的后台入口、测试环境页面、未打补丁的框架报错页、上传目录。这些往往不在官网导航里但爬虫可能通过外链或目录遍历收录到了。隐性资产备份文件包、配置文件、日志文件、带有敏感字段的源码片段。这是最危险的一类因为它们设计的初衷就不该出现在公网。Google Hacking通常叫 Google Dorking的核心思路就是针对第三类来做“按图索骥”你不需要知道某个公司有没有泄露你只需要用语法去匹配那些只有目标机密文件才有的特征。2.2 从打猎到放哨的思维转变很多人刚接触搜索语法时会兴奋地搜着玩今天搜到某个站点的配置明天看到某个仓库的历史密钥。但发现一个删一个只是被动响应。你真正该建立的是持续发现-验证-处置-监控的闭环第一次做全量排查时用一批高覆盖率的查询语句把已知域名、已知代码托管组织、已知邮箱后缀全部扫一遍。发现的问题分优先级处置高危的立刻下线、轮换密钥中危的排期修复低危的记录在案。处置完之后不是结束而是把这些查询语句保存下来做成定时任务每 12 小时或每天跑一轮新的查询。监控输出的结果与上次比对只把新增的、变化的内容丢到通知渠道里。这样就从“被动等人告诉你”变成“主动等着情报上门”。这也是我把文章标题定为“从信息猎人进化到资产哨兵”的原因。猎人靠嗅觉去搜一次哨兵靠流程去盯长期。2.3 这套方案的适用范围与现实局限搜索语法不是万能的先认清边界能少走很多弯路它只能发现已被公开索引的内容。如果某个文件设置了严格的访问控制或者刚上传还没被爬虫收录搜索引擎是看不到的这是时效差。它受制于搜索引擎的处理能力。Google 能索引 web 网页、部分文件类型但对动态页面、需要登录的内容无能为力。GitHub 代码搜索只能搜到代码托管平台公开仓库中被索引且属于默认分支的文件。某个分支、某个提交历史里藏了密钥不一定能被搜到除非用专门的提交历史搜索。所以我的定位是搜索语法是暴露面发现的“第一漏斗”它能用低成本筛出 60% 的常见问题剩下的靠自动化工具、日志审计、源码扫描去做。这篇文章里我重点把第一漏斗走通。3. 搜索语法拆解Google 与 GitHub 的高阶姿势3.1 Google 搜索语法速查表与应用示例虽然现在很多人日常搜索习惯只用关键词但做暴露面排查时语法指令是必须掌握的。我按实用程度整理了一批语法作用暴露面排查示例site:限定搜索某个域名或站点site:example.com查看该公司被收录的所有页面inurl:匹配 URL 中的关键字段inurl:/backup/找备份目录inurl:/wp-admin/找后台intitle:匹配页面标题关键词intitle:index of找目录列表页filetype:限定文件扩展名filetype:env找环境变量文件filetype:sql找数据库备份intext:匹配页面正文字段intext:password配合站点限定找敏感文本cache:查看搜索引擎缓存的历史版本页面已下线但缓存仍在时能捞出旧内容*通配符代替任意词site:example.com admin*匹配多种后台路径-排除关键词site:example.com -filetype:html去找非网页文件单独看每个语法都很简单但实际排查中几乎都是组合使用的。我给你举几个我经常用的组合site:example.com filetype:xls OR filetype:pdf OR filetype:docx先摸一下该域名下有哪些非网页文件这些通常是文档和表格容易带内部信息。site:example.com inurl:phpMyAdmin快速找数据库管理入口的暴露。intitle:index of inurl:/config/找开放目录列表往往能看到一堆配置文件。example.com password filetype:log用邮箱后缀和密码关键词匹配日志泄漏。这里我要特别强调一个实操感悟Google 的搜索语法并不总是稳定的同一个查询可能今天有结果明天没有而且它会根据用户偏好调整排序。所以不要依赖单次结果要用多组语句交叉验证最好配合其他搜索引擎和工具平台一起看。3.2 GitHub 代码搜索语法速查表与应用示例GitHub 的代码搜索与普通网页搜索不同它有一套自己的限定符qualifier在搜索框和 API 中都能用。我按功能分了几个组范围限定repo:指定仓库owner:/user:/org:指定账号或组织。代码内容限定language:指定编程语言path:限定文件路径extension:限定扩展名filename:限定文件名。时间限定created:/pushed:/committed:配合日期比如pushed:2024-01-01。符号限定精确字符串、AND、OR、NOT以及常见的size:按文件大小过滤。举几个我在GitHub上排查泄露最常用的查询示例# 找疑似密钥文件 filename:.npmrc _authToken filename:.env APP_SECRET extension:yaml password: org:某组织名称 api_key NOT test path:config secret_keyfilename:.env APP_SECRET的意思是“在所有公开仓库中查找文件名是 .env 且内容包含 APP_SECRET 的文件”。这种组合查出来的基本上都是环境变量配置泄露实战命中率很高。你可能会问GitHub 上这么多公开仓库搜出来的结果不怕多吗严格来说单纯搜password结果会非常多所以 GitHub 的检索逻辑更倾向于“限定文件路径或文件名”。对比一下这两种查询password:会命中大量源码中的变量赋值、函数参数噪音大。filename:.npmrc _authToken只匹配 npmrc 文件里带认证 token 的记录精准度极高。这也是我在这篇文章里想反复强调的核心思路搜索语法最大的门槛不是记住语法而是理解搜索引擎如何构建索引以及如何用低噪音的特征去过滤数据。3.3 三类最容易泄露的高价值资产结合我实际的排查经验以下三类文件在 Google 和 GitHub 上的出现频率最高处置优先级也最高环境变量文件.env、.env.production、application.yml、config.php、settings.py。里面通常有数据库口令、API Key、云平台密钥对。特征是文件名固定、字段命名规律。云平台密钥对aws_access_key_id、AKIA...开头的密钥、阿里云AccessKey ID、腾讯云SecretId/SecretKey。这类一旦暴露攻击者可以直接调用云 API 创建机器、读取存储桶。数据库与中间件配置jdbc:mysql://连接串、redis密码、mongodb://链接、spring.datasource.password。特征是协议前缀明确、常出现在配置文件中。围绕这三类可以构建一个常规的“高价值目标查询清单”。后面我讲自动化监控的时候会用这个清单作为默认规则库。4. 核心细节解析搜索语法背后的收录逻辑与误报根源4.1 为什么你以为藏得很深搜索引擎还是能扒出来不少开发者和运维有过这样的困惑“我明明没把这个文件放到官网导航里怎么搜索引擎还能搜到”原因有三个爬虫会顺着所有外链爬取。某个页面引用了/backup/db.zip的下载链接或者同事在内部文档里贴了完整 URL爬虫顺藤摸瓜就能抓取。很多 Web 服务器对目录请求默认返回目录列表即使没有超链接爬虫发现目录后会把里面的文件名全部索引。公共组件、开源模板会预置默认路由比如 PHPMyAdmin、Tomcat Manager、Swagger UI这些路径是公开规律爬虫会主动探测。在 GitHub 场景下逻辑更加简单只要仓库是 public任何文件默认对所有人可见。有的团队以为“只是放上去管理一下”就没事却忽略了平台本身就会对公开代码建立全文索引。4.2 高命中率组合查询的模式总结我总结出一套“高命中率查询公式”本质是三层结构的叠加限定范围site/org/repo/path 限定文件特征filetype/filename/extension 限定内容关键字password/api_key/secret/token拿这个公式去套基本不会跑偏。举几个实例site:example.com filetype:sql INSERT INTO password找 SQL 备份中可能存在的账号表。org:某开源组织 filename:application.yml spring.datasource.password找 Spring Boot 项目配置。site:example.com AccessKey ID LTAI匹配某云厂商 AccessKey 的特征前缀。第三层的关键字选择有时候需要发散思维。比如密钥不一定叫password也可能是passwd、pwd、secret、credential、auth_token、private_key。我的建议是建立一套关键词字典按“基础词 扩展词”去轮换扩充。4.3 误报的三类根源与过滤思路凡是做过实际排查的人都知道搜索结果的“脏”是常态。误报主要来自三个方向开发测试变量Demo 项目、教程代码里大量出现password 123456、api_key test这类内容没有真实危害。代码注释或文档示例文档里写“请把YOUR_API_KEY替换为真实值”这种内容是写给使用者看的示例并非泄露。历史存量噪音某些仓库被搜索引擎收录时内容很敏感后来修复删除了但索引缓存还会保留一段时间。我通常的做法是先按文件路径、文件名的特征过滤一轮优先看.env、config 目录、部署目录再根据内容上下文判断有没有真实域名、IP、完整密钥前缀最后才是人工复核。优先级永远是文件特征 内容特征 上下文特征。5. 实操过程以 GitHub 为目标搭建暴露面监控脚本5.1 思路概览与 API 选择Google 搜索自动化相对受限因为官方没有公开的网页搜索 API第三方封装又不稳定。相比之下GitHub 的代码搜索 API 开放、文档清晰是自动化监控最合适的起点。我选择 GitHub 作为第一个自动化目标的原因有三个检索接口公开且身份认证后使用更稳定。搜索维度丰富代码、仓库、提交历史、Issue 都能搜。平台数据更新及时代码推送后很快就能被检索到适合做“上线即监控”。整体流程是用search/code接口跑一组预先设定的查询规则把结果里的仓库名、文件路径、匹配片段存下来与上次运行结果做差集把新增项推送通知。5.2 前期准备Token 的申请与权限边界调用 GitHub Search API 需要在账号设置里生成一个 Personal Access Token简称 PAT。我用的是 Fine-grained token权限只需要勾选Public repositories下的Contents: Read-only不需要写权限。设置原则是“最小够用”token 只在脚本所在机器上保存环境变量注入不要写死在代码或任何公开配置文件里。注意区分代码搜索 API 的速率限制是每分钟 10 次请求普通仓库搜索是每分钟 30 次未认证的请求会被限制得更严格。后面设计脚本时要把这个限制算进调度逻辑里否则跑不了几轮就被限流。5.3 查询规则库的设计我把查询规则设计成一个双层结构基础规则按文件特征匹配适合捕捉新出现的泄露文件。例如filename:.env、filename:.npmrc、filename:config.php、extension:sql。内容规则按高价值关键字匹配适合捕捉已有仓库中新增的敏感内容。例如spring.datasource.password、aws_access_key_id、api_key。每个规则之间用逗号分隔脚本按数组顺序轮询执行。设计时要给每个规则配一个“危险等级”字段方便处置时排优先级。5.4 代码实现一个可用的 Python 监控脚本下面这段脚本是我在实际工作中精简后的版本适合用来理解完整逻辑。我把无关业务的部分剥掉保留核心流程import requests import json import os from datetime import datetime, timedelta # 读取环境变量中的 token不要硬编码 GITHUB_TOKEN os.environ.get(GITHUB_TOKEN) SEARCH_URL https://api.github.com/search/code # 查询规则列表每一项是 (规则描述, 查询语句, 危险等级) RULES [ (env文件泄露, filename:.env, high), (npm凭证泄露, filename:.npmrc _authToken, high), (数据库口令, path:config extension:yml password, medium), (云密钥特征, extension:json aws_access_key_id, high), ] HEADERS { Authorization: ftoken {GITHUB_TOKEN}, Accept: application/vnd.githubjson, } def search_code(query: str) - list: 执行单条查询返回结果中的代码片段元信息列表 items [] page 1 while True: params { q: query, per_page: 30, page: page, } resp requests.get(SEARCH_URL, headersHEADERS, paramsparams, timeout15) if resp.status_code ! 200: print(f查询失败: {resp.status_code}, 规则: {query}) break data resp.json() items.extend(data.get(items, [])) page 1 if page data.get(total_count, 0) // 30: break # 保守限速避免触发第二重限制 time.sleep(6) return items def load_seen() - set: 加载已经处理过的结果标识用于增量比对 seen_path seen_results.json if os.path.exists(seen_path): with open(seen_path, r, encodingutf-8) as f: return set(json.load(f)) return set() def save_seen(seen: set): with open(seen_results.json, w, encodingutf-8) as f: json.dump(list(seen), f, ensure_asciiFalse) def format_notification(item: dict, rule_name: str, rule_level: str) - str: 把结果格式化成消息文本方便接入机器人通知 repo_name item[repository][full_name] file_path item[path] html_url item[html_url] return f[{rule_level}] {rule_name}\n仓库: {repo_name}\n文件: {file_path}\n链接: {html_url} def main(): seen load_seen() new_items [] for rule_name, query, level in RULES: try: results search_code(query) except Exception as e: print(f规则执行异常: {rule_name}, error{e}) continue for item in results: # 用 仓库名 文件路径 做去重标识 repo item[repository][full_name] path item[path] marker f{repo}/{path} if marker not in seen: seen.add(marker) new_items.append(format_notification(item, rule_name, level)) print(f规则完成: {rule_name}, 本次新增: {len(new_items)}) save_seen(seen) # 新增结果写入本地文件你需要再把它接入邮件/IM 机器人 if new_items: with open(alert_messages.txt, w, encodingutf-8) as f: f.write(\n.join(new_items)) print(发现新增敏感信息请查看 alert_messages.txt) else: print(本次巡检无新增结果) if __name__ __main__: main()这段脚本的核心要注意三点增量去重用仓库名/文件路径作为标识能有效避免同一条记录反复报警。搜索接口是按相关度排序不是严格按时间排序。如果你关心“最近新增”可以在规则里加上pushed:YYYY-MM-DD或committed:YYYY-MM-DD精确定位。脚本只是“监控端”结果出来后建议再接一个通知渠道。我在企业里常用的是企业微信机器人或者邮件告警格式就是上面format_notification生成的纯文本。自用的话存到本地文件或者直接打印即可。5.5 定时调度从脚本到哨兵脚本写完后还要解决“谁来定时跑”的问题。最朴素的做法是服务器上挂 crontab0 9 * * * cd /path/to/script /usr/bin/python3 monitor.py如果不想维护服务器可以用 GitHub Actions 的schedule触发器把脚本直接放在一个私有仓库里每天定时执行一次结果推送到仓库的 Issue 或外部通知服务。这样做的好处是不需要额外购买服务器坏处是执行节点在云端要留意脚本里的 token 权限隔离。我个人更推荐在服务器上跑因为排查脚本可能会持续演进出更复杂的数据处理逻辑在本地可控性更强。初期阶段也没有必要搞容器化一个虚拟环境 一个 cron 任务就够了。5.6 针对 Google 搜索的自动化补充Google 搜索没有官方 API自动化方式比较有限。但有一个替代方案用r.jina.ai这类自然语言搜索代理服务去间接检索它对普通网页内容的效果还行。我试用过几次作为辅助情报源是够用的但不建议作为主监控渠道。替代思路是把主要监控精力放在代码托管平台和某些第三方威胁情报平台它们有相对开放的检索接口自动化程度更高。Web 搜索引擎的监控可以降低频率每周手动核查一次即可。6. 处置流程与避坑经验发现泄露之后怎么办6.1 泄露信息分级确认与处置路径发现敏感信息后的第一反应不是删文件而是先冷静评估。我一般按这个顺序走截图留存证据。记录发现时间、来源链接、内容片段材料要保存在本地或内部系统。判断有效性。打开文件看内容确定里面是真实凭证还是测试占位符。比如AKIA开头的密钥可以直接用官方工具校验数据库口令可以尝试连通性测试但不要真的去读取数据。上报并定位责任人。通过仓库提交记录、文件路径、服务器访问日志找到对应的负责人确认文件用途。执行收敛。删除线上文件、回收云密钥、重置数据库口令、修改应用配置。复盘根因。是运维流程问题、开发习惯问题还是第三方服务导致的要落成整改项。这也解释了为什么我强调“哨兵”思维查一次只能解决存量问题如果不对流程做整改同样的泄露模式隔几个月就会复发。6.2 需要格外小心的两类“假泄露”我在实际排查中遇到两种最容易被误判为“严重泄露”的情况特地列出来帮大家避坑代码生成器的硬编码占位符像sk_test_XXXX、AKIAIOSFODNN7EXAMPLE这类字符串经常出现在框架文档、单元测试和 SDK Demo 中。它们的特征是前缀规则正确但内容一眼就能看出是示例。确认时只需检索前 8 位字符是否匹配真实密钥校验规则即可快速判断。私有截图泄露在某个公开仓库的 README 中开发者贴了一张调试截图里面恰好显示着数据库连接串。这类信息不会出现在代码搜索里只能靠人工浏览仓库页面时发现。这也是为什么自动化工具不能完全替代人工巡检它只能把“大部分常见问题捞掉”剩下需要人眼判断。6.3 与内部同事协作时的沟通技巧涉敏信息处置不可避免地要拉上研发和运维协作。这里有一个非常现实的经验别用“你泄露了密钥”这种话开头容易激起防御心理。我习惯的说法是“在公开代码库中发现了一个疑似配置信息先确认这个环境是否还在使用如果已停用我们直接清理如果还在用需要一起替换。”这种方式效率高很多。因为大多数配置文件泄露不是主观故意而是习惯问题提醒协助解决比追责更能推动整改落地。7. 常见问题与排查技巧实录速查表下面这个速查表是我这段实操经验的浓缩版把它打印出来贴在工位上遇到问题直接对着查现象原因处理方式GitHub 搜不到目标代码但确认仓库存在代码搜索只索引默认分支或仓库未被平台收录确认当前分支是否为 default检查仓库可见性代码搜索提示要求登录未认证的代码搜索受限为脚本配置 token或先登录网页端搜索搜索结果不是最新提交平台索引与仓库推送存在延迟使用committed:时间参数配合人工复核查询结果噪音太大关键字太宽泛改用 filename/path 限定文件特征再叠加内容关键字搜索 API 报 403速率限制触发降低请求频率token 权限检查每两条规则间隔 6 秒以上配置文件中有明文口令常见的低级问题立即轮换并在仓库中移除建议引入 secret scanner 工具做提交前检查某个文件在网页搜索可见但 GitHub 搜不到网页搜索收录了 GitHub 的页面缓存代码搜索索引不同步以代码搜索为准网页搜索结果优先人工复核我还想补充一条通用技巧排查敏感信息时不要只盯代码仓库的当前状态提交历史也值得翻一翻。很多团队删掉了当前分支的密钥文件但提交历史里还留着完整记录。GitHub 提交历史搜索的入口在搜索框切换“Commits”标签语法同样支持关键词与仓库限定。不过要注意这事的合规性边界——对自家资产做历史排查没问题对第三方资产做深度挖掘就要慎重严格在授权范围内操作。8. 写在最后监控不是目的收敛才是如果你已经能熟练地用 Google 语法和 GitHub 语法找出敏感信息我恭喜你掌握了“猎人”的技能。但真正让我觉得这套方法有价值的不是“能搜出来”而是“能在造成实际影响前发现并处置”。我自己的体会是搜索语法再怎么花哨也只是暴露面管理的第一步。完整的安全工作流还需要定期的自动化巡检、有效的告警通知、明确的处置 SOP以及团队意识的培养。你可以先从最简单的 GitHub 脚本开始跑通一轮“发现-通知-处置”流程再逐步加入 Google 和其他平台的补充监控慢慢形成属于自己团队的一套“资产哨兵机制”。最后分享一个小建议所有自动化脚本用到的查询规则库平时就要注意维护。关键词是会和现实一起演变的——今年流行的框架配置项、云平台密钥前缀可能过两年就换了。每个月花半小时更新规则库比临时想起来查一次要管用得多。