SRC漏洞挖掘实战：从资产规则到审核评级的完整指南

做安全这一行，最常被问的问题绕不开那句：“你们说的挖洞，到底怎么挖，真的能赚钱吗？”我发现每次回答这个问题，三两句话根本讲不清。最近整理自己在第176天阶段的安全学习笔记，把SRC挖掘这条线从头到尾串了一遍，正好是可以系统讲清楚的时候。这篇不是理论手册，是我实际踩过坑之后沉淀下来的思考，按照一条完整思路来：SRC是什么、资产规则该怎么看、审核评级到底怎么判、一条完整的挖掘链路怎么走，以及新手最常见的几个问题。文章偏web安全方向，也涵盖渗透测试常用思路，不管你是正在研究SRC挖掘、CNVD收录、EDU类专项资产，还是单纯想找一条合法的web安全进阶路线，这篇应该能帮你省不少时间。

1. 先搞清楚SRC挖掘到底在玩什么

1.1 SRC、众测平台、漏洞库收录：三个入口别混淆

SRC的全称是Security Response Center，也就是安全应急响应中心。可以把它理解成企业或机构对外开设的“漏洞信箱”。白帽子在授权范围内寻找他们还没发现的漏洞，提交之后由审核人员复现、定级，然后给你积分、奖金、礼品，或者一份圈内认可的荣誉编号。整个过程中最关键的一个词是“授权”。没有授权，再厉害的渗透测试技术也属于越界行为，这个底线必须刻在脑子里。

很多新人一开始容易把SRC、众测平台、CNVD这几样东西搅在一起，其实它们的定位有明显区别。厂商自建SRC是最常见的形态，比如某个互联网公司专门开一个漏洞收集入口，测试范围就是这家公司的资产。第三方众测平台则把多个SRC项目聚合在一起，白帽子注册之后可以自行选择参与哪个项目，补天、漏洞盒子这类平台就属于这个方向。CNVD可以理解为漏洞库收录体系，它所接收的不只是公司自家站点的漏洞，还涵盖通用软件、常见组件等目标，审核通过后会分配编号，后续可以凭编号获得证书，这类成果更多是行业认可和简历加分项。

EDU类专项项目是另一个值得单独拿出来说的存在。它是面向教育行业资产集合的漏洞收集项目，很多平台会把它单独划分一个分类。这类项目的特征是资产多、子系统多、历史包袱重，很多老网站跑了十几年，技术栈五花八门，对新手相对友好。但恰恰因为资产生命周期长、访问量大，就更需要严格遵守平台划定的资产规则，而不是看到一个学校相关域名就上去乱测。

1.2 通用事件和专属事件：提交类型别选错

在SRC或CNVD提交漏洞时，经常会遇到一个下拉选项：通用型漏洞、事件型漏洞，或者叫通用事件、专属事件。很多人第一次提交被驳回，不是漏洞不真实，而是提交类型选错了。

通用型漏洞指某个开源组件、通用软件、常见框架本身存在的漏洞，影响的不只是一个单独目标，而是所有正在使用它的站点。提交这类漏洞时，你需要在材料里写清楚漏洞原理、受影响版本范围、利用条件和修复建议，审核人员会判断这个漏洞是否具备通用性，是否值得收录到漏洞库。事件型漏洞则是针对特定站点、特定业务的具体问题，比如某个具体机构的门户网站存在一个SQL注入，影响范围就是这个单独站点。

选类型之前，花三分钟看看平台规则里的说明，比提交后等两周再审要划算得多。类型确定下来，其实也就决定了后续审核的着眼点：通用事件看技术深度和影响面，事件型看复现逻辑和危害真实性。

2. 资产规则是生命线，先读懂边界再动手

2.1 范围红线：不在列表里的资产一律不碰

SRC项目页面上都会有一块“资产范围”或者“测试范围”的区域，里面往往写着域名列表、IP段、App包名、小程序名称。有些平台还会额外标注“禁止测试列表”，把核心数据库、生产支付系统、第三方服务等标得清清楚楚。

我看到过不少人栽在范围问题上。有人觉得主域名下了个二级域名很接近，顺手测一下应该没问题；有人觉得IP段里多扫一个地址无所谓。结果审核不认，轻则漏洞作废白忙一场，重则被平台拉黑，账号都没了。规则里写明的范围，就是你能碰的范围，没有“顺便”“大概率算”这种说法。

实际操作中我会这样做：先把项目规则里所有域名整理成一个文档，把根域名、子域名、IP段分开记录。测试任何目标之前，先把URL核对一遍，确认它确实落在授权范围内。这个动作看起来麻烦，但能避免绝大多数合规风险。

2.2 域名、IP、小程序：资产形态不一样，打法也不一样

资产规则里常见的几种形态，对应的测试思路差异很大。

域名类资产最常见。规则会写明根域名是a.com，有时也会明确“包含所有子域名”。如果只写了根域名而没有注明子域名，稳妥起见，先测列表里明确给出的资产，或者通过规则里的“资产查询”功能确认一下。

IP段类资产在EDU类项目中比较多。直接给一个网段的情况，通常意味着授权范围覆盖了整个网段上的服务。这时候建议先用端口扫描找出开放的Web服务，再逐个确认业务功能，而不是一上来就对着全部端口乱打。

小程序和App也算常见资产。测试小程序可以抓包看请求的接口，验证接口是否存在越权、注入、逻辑漏洞。关键点在于，接口必须属于资产规则里的小程序业务链，不能顺着接口跳到别的无关系统。

2.3 资产重要性决定漏洞的含金量

同一类漏洞，出现在不同资产上，评级差别很大。一个只在活动页面上的反射型XSS，和一个能批量获取用户信息的业务系统上的SQL注入，完全不是一个量级。

判断一个漏洞值不值钱，不能只看漏洞类型，还要看它在什么位置、能接触到什么数据。比如一个管理后台的弱口令，如果后台只管理静态内容，那危害就很有限；如果是核心用户系统的后台，那评级会直接拉高。所以提交之前，先想清楚漏洞影响的是哪个业务、波及多少用户、能导致什么后果。影响面描述清楚了，审核人员才会把你的漏洞当回事。

3. 审核评级逻辑：为什么同一个洞，别人分比你高

3.1 危害等级是怎么评出来的

SRC审核评级很少只参考一个漏洞类型列表，它一般是多个维度叠加判断的：漏洞类型、资产重要性、利用前置条件、影响数据量、是否需要用户交互。举一个例子：登录前的SQL注入，和需要后台管理员权限才能触发的存储型XSS，哪个更严重？多数情况下是前者，因为它在未授权状态下就能直达数据库，危害面完全不同。

从个人经验看，高等级漏洞通常具备几个特征：无需特殊权限、可影响大量用户数据、利用过程稳定可复现、且修复成本高。中低等级漏洞则往往有条件限制，比如需要诱导用户点击、需要低权限账号配合、只能读取到非敏感信息。

这里整理一张经验参考表，实际标准以各平台规则为准：

3.2 报告质量决定漏洞价值

我见过太多新人把漏洞提交写成一句话：“存在sql注入，url是xxx，请尽快修复。”这种报告大概率会被低评，甚至直接忽略。审核人员一天要过几十上百个漏洞，他没有义务替你把危害分析补齐。

一份合格漏洞报告应该包含：标题、漏洞URL或接口、漏洞类型、危害等级建议、复现步骤、截图或录屏、影响范围描述、修复建议。标题要简短到一眼能看懂，比如“某业务登录接口存在SQL注入可脱库”；复现步骤要精确到用哪台电脑、打开哪个页面、输入什么参数、观察什么响应。

还有一个容易被忽略的点：截图要保留关键请求和响应。不要只截一个弹窗，要把URL、请求包、返回数据都放在一张图里。涉及敏感信息时记得脱敏打码，既证明危害，又不泄露真实数据。

3.3 被判忽略？先对照这五个原因自查

漏洞提交后被驳回，先别急着抱怨审核不专业，对照下面几个原因自查一遍：

重复提交是最大的浪费。测试之前先在平台已收录漏洞里搜一遍关键词，确认没有重合。超出资产范围，这个没什么好解释的，就是规则没读透。危害不成立也是常见情况，比如你以为的参数注入其实只是把内容拼到了邮件模板里，根本没有进入数据库；或者反射型XSS被CSP策略拦截，实际无法弹窗。无法复现经常出现在新手报告里，步骤写得含糊，审核照做之后没反应。报告不完整则是前面说的，信息量太少，审核没法判断。

每次提交被驳回，我都建议把驳回理由存进自己的笔记里，积累一段时间你会发现，那些反复出现的坑，其实就是你提升报告质量的关键点。

4. 一条完整的SRC挖掘链路：从信息收集到漏洞上报

4.1 信息收集：先搞清授权范围内有什么

真正开始挖洞之前，第一步是信息收集。目标很明确：授权范围内有哪些资产，哪些是活的，用什么技术栈，有哪些功能点。

子域名收集是第一个常用动作，主流方法包括证书透明度日志、搜索引擎语法、DNS字典爆破。拿到一批子域名后，再批量探测存活状态。这里贴一个常用命令组合：

bash复制# 示例：子域名收集后探测存活Web服务
subfinder -d example.com -silent | httpx -status-code -title -tech-detect

这条命令做了两件事：先用subfinder通过证书透明度等公开渠道收集example.com的子域名，再用httpx批量探测这些域名是否存活、返回状态码、页面标题和技术栈。在本地跑一遍，输出结果会比手动一个个访问高效很多。

指纹识别也是信息收集阶段必须做的一件事。通过响应头里的Server字段、页面特征、特定静态文件路径，判断目标使用的是什么CMS、什么中间件、什么框架。确定指纹之后，就能快速比对是否存在已知漏洞，缩小测试范围。

还有一个容易被忽略的信息源是JS文件。前端打包文件里经常藏着未公开接口、API路径，甚至注释里残留的账号信息和内网地址。把JS文件下载下来，搜一下api、token、admin、internal这类关键词，往往能有意外收获。

4.2 漏洞探测：常见的思考方向

信息收集完成后，会根据功能点梳理可操作面。下面这几个方向是我认为最值得新手花时间研究的：

输入点与输出点。凡是用户可控的数据进入后端，都有可能存在注入或XSS。遇到搜索框、登录框、留言板、文件上传点，先想想这个数据会被拼到哪里、在哪里展示、是否经过过滤。

权限与越权。尝试修改请求中的ID、订单号、用户名等参数，访问本不应该属于当前权限的数据。越权漏洞经常出现在接口层，前端隐藏了入口不代表后端做了权限校验。在授权范围内做越权测试时，我会用一个自己创建的测试账号操作，避免碰真实用户数据。

业务流程与逻辑漏洞。支付金额篡改、验证码绕过、密码重置流程被猜解、优惠券重复领取，这类逻辑漏洞往往比扫描器扫出来的SQL注入更有价值，也更能体现报告者的分析能力。

还要提一点，不建议一上来就开全自动扫描器。扫描器的误报率在SRC审核眼里非常影响印象分，而且大量扫描流量会给目标造成不必要的压力。更合理的做法是先用浏览器把核心功能点手动走一遍，再用工具做补充验证。手动测试发现的逻辑漏洞，通常比扫描器自动跑出来的结果更有说服力。

4.3 复现验证：不是“能弹窗”就完事

确认了一个漏洞后，别急着截图上报。我会反复验证三次以上：换个浏览器试试，重开会话再试一次，重新走一遍完整流程。原因很简单，如果审核人员也复现不出来，这个漏洞基本就白提交了。

验证过程中有一个必须遵守的原则：绝不动真实用户数据。不翻别人的订单，不下载全量数据，不修改他人密码。这些行为已经不是漏洞测试，而是实打实的违规操作。我在调越权漏洞时只用自己的两个测试账号互相验证，确认能访问到“另一个账号的数据”就停下来记录。

截图的时候要保留关键请求和响应，URL里涉及个人身份的部分打马赛克。平台要求提供payload时，给一个能稳定复现的最小请求，不要贴一长串自动化脚本。测试过程中产生的临时数据要清理干净，不删目标数据、不留后门、不做横向移动。这些都是最基本的职业操守，也是每个白帽子应该守住的底线。

5. 效率工具与学习路径：新手怎么少走弯路

5.1 工具不用贪多，先掌握三件套

经常看到新人电脑里装了上百个安全工具，每个都会跑两步，但没有一个能讲清楚原理。这其实是在用工具数量掩盖知识空缺。SRC挖掘真正高频使用的工具没有那么多。

BurpSuite是绕不开的抓包改包工具，用来观察和修改HTTP请求，测试参数变化、重放请求都靠它，必须熟练。浏览器开发者工具也极其重要，很多前端调试、请求分析、JS查看都可以直接在浏览器里完成。再加上子域名收集和存活探测的命令行工具组合，就已经覆盖了绝大多数场景。

抓包工具本身能修改请求，但请记住一句原则：目标不在授权范围内，就不应该发起任何探测数据包。工具的能力越强，越需要规则意识约束。

5.2 学习路径怎么排效率最高

我的建议是先学HTTP协议，再学前端基础，包括HTML、JS、请求和响应结构，然后补SQL基础和数据库概念，最后才开始啃漏洞原理。顺序反了也能学，但效率会低不少。很多人一上来就背各种exp，连POST和GET的区别都说不太清，这类地基不牢的问题，后期会反复回来找麻烦。

打靶场是很好的合法练习环境。DVWA、pikachu、sql-labs、upload-labs这些经典项目都可以在本地搭建。本地靶场的好处是想怎么测就怎么测，不用担心合规问题，而且能清楚看到每一个漏洞背后的代码逻辑。反复打，打到不需要看writeup就能讲清楚原理，比刷一百个视频都有用。

本地打熟了以后，再去正规SRC平台注册账号，在规则明确允许的小目标上练手。一开始可能连漏洞影子都摸不到，这是正常的。先找边缘系统，从信息收集开始跑通整个流程，再慢慢追求高价值漏洞。

我也注意到现在有人开始尝试用AI辅助渗透测试，自动生成测试用例、分析响应包，确实能提升一部分效率。但SRC审核很看重可复现性，AI生成的结论只能当辅助参考，不能直接作为漏洞证据。工具是放大器，核心还是你对web安全底层逻辑的理解。

6. 高频问题与经验速查：审核、收益、心态一起说

6.1 审核周期：为什么有的快有的慢

新人对审核周期最敏感，尤其是EDU类项目里，经常听到有人问“edu的src审核要多久”。实际体验下来，不同平台差异很大。快的当天就有结论，慢的可能要两到四周，取决于审核员排期、漏洞复杂度、报告是否清晰。

如果超过一个月没有动静，可以看看平台有没有催办或反馈入口，礼貌询问进度。但切忌反复提交同一个漏洞，系统判定重复之后，反而会影响你在平台上的信任度。提交记录里的状态本身就是信息，多留意状态变化比干着急有用。

6.2 收益预期：可以赚零花钱，但别指望暴富

SRC挖掘的收益，说实话很看运气和积累。同一个SRC项目，严重漏洞可能给几千到几万不等的奖励，而EDU类专项很多是积分、证书、礼品为主，现金相对少。把SRC挖掘当作快速致富渠道，大概率会失望。它更适合作为技术进阶和简历背书的路径，慢慢积累，收益会随着能力增长而变好。

从我自己的经历看，第1天和第176天之间真正的变化，不在于某天突然挖到一个高危，而在于日复一日把“看到URL、判断功能、排查输入点、验证影响”这条链路练成了肌肉记忆。漏洞挖掘是概率游戏，更是手艺活。

最后再说一个个人习惯：拿到新项目之后，我会先把资产规则从头到尾读三遍再动手。这不是保守，是珍惜自己的测试资格。SRC平台每天有大量自动化工具在跑，审核员最怕的就是搞不清你测的是不是授权范围之内的东西。规则内平推思路，规则外坚决不碰，这个底线守住了，后面的挖掘工作才有持续的可能。第176天笔记大概就记到这里，web安全和渗透测试这条线，我还会继续往深推。