我一直觉得，SRC 信息收集做到后面，拼的早就不是工具数量，而是你对“资产”和“情报”这两个词的理解深度。第一集我们聊了从零开始怎么把域名、IP、子域名这些基础资产捞出来，很多人照着做完一轮，发现东西是收集了一堆，但真正能用的、值得花时间深挖的没几个——这种情况我太熟悉了。这篇续集不打算再重复“有哪些工具”“怎么安装”这类入门内容，而是想聊清楚一件事：信息收集的进阶，到底进在哪。进在你能把分散的子域名、IP、指纹、JS文件、备案信息串成一张有逻辑的情报网；进在你看到一份资产清单时，能一眼判断哪些是自建系统、哪些是外包残留、哪些是历史遗留；进在你不需要等扫描器跑完几个小时，就能通过几个关键信号锁定最容易出问题的目标。本篇适合那些已经跑通过一次基础信息收集流程、但觉得效率不高、思路不够系统的同学，也适合准备系统整理自己SRC方法论的人。下面所有内容都是我基于大量授权测试场景下的实操经验总结出来的，不涉及任何具体项目敏感信息，请放心阅读。1. 先想明白：信息收集到底在收集什么很多人把信息收集理解为“尽可能多地拿到域名、IP、子域名、端口”，然后用工具把所有结果堆到一起，指望数量取胜。这个思路在第一集还能用，毕竟新手阶段需要的是广度，是先把视野打开。但做到进阶阶段，如果你的目标还是“多”，而不是“准”，那大概率会陷入一个很尴尬的境地：报告写了一堆，真正有价值的发现寥寥无几。1.1 从“广撒网”到“精准打点”我见过不少朋友拿几十个字典轮番扫一个门户网站，目录跑了三天三夜，最后扫出来的都是 404 和几个静态资源，顺手还把自己本地磁盘撑满了。问题不在工具，而在没有做前置研判。一个正经的SRC信息收集流程，核心目标应该是找出目标单位在互联网上所有可访问的系统入口，并判断哪些入口最有可能存在可利用的问题。到了进阶阶段，我会把信息收集的产出分成三个层级。第一层是“资产清单”，就是域名、IP、端口这些都是什么，只解决“有什么”的问题。第二层是“资产关系”，哪些系统是同一套代码改的、哪些是同一台服务器托管的、哪些是同一个业务团队维护的，这解决的是“怎么串起来”的问题。第三层是“攻击预判”，根据指纹、报错信息、目录结构、接口风格判断这套系统大概是什么框架、什么版本、哪里可能配置不当，这解决的是“下一步往哪打”的问题。很多人卡在第二层，觉得资产之间的关系太难梳理。其实有一个很朴素的思路：凡是能通过同一个登录入口认证的，凡是共用同一套静态资源路径的，凡是在同一个IP段且开放端口高度相似的，都值得怀疑是一个业务域。把这些信号记录下来，你的情报价值立刻就不一样了。1.2 一条完整的信息收集流水线进阶信息收集不是靠某一个神级工具一步到位，而是一条流水线。我习惯把它拆成五个环节：资产确权、暴露面测绘、指纹识别、敏感信息挖掘、关联扩线。每个环节的输出，都是下一个环节的输入。资产确权解决的是“目标到底有哪些地盘”，比如主域名、子公司域名、新业务品牌、APP、小程序。暴露面测绘解决的是“这些地盘上有哪些门开着”，比如子域名解析记录、端口服务、目录接口。指纹识别解决的是“门的材质和锁芯型号”，比如框架类型、版本号、语言栈、容器。敏感信息挖掘解决的是“门旁边有没有藏钥匙”，比如代码仓库泄露、备份文件、配置文件、文档元数据。最后一步关联扩线，是拿着前面所有线索去反查，看能不能找到更多此前没发现的关联资产。这条流水线不是一个串行流程，而是每完成一轮就要回灌一次。比如你从小程序里挖到了一个 API 域名，这个域名可能反过来带你找到一个新网段，新网段里又有另一套老系统，老系统的备案信息可能关联到另一个业务主体。信息收集做到最后，其实是织网的过程，不是线性清单的过程。1.3 用ROI思维管理收集节奏进阶阶段你一定会遇到一个现实问题：客户给的测试时间有限，或者你作为个人做SRC，精力就那么多，不可能每个目标都无限深挖。这时候必须用ROI思维给目标排序。我的习惯是给每个收集到的资产打三个标签：价值标签、成本标签、风险标签。价值标签看的是这个系统是否涉及核心业务、是否有用户数据、是否承担交易功能；成本标签看的是要验证它需要多少步骤，比如是否需要复杂认证、是否需要特定客户端；风险标签看的是这个系统是不是边缘系统、是不是外包项目、是不是已经没人维护的老古董。边缘系统、无人维护的老系统、外包项目，这些通常是信息收集阶段最值得倾斜时间的。不是因为它们一定有漏洞，而是因为它们的防护通常比核心系统弱，而且历史包袱重。反过来说，那种一打开就看到完善的WAF、强制双因子认证、前后端分离且接口全部走网关的系统，你花再多时间收集也可能一无所获，这时候沉没成本要果断止损。提示：信息收集的终极目标是给后续测试环节提供“最有把握的入口”，不是把自己累死。每个目标投入的时间要有上限，我一般单个资产不超过2小时，如果2小时内没发现值得深挖的信号，就切下一个。2. 资产确权：把目标的所有“分身”找全SRC项目里最常见的坑就是目标范围没搞清楚。甲方给了一个主域名，你觉得挺清晰，但实际上一查，这个集团下面还有一堆子公司、关联公司、海外主体，每个主体都有自己的域名和系统。这些算不算目标范围？严格来说要回到授权书和项目范围说明里去确认，但在信息收集阶段，你至少应该先把它们全找出来，再逐一对照范围。这个环节我称之为“确权”，因为你不只要收集，还要为后续每一个动作确认“这个资产能不能碰”。2.1 不止主域名：企业关系网里的隐藏资产第一步一定是从公开的企业信息入手。目标主体通常有工商信息，这些信息里能看到股东、对外投资、分支机构、主要人员。每一层节点都可能对应一个新域名、一个新系统。实操中我会把企业关系数据整理成表格，一列是主体名称，一列是关联方式，一列是来源链接，然后在每个主体后面继续做域名收集。不要小看这个方法。某次模拟测试中，我从一个主目标往下一层，发现它投资了一个做物流系统的子公司，这个子公司的官网挂在另一个独立域名上，而那个域名解析到一台托管服务器，服务器上直接开着管理后台的登录页，且没有任何访问控制。这一步的价值，比我后续扫任何子域都要大。当然，实际操作中必须确认范围，这里重点分享思路。2.2 备案反查与品牌词组合的玩法中国企业域名有个特点，绝大多数都要走ICP备案，备案信息里包含主体名称、域名列表、备案号。反过来查，就可以通过主体名称把该主体名下的域名全部拉出来。这比穷举子域名快得多，因为你拿到的是“官方注册”的域名，往往就是核心业务入口。除了备案反查，还要关注品牌词组合。很多大公司会注册一堆和主品牌相近、容易混淆的域名，这些域名不一定在备案列表里，但确实解析到业务系统。常见的注册习惯包括：加上“test”“dev”“staging”“demo”“old”“new”“v2”这类后缀，或者使用不同的顶级域（比如.com之外还有.cn、.net、.org甚至.io）。信息收集阶段，我会把目标品牌的拼音、英文名、缩写整理成字典，用批量查询的方式看哪些域名被人注册过、哪些解析到了真实服务器。2.3 APP和小程序：手机端的资产别漏了现在很多业务的入口早就不在网页端了，特别是面向消费者的业务，主力产品是APP，还配套一堆小程序和公众号。信息收集如果把APP资产漏掉，相当于只摸了一半暴露面。APP层面的信息收集要从应用商店开始。在商店里能找到开发者主体名称，这个名称可以用来反查这个开发者还发布过哪些其他APP。下载安装后，我会把APP的安装包存起来，后面用于提取代码中的接口地址和配置信息，这个环节我放到后面敏感信息部分细说。小程序方面，微信搜索、支付宝小程序搜索都能定位官方小程序，小程序包的拉取和源码分析现在已经有不少成熟的辅助工具，但我这里不展开讲具体工具链，重点是思路：凡是你能在手机上下载到的应用，都是潜在的攻击面，都不要漏。3. 域名与DNS层：信息收集的黄金入口子域名收集是信息收集的经典项目，第一集应该已经覆盖了基础的暴力枚举和证书透明日志。这里我想聊的是更深一层的东西：哪些子域名收集手段是真正的高性价比？哪些数据值得你持续维护？3.1 证书透明日志的价值与用法证书透明日志（CT日志）是我个人最喜欢的子域名情报源。因为CA在签发证书时会把证书记录到公开日志里，任何人通过查询就能知道某个域名下最近签发了哪些证书。对于SRC信息收集来说，CT日志有两个独特优势：第一，它能收集到很多没有公开发布的内部子域名；第二，它有时间戳，你可以看到某个子域名是最近才被创建证书的，这往往意味着背后有新的业务系统上线。光靠一个CT日志查询服务不够，实战中要把多个CT源的数据合并去重。我自己维护了一个简单的定时任务，每天把关注域名的CT数据拉一遍，存到本地，这样当目标系统新上线一个内部工具时，我能第一时间知道。这种“数据积累”的玩法，比临时扫一轮要强太多。3.2 DNS历史解析和被动收集子域名收集还有一个维度值得关注：它不是静态的。很多子域名的A记录会变化，旧地址可能指向云服务器，现在迁移到了新的云服务商；有些子域名长期没有解析记录，但历史上有过，意味着这台服务器曾经存在过。DNS历史查询在信息收集阶段的作用，是帮你找到那些下线但可能仍在内网存活的系统线索，或者找到曾经的云资产归属网段。被动收集方面，除了常规的证书透明，我还会关注一些公开的被动DNS数据源和搜索引擎的缓存结果。整体思路是：主动枚举你能想到的名字，被动收集你没想到但真实存在的名字，两条腿走路才能覆盖得全。实操时，我会把主动枚举的子域名和被动收集到的子域名分别标记，后续做指纹识别时优先看被动收集的，因为它们往往更冷门、更可能缺乏维护。3.3 favicon图标哈希与图标检索这是一个非常实用但经常被忽略的技巧。很多系统的favicon图标是独有的，把favicon文件做哈希处理后，可以用公开的搜索引擎查询同一个哈希值在其他哪些域名上也出现过。这个方法特别适合用来找同一套图标体系下的“兄弟系统”。举例来说，一个主域名用的是公司Logo图标，那你拿这个图标哈希去检索，很可能找到一堆旁边没被人注意过的关联资产——可能是某个内部系统的登录页，用的图标跟官网完全一致。这类资产往往不在备案信息里，也不在CT日志里，只有通过图标这种“指纹”才能把它们从海量数据里挖出来。类似的思路还能扩展到页面标题、首页关键词、页面版权声明这些特征。4. 主动探测与接口发现：从“知道有什么”到“找到能打的”子域名和IP收集得差不多之后，下一步自然就是探测这些资产上到底跑着什么服务、有哪些目录和接口。这个环节如果只靠扫描器跑，效率和准确率都不会太理想。我习惯把主动探测分成几个阶段来做。4.1 目录字典：别只用一份通用字典很多人跑目录扫描时，喜欢直接用一个几万条的大字典从头跑到尾。不是说这不行，但如果目标明确知道自己是什么框架，你就可以定制一套“高命中率”的字典，速度更快、结果更干净。举个例子，目标系统如果是Java系的老系统，那常见路径就有actuator接口、druid监控页、swagger文档页、WEB-INF目录这类特征路径；如果目标系统是ThinkPHP，那跑一些PHPIDE路径和备份文件路径更有意义。关键是根据指纹来决定字典的侧重点。我的做法是准备几套基础字典，再准备一个“叠加字典”，里面全是各框架特有的敏感路径，拿到指纹后把对应部分并进基础字典再跑。4.2 从JS文件和源码注释里挖接口主动探测目录扫到的东西终究有限，真正的接口宝藏常常藏在JS文件里。现在的Web应用基本都是前后端分离，前端JS文件会写明API的路径、请求方法、参数结构，甚至偶尔还会出现写死的密钥和测试账号。我的做法是，在拿到目标站点的页面之后，把当前页面用到的所有JS文件列表拉出来，逐个下载保存，然后做关键词匹配。重点关注的关键词包括：api、admin、list、upload、download、config、token、key、secret、internal、debug、test。匹配到结果后，把完整的接口路径还原出来，然后手动访问或批量请求，观察返回的数据格式和状态码。这个过程中最常出现的惊喜，就是找到了没有加鉴权的管理接口或者内部查询接口。4.3 授权范围内的403绕过思路主动探测时遇到403是很常见的事，很多人直接跳过，其实403页面恰恰值得停下来想想。403本质上是说“服务器知道资源存在，但你当前这个身份不被允许访问”，这透露了一个关键信息：资源可能真实存在。在授权测试场景下，可以尝试一些非破坏性验证思路。比如从域名访问改成IP访问，或者反过来；把路径的大小写转换一下；在URL后面加一个合法参数让请求命中不同的处理逻辑；尝试用POST请求替代GET请求看看是不是方法限制。这些操作的目的不是绕过访问控制去做未授权操作，而是为了判断目标是否存在“访问控制配置不当”这类值得上报的风险。每做完一种尝试，都必须记录请求的方法、路径、返回码，方便后续写报告时复盘。特别要强调的是，所有操作都必须严格遵循授权范围，超出范围的一律不做。注意：403绕过的核心价值在于确认“资源存在但访问控制缺失”，而不是鼓励无限制地突破边界。如果尝试过程中发现已经进入需要特定授权才能访问的数据区域，请立即停止并记录时间点，交给项目负责人判断。5. 指纹识别与技术栈研判指纹识别是整个信息收集环节里最能拉开差距的部分之一。同样看到一个登录页，新手会直接开始跑弱口令，而熟练的人会先判断这套系统是什么框架、什么版本、有没有历史公开漏洞、默认配置是否改过。这些判断的依据，就来自指纹信息。5.1 指纹识别的几个维度技术栈指纹不光是看首页返回的响应头，至少可以从五个维度去判断。第一是响应头，比如Server字段、X-Powered-By字段、Set-Cookie的名称；第二是页面结构，比如特定框架的报错页风格、默认登录框DOM结构、特定版权声明；第三是静态资源路径，比如常见框架的默认JS/CSS文件名；第四是URL风格，比如ThinkPHP的index.php路由形式，Java Spring的/api路径风格；第五是Cookie行为，有些框架生成的会话Cookie名称是固定的。把这五个维度的信息汇总起来，基本就能判断出目标用的具体框架和大致版本。这时候再去查这个版本的公开漏洞，方向就会非常清晰。我经常说，指纹识别做得好，后面省的不只是时间，更是你盲目的精力消耗。5.2 常见指纹的实战意义每种指纹背后都对应一套后续打法。比如识别到目标使用了某种开源CMS且版本较老，那就可以直接去查该版本的历史漏洞库，重点看有没有前台RCE或SQL注入；如果识别到目标用的是某种微服务网关，那重点看路由配置是否可改写、是否存在未授权访问；如果识别到后端是Node.js且接口返回里有特定报错格式，那可以关注一下依赖组件是否存在已知CVE。我习惯把指纹信息记在一个简单的表格里，字段包括：目标URL、指纹来源、判断结果、置信度、下一步建议。积累到一定数量后，你会发现很多目标之间其实有共性的技术栈，而这些共性往往说明它们来自同一家外包开发商或者同一套内部框架，一个点打穿，其他点可以复用同一套思路。这就是信息收集进阶真正的价值，不是单点收集，而是形成体系预判的能力。6. 敏感信息与历史痕迹挖掘信息收集到了这个阶段，已经不只是收集“活跃资产”了，而是要把目光放到那些可能被遗忘、被忽略的信息痕迹上。老话说“百密一疏”，很多系统上线时很安全，但开发过程中留下的痕迹往往没有清理干净，这些痕迹就是信息收集阶段最有价值的产出来源。6.1 代码仓库泄露开发人员习惯把代码放到公开代码托管平台上，有些是私有仓库，但也总有意外泄露的情况。信息收集阶段，我会用目标的域名、品牌名、核心产品名作为关键词，在公开代码平台上搜索。重点关注仓库名里带目标品牌、描述里带官网域名、代码里出现目标API地址的仓库。如果真找到了目标相关的代码仓库，先别急着高兴，要按重要程度排序去检查。第一优先看配置文件，包括数据库连接、云服务密钥、第三方API Token；第二看部署脚本，里面可能写有服务器地址和账号信息；第三看近期提交记录，提交信息里可能包含内网地址或测试账号。在授权测试项目里，发现代码仓库泄露本身就是一条可以直接上报的安全问题，因为代码中往往包含大量关于系统的内部信息。6.2 云存储与公开文档国内很多企业都在使用云存储服务，经常出现配置不当的情况。判断的依据很简单：如果访问一个对象存储的URL能直接以目录形式列出文件列表，那就是配置不当。信息收集阶段，可以用目标的域名、品牌拼音、业务关键词去拼可能的存储桶名称，或者通过公开的接口搜索引擎来检索。公开文档也是容易被忽视的一块。网上搜索目标的域名或者品牌名，经常能搜到一些内部培训PPT、运维手册、业务流程图。这些文档里偶尔会出现内网IP、服务器命名规则、系统架构图，甚至直接附带了部分账号密码。文档类信息虽然不算直接的漏洞，但能大幅提升你对目标内部架构的理解，帮你更精准地做后续收集。6.3 把零散信息拼成一张情报网单条敏感信息看起来没有特别大的价值，但把它们拼起来就是一张完整的情报网。比如你从一个公开仓库里拿到了内网IP段，又从一篇文档里知道了服务器命名规则，再从APP的JS文件里挖到了一个内部API域名，这几个信息合在一起，你就能推测出目标大概的部署架构：哪些系统在前端，哪些系统在内网，哪些接口是内部专用的。信息收集到这一步才算完整。我自己的做法是每拿到一条新线索，就问自己三个问题：它能不能帮我找到新的资产？它能不能帮我判断某个系统的重要性？它能不能帮我省掉后续测试的某些步骤？如果三个问题的答案都是否，那这条线索就先放到备选池里，不急着现在用。信息收集的时间是有限的，一定要把精力放在能产生连锁反应的信息上。7. 常见问题与避坑实录信息收集看起来是体力活，但实际操作中的坑非常多。我踩过的坑估计比很多新手扫过的目录还多，这里整理几个典型的问题和排查思路，供你参考。7.1 信息收集阶段常见的5个问题第一个问题是“收集结果过多，筛选困难”。扫了几万个URL，最后没法判断哪些值得看。解决思路是在收集阶段就加入过滤条件，比如先按响应码过滤，只保留200和301的；再按标题过滤，去掉静态页面；最后按指纹分组，把同类的放一起抽查。第二个问题是“目标范围跑偏”，收到一个没在授权范围的资产上去了。这个没有别的办法，只能靠收集之前把资产范围表做扎实，每新增一个资产就先对照范围表。第三个问题是“重复扫描”，同一批子域名被多个工具反复扫，浪费时间。解决办法是收口，所有收集结果统一走一个汇总，每个目标只做一轮标准扫描。第四个问题是“工具报错看不懂”，比如依赖缺失、权限不足。多数时候是环境问题，先把工具链用容器化管理，能省很多时间。第五个问题是“报告数据不完整”，测试做完了，信息收集阶段的证据却找不全。这个要靠流程规范，每验证一个点就立刻截图存档。7.2 合规与边界：收集不等于越权信息收集是SRC流程中离“边界”最近的一个环节，因为主动扫描、目录枚举、接口探测本质上都在和目标系统交互。这里必须有一个清晰且不可逾越的底线：所有操作都只能作用于你获得授权、且明确写入项目范围的目标。任何超出范围的探测，哪怕只是扫描一个“看起来关联”的IP，都可能构成越权，这不是技术问题，是合规问题。另外还要注意数据最小化。信息收集阶段可能接触到目标系统中的敏感数据，比如测试账号、内部人员信息、客户信息。这些数据只能在项目范围内使用，不能留存超过必要时间，不能复制到个人设备上，更不能在工作交流群里传播。我自己的习惯是，每个项目结束之后，会专门清理一次本地缓存和备份文件，确保没有项目数据残留。这块意识要放到和技术同等重要的位置。7.3 收尾工作：证据固化与报告整理信息收集阶段结束之后，至少要输出三类成果。第一类是资产清单，包含所有确认过的域名、IP、指纹、归属状态，并标注哪些是核心资产、哪些是边缘资产。第二类是测试路线图，就是从所有收集结果中筛选出的下一步测试重点，每个重点都要写清楚理由。第三类是证据包，包括发现敏感信息时的截图、响应包、请求记录，按编号整理好。证据的规整程度直接影响后续漏洞报告的质量。我见过太多报名因为时间紧张、证据零散而显得不专业的情况。实操中我会给每个待测点建一个文件夹，里面放好描述、证据、请求包和处置建议。这些材料看起来只是信息收集的副产品，但等到项目结束或者需要回溯时，你就知道这套习惯有多重要了。最后聊几句写了这么多，最想传达的一个观点是：SRC信息收集的进阶，本质上是情报思维的进阶。工具永远是执行层的东西，真正值钱的是你拿到一堆原始数据之后，能不能把它们组织成有逻辑、有优先级、能指导行动的结构化情报。我自己早期也走过弯路，总以为收集得越多就越接近成功，结果大量时间浪费在无限扩大的信息海洋里。后来换了思路，每一次收集都带着明确问题去，比如“我想证明这个系统是否有配置不当”“我想判断这个域名是否值得深挖”“我想把这条线索扩成新的关联资产”，效率一下子提升了很多。信息收集不是一个体力活干完就结束的，它是一个需要不断回看、修正、沉淀的过程。希望这篇延续第一集的分享，能帮你少走一些我走过的弯路。
我一直觉得，SRC 信息收集做到后面，拼的早就不是工具数量，而是你对“资产”和“情报”这两个词的理解深度。第一集我们聊了从零开始怎么把域名、IP、子域名这些基础资产捞出来，很多人照着做完一轮，发现东西是收集了一堆，但真正能用的、值得花时间深挖的没几个——这种情况我太熟悉了。这篇续集不打算再重复“有哪些工具”“怎么安装”这类入门内容，而是想聊清楚一件事：信息收集的进阶，到底进在哪。进在你能把分散的子域名、IP、指纹、JS文件、备案信息串成一张有逻辑的情报网；进在你看到一份资产清单时，能一眼判断哪些是自建系统、哪些是外包残留、哪些是历史遗留；进在你不需要等扫描器跑完几个小时，就能通过几个关键信号锁定最容易出问题的目标。本篇适合那些已经跑通过一次基础信息收集流程、但觉得效率不高、思路不够系统的同学，也适合准备系统整理自己SRC方法论的人。下面所有内容都是我基于大量授权测试场景下的实操经验总结出来的，不涉及任何具体项目敏感信息，请放心阅读。1. 先想明白：信息收集到底在收集什么很多人把信息收集理解为“尽可能多地拿到域名、IP、子域名、端口”，然后用工具把所有结果堆到一起，指望数量取胜。这个思路在第一集还能用，毕竟新手阶段需要的是广度，是先把视野打开。但做到进阶阶段，如果你的目标还是“多”，而不是“准”，那大概率会陷入一个很尴尬的境地：报告写了一堆，真正有价值的发现寥寥无几。1.1 从“广撒网”到“精准打点”我见过不少朋友拿几十个字典轮番扫一个门户网站，目录跑了三天三夜，最后扫出来的都是 404 和几个静态资源，顺手还把自己本地磁盘撑满了。问题不在工具，而在没有做前置研判。一个正经的SRC信息收集流程，核心目标应该是找出目标单位在互联网上所有可访问的系统入口，并判断哪些入口最有可能存在可利用的问题。到了进阶阶段，我会把信息收集的产出分成三个层级。第一层是“资产清单”，就是域名、IP、端口这些都是什么，只解决“有什么”的问题。第二层是“资产关系”，哪些系统是同一套代码改的、哪些是同一台服务器托管的、哪些是同一个业务团队维护的，这解决的是“怎么串起来”的问题。第三层是“攻击预判”，根据指纹、报错信息、目录结构、接口风格判断这套系统大概是什么框架、什么版本、哪里可能配置不当，这解决的是“下一步往哪打”的问题。很多人卡在第二层，觉得资产之间的关系太难梳理。其实有一个很朴素的思路：凡是能通过同一个登录入口认证的，凡是共用同一套静态资源路径的，凡是在同一个IP段且开放端口高度相似的，都值得怀疑是一个业务域。把这些信号记录下来，你的情报价值立刻就不一样了。1.2 一条完整的信息收集流水线进阶信息收集不是靠某一个神级工具一步到位，而是一条流水线。我习惯把它拆成五个环节：资产确权、暴露面测绘、指纹识别、敏感信息挖掘、关联扩线。每个环节的输出，都是下一个环节的输入。资产确权解决的是“目标到底有哪些地盘”，比如主域名、子公司域名、新业务品牌、APP、小程序。暴露面测绘解决的是“这些地盘上有哪些门开着”，比如子域名解析记录、端口服务、目录接口。指纹识别解决的是“门的材质和锁芯型号”，比如框架类型、版本号、语言栈、容器。敏感信息挖掘解决的是“门旁边有没有藏钥匙”，比如代码仓库泄露、备份文件、配置文件、文档元数据。最后一步关联扩线，是拿着前面所有线索去反查，看能不能找到更多此前没发现的关联资产。这条流水线不是一个串行流程，而是每完成一轮就要回灌一次。比如你从小程序里挖到了一个 API 域名，这个域名可能反过来带你找到一个新网段，新网段里又有另一套老系统，老系统的备案信息可能关联到另一个业务主体。信息收集做到最后，其实是织网的过程，不是线性清单的过程。1.3 用ROI思维管理收集节奏进阶阶段你一定会遇到一个现实问题：客户给的测试时间有限，或者你作为个人做SRC，精力就那么多，不可能每个目标都无限深挖。这时候必须用ROI思维给目标排序。我的习惯是给每个收集到的资产打三个标签：价值标签、成本标签、风险标签。价值标签看的是这个系统是否涉及核心业务、是否有用户数据、是否承担交易功能；成本标签看的是要验证它需要多少步骤，比如是否需要复杂认证、是否需要特定客户端；风险标签看的是这个系统是不是边缘系统、是不是外包项目、是不是已经没人维护的老古董。边缘系统、无人维护的老系统、外包项目，这些通常是信息收集阶段最值得倾斜时间的。不是因为它们一定有漏洞，而是因为它们的防护通常比核心系统弱，而且历史包袱重。反过来说，那种一打开就看到完善的WAF、强制双因子认证、前后端分离且接口全部走网关的系统，你花再多时间收集也可能一无所获，这时候沉没成本要果断止损。提示：信息收集的终极目标是给后续测试环节提供“最有把握的入口”，不是把自己累死。每个目标投入的时间要有上限，我一般单个资产不超过2小时，如果2小时内没发现值得深挖的信号，就切下一个。2. 资产确权：把目标的所有“分身”找全SRC项目里最常见的坑就是目标范围没搞清楚。甲方给了一个主域名，你觉得挺清晰，但实际上一查，这个集团下面还有一堆子公司、关联公司、海外主体，每个主体都有自己的域名和系统。这些算不算目标范围？严格来说要回到授权书和项目范围说明里去确认，但在信息收集阶段，你至少应该先把它们全找出来，再逐一对照范围。这个环节我称之为“确权”，因为你不只要收集，还要为后续每一个动作确认“这个资产能不能碰”。2.1 不止主域名：企业关系网里的隐藏资产第一步一定是从公开的企业信息入手。目标主体通常有工商信息，这些信息里能看到股东、对外投资、分支机构、主要人员。每一层节点都可能对应一个新域名、一个新系统。实操中我会把企业关系数据整理成表格，一列是主体名称，一列是关联方式，一列是来源链接，然后在每个主体后面继续做域名收集。不要小看这个方法。某次模拟测试中，我从一个主目标往下一层，发现它投资了一个做物流系统的子公司，这个子公司的官网挂在另一个独立域名上，而那个域名解析到一台托管服务器，服务器上直接开着管理后台的登录页，且没有任何访问控制。这一步的价值，比我后续扫任何子域都要大。当然，实际操作中必须确认范围，这里重点分享思路。2.2 备案反查与品牌词组合的玩法中国企业域名有个特点，绝大多数都要走ICP备案，备案信息里包含主体名称、域名列表、备案号。反过来查，就可以通过主体名称把该主体名下的域名全部拉出来。这比穷举子域名快得多，因为你拿到的是“官方注册”的域名，往往就是核心业务入口。除了备案反查，还要关注品牌词组合。很多大公司会注册一堆和主品牌相近、容易混淆的域名，这些域名不一定在备案列表里，但确实解析到业务系统。常见的注册习惯包括：加上“test”“dev”“staging”“demo”“old”“new”“v2”这类后缀，或者使用不同的顶级域（比如.com之外还有.cn、.net、.org甚至.io）。信息收集阶段，我会把目标品牌的拼音、英文名、缩写整理成字典，用批量查询的方式看哪些域名被人注册过、哪些解析到了真实服务器。2.3 APP和小程序：手机端的资产别漏了现在很多业务的入口早就不在网页端了，特别是面向消费者的业务，主力产品是APP，还配套一堆小程序和公众号。信息收集如果把APP资产漏掉，相当于只摸了一半暴露面。APP层面的信息收集要从应用商店开始。在商店里能找到开发者主体名称，这个名称可以用来反查这个开发者还发布过哪些其他APP。下载安装后，我会把APP的安装包存起来，后面用于提取代码中的接口地址和配置信息，这个环节我放到后面敏感信息部分细说。小程序方面，微信搜索、支付宝小程序搜索都能定位官方小程序，小程序包的拉取和源码分析现在已经有不少成熟的辅助工具，但我这里不展开讲具体工具链，重点是思路：凡是你能在手机上下载到的应用，都是潜在的攻击面，都不要漏。3. 域名与DNS层：信息收集的黄金入口子域名收集是信息收集的经典项目，第一集应该已经覆盖了基础的暴力枚举和证书透明日志。这里我想聊的是更深一层的东西：哪些子域名收集手段是真正的高性价比？哪些数据值得你持续维护？3.1 证书透明日志的价值与用法证书透明日志（CT日志）是我个人最喜欢的子域名情报源。因为CA在签发证书时会把证书记录到公开日志里，任何人通过查询就能知道某个域名下最近签发了哪些证书。对于SRC信息收集来说，CT日志有两个独特优势：第一，它能收集到很多没有公开发布的内部子域名；第二，它有时间戳，你可以看到某个子域名是最近才被创建证书的，这往往意味着背后有新的业务系统上线。光靠一个CT日志查询服务不够，实战中要把多个CT源的数据合并去重。我自己维护了一个简单的定时任务，每天把关注域名的CT数据拉一遍，存到本地，这样当目标系统新上线一个内部工具时，我能第一时间知道。这种“数据积累”的玩法，比临时扫一轮要强太多。3.2 DNS历史解析和被动收集子域名收集还有一个维度值得关注：它不是静态的。很多子域名的A记录会变化，旧地址可能指向云服务器，现在迁移到了新的云服务商；有些子域名长期没有解析记录，但历史上有过，意味着这台服务器曾经存在过。DNS历史查询在信息收集阶段的作用，是帮你找到那些下线但可能仍在内网存活的系统线索，或者找到曾经的云资产归属网段。被动收集方面，除了常规的证书透明，我还会关注一些公开的被动DNS数据源和搜索引擎的缓存结果。整体思路是：主动枚举你能想到的名字，被动收集你没想到但真实存在的名字，两条腿走路才能覆盖得全。实操时，我会把主动枚举的子域名和被动收集到的子域名分别标记，后续做指纹识别时优先看被动收集的，因为它们往往更冷门、更可能缺乏维护。3.3 favicon图标哈希与图标检索这是一个非常实用但经常被忽略的技巧。很多系统的favicon图标是独有的，把favicon文件做哈希处理后，可以用公开的搜索引擎查询同一个哈希值在其他哪些域名上也出现过。这个方法特别适合用来找同一套图标体系下的“兄弟系统”。举例来说，一个主域名用的是公司Logo图标，那你拿这个图标哈希去检索，很可能找到一堆旁边没被人注意过的关联资产——可能是某个内部系统的登录页，用的图标跟官网完全一致。这类资产往往不在备案信息里，也不在CT日志里，只有通过图标这种“指纹”才能把它们从海量数据里挖出来。类似的思路还能扩展到页面标题、首页关键词、页面版权声明这些特征。4. 主动探测与接口发现：从“知道有什么”到“找到能打的”子域名和IP收集得差不多之后，下一步自然就是探测这些资产上到底跑着什么服务、有哪些目录和接口。这个环节如果只靠扫描器跑，效率和准确率都不会太理想。我习惯把主动探测分成几个阶段来做。4.1 目录字典：别只用一份通用字典很多人跑目录扫描时，喜欢直接用一个几万条的大字典从头跑到尾。不是说这不行，但如果目标明确知道自己是什么框架，你就可以定制一套“高命中率”的字典，速度更快、结果更干净。举个例子，目标系统如果是Java系的老系统，那常见路径就有actuator接口、druid监控页、swagger文档页、WEB-INF目录这类特征路径；如果目标系统是ThinkPHP，那跑一些PHPIDE路径和备份文件路径更有意义。关键是根据指纹来决定字典的侧重点。我的做法是准备几套基础字典，再准备一个“叠加字典”，里面全是各框架特有的敏感路径，拿到指纹后把对应部分并进基础字典再跑。4.2 从JS文件和源码注释里挖接口主动探测目录扫到的东西终究有限，真正的接口宝藏常常藏在JS文件里。现在的Web应用基本都是前后端分离，前端JS文件会写明API的路径、请求方法、参数结构，甚至偶尔还会出现写死的密钥和测试账号。我的做法是，在拿到目标站点的页面之后，把当前页面用到的所有JS文件列表拉出来，逐个下载保存，然后做关键词匹配。重点关注的关键词包括：api、admin、list、upload、download、config、token、key、secret、internal、debug、test。匹配到结果后，把完整的接口路径还原出来，然后手动访问或批量请求，观察返回的数据格式和状态码。这个过程中最常出现的惊喜，就是找到了没有加鉴权的管理接口或者内部查询接口。4.3 授权范围内的403绕过思路主动探测时遇到403是很常见的事，很多人直接跳过，其实403页面恰恰值得停下来想想。403本质上是说“服务器知道资源存在，但你当前这个身份不被允许访问”，这透露了一个关键信息：资源可能真实存在。在授权测试场景下，可以尝试一些非破坏性验证思路。比如从域名访问改成IP访问，或者反过来；把路径的大小写转换一下；在URL后面加一个合法参数让请求命中不同的处理逻辑；尝试用POST请求替代GET请求看看是不是方法限制。这些操作的目的不是绕过访问控制去做未授权操作，而是为了判断目标是否存在“访问控制配置不当”这类值得上报的风险。每做完一种尝试，都必须记录请求的方法、路径、返回码，方便后续写报告时复盘。特别要强调的是，所有操作都必须严格遵循授权范围，超出范围的一律不做。注意：403绕过的核心价值在于确认“资源存在但访问控制缺失”，而不是鼓励无限制地突破边界。如果尝试过程中发现已经进入需要特定授权才能访问的数据区域，请立即停止并记录时间点，交给项目负责人判断。5. 指纹识别与技术栈研判指纹识别是整个信息收集环节里最能拉开差距的部分之一。同样看到一个登录页，新手会直接开始跑弱口令，而熟练的人会先判断这套系统是什么框架、什么版本、有没有历史公开漏洞、默认配置是否改过。这些判断的依据，就来自指纹信息。5.1 指纹识别的几个维度技术栈指纹不光是看首页返回的响应头，至少可以从五个维度去判断。第一是响应头，比如Server字段、X-Powered-By字段、Set-Cookie的名称；第二是页面结构，比如特定框架的报错页风格、默认登录框DOM结构、特定版权声明；第三是静态资源路径，比如常见框架的默认JS/CSS文件名；第四是URL风格，比如ThinkPHP的index.php路由形式，Java Spring的/api路径风格；第五是Cookie行为，有些框架生成的会话Cookie名称是固定的。把这五个维度的信息汇总起来，基本就能判断出目标用的具体框架和大致版本。这时候再去查这个版本的公开漏洞，方向就会非常清晰。我经常说，指纹识别做得好，后面省的不只是时间，更是你盲目的精力消耗。5.2 常见指纹的实战意义每种指纹背后都对应一套后续打法。比如识别到目标使用了某种开源CMS且版本较老，那就可以直接去查该版本的历史漏洞库，重点看有没有前台RCE或SQL注入；如果识别到目标用的是某种微服务网关，那重点看路由配置是否可改写、是否存在未授权访问；如果识别到后端是Node.js且接口返回里有特定报错格式，那可以关注一下依赖组件是否存在已知CVE。我习惯把指纹信息记在一个简单的表格里，字段包括：目标URL、指纹来源、判断结果、置信度、下一步建议。积累到一定数量后，你会发现很多目标之间其实有共性的技术栈，而这些共性往往说明它们来自同一家外包开发商或者同一套内部框架，一个点打穿，其他点可以复用同一套思路。这就是信息收集进阶真正的价值，不是单点收集，而是形成体系预判的能力。6. 敏感信息与历史痕迹挖掘信息收集到了这个阶段，已经不只是收集“活跃资产”了，而是要把目光放到那些可能被遗忘、被忽略的信息痕迹上。老话说“百密一疏”，很多系统上线时很安全，但开发过程中留下的痕迹往往没有清理干净，这些痕迹就是信息收集阶段最有价值的产出来源。6.1 代码仓库泄露开发人员习惯把代码放到公开代码托管平台上，有些是私有仓库，但也总有意外泄露的情况。信息收集阶段，我会用目标的域名、品牌名、核心产品名作为关键词，在公开代码平台上搜索。重点关注仓库名里带目标品牌、描述里带官网域名、代码里出现目标API地址的仓库。如果真找到了目标相关的代码仓库，先别急着高兴，要按重要程度排序去检查。第一优先看配置文件，包括数据库连接、云服务密钥、第三方API Token；第二看部署脚本，里面可能写有服务器地址和账号信息；第三看近期提交记录，提交信息里可能包含内网地址或测试账号。在授权测试项目里，发现代码仓库泄露本身就是一条可以直接上报的安全问题，因为代码中往往包含大量关于系统的内部信息。6.2 云存储与公开文档国内很多企业都在使用云存储服务，经常出现配置不当的情况。判断的依据很简单：如果访问一个对象存储的URL能直接以目录形式列出文件列表，那就是配置不当。信息收集阶段，可以用目标的域名、品牌拼音、业务关键词去拼可能的存储桶名称，或者通过公开的接口搜索引擎来检索。公开文档也是容易被忽视的一块。网上搜索目标的域名或者品牌名，经常能搜到一些内部培训PPT、运维手册、业务流程图。这些文档里偶尔会出现内网IP、服务器命名规则、系统架构图，甚至直接附带了部分账号密码。文档类信息虽然不算直接的漏洞，但能大幅提升你对目标内部架构的理解，帮你更精准地做后续收集。6.3 把零散信息拼成一张情报网单条敏感信息看起来没有特别大的价值，但把它们拼起来就是一张完整的情报网。比如你从一个公开仓库里拿到了内网IP段，又从一篇文档里知道了服务器命名规则，再从APP的JS文件里挖到了一个内部API域名，这几个信息合在一起，你就能推测出目标大概的部署架构：哪些系统在前端，哪些系统在内网，哪些接口是内部专用的。信息收集到这一步才算完整。我自己的做法是每拿到一条新线索，就问自己三个问题：它能不能帮我找到新的资产？它能不能帮我判断某个系统的重要性？它能不能帮我省掉后续测试的某些步骤？如果三个问题的答案都是否，那这条线索就先放到备选池里，不急着现在用。信息收集的时间是有限的，一定要把精力放在能产生连锁反应的信息上。7. 常见问题与避坑实录信息收集看起来是体力活，但实际操作中的坑非常多。我踩过的坑估计比很多新手扫过的目录还多，这里整理几个典型的问题和排查思路，供你参考。7.1 信息收集阶段常见的5个问题第一个问题是“收集结果过多，筛选困难”。扫了几万个URL，最后没法判断哪些值得看。解决思路是在收集阶段就加入过滤条件，比如先按响应码过滤，只保留200和301的；再按标题过滤，去掉静态页面；最后按指纹分组，把同类的放一起抽查。第二个问题是“目标范围跑偏”，收到一个没在授权范围的资产上去了。这个没有别的办法，只能靠收集之前把资产范围表做扎实，每新增一个资产就先对照范围表。第三个问题是“重复扫描”，同一批子域名被多个工具反复扫，浪费时间。解决办法是收口，所有收集结果统一走一个汇总，每个目标只做一轮标准扫描。第四个问题是“工具报错看不懂”，比如依赖缺失、权限不足。多数时候是环境问题，先把工具链用容器化管理，能省很多时间。第五个问题是“报告数据不完整”，测试做完了，信息收集阶段的证据却找不全。这个要靠流程规范，每验证一个点就立刻截图存档。7.2 合规与边界：收集不等于越权信息收集是SRC流程中离“边界”最近的一个环节，因为主动扫描、目录枚举、接口探测本质上都在和目标系统交互。这里必须有一个清晰且不可逾越的底线：所有操作都只能作用于你获得授权、且明确写入项目范围的目标。任何超出范围的探测，哪怕只是扫描一个“看起来关联”的IP，都可能构成越权，这不是技术问题，是合规问题。另外还要注意数据最小化。信息收集阶段可能接触到目标系统中的敏感数据，比如测试账号、内部人员信息、客户信息。这些数据只能在项目范围内使用，不能留存超过必要时间，不能复制到个人设备上，更不能在工作交流群里传播。我自己的习惯是，每个项目结束之后，会专门清理一次本地缓存和备份文件，确保没有项目数据残留。这块意识要放到和技术同等重要的位置。7.3 收尾工作：证据固化与报告整理信息收集阶段结束之后，至少要输出三类成果。第一类是资产清单，包含所有确认过的域名、IP、指纹、归属状态，并标注哪些是核心资产、哪些是边缘资产。第二类是测试路线图，就是从所有收集结果中筛选出的下一步测试重点，每个重点都要写清楚理由。第三类是证据包，包括发现敏感信息时的截图、响应包、请求记录，按编号整理好。证据的规整程度直接影响后续漏洞报告的质量。我见过太多报名因为时间紧张、证据零散而显得不专业的情况。实操中我会给每个待测点建一个文件夹，里面放好描述、证据、请求包和处置建议。这些材料看起来只是信息收集的副产品，但等到项目结束或者需要回溯时，你就知道这套习惯有多重要了。最后聊几句写了这么多，最想传达的一个观点是：SRC信息收集的进阶，本质上是情报思维的进阶。工具永远是执行层的东西，真正值钱的是你拿到一堆原始数据之后，能不能把它们组织成有逻辑、有优先级、能指导行动的结构化情报。我自己早期也走过弯路，总以为收集得越多就越接近成功，结果大量时间浪费在无限扩大的信息海洋里。后来换了思路，每一次收集都带着明确问题去，比如“我想证明这个系统是否有配置不当”“我想判断这个域名是否值得深挖”“我想把这条线索扩成新的关联资产”，效率一下子提升了很多。信息收集不是一个体力活干完就结束的，它是一个需要不断回看、修正、沉淀的过程。希望这篇延续第一集的分享，能帮你少走一些我走过的弯路。