1. 先搞清楚SRC到底在玩什么：从平台规则到漏洞定价的一场"寻宝游戏"
很多人第一次听说SRC，第一反应是"是不是像CTF一样打靶场"。我可以直接告诉你，差得很远。CTF是一场有标准答案的开卷考试，SRC是在真实业务系统上做安全测试——没有标准答案，没有固定路径，甚至很多时候目标系统本身就是一个"千疮百孔"的旧项目，能不能找到洞、找到什么级别的洞，全看你的思路和运气。
用一个更贴切的比喻：SRC漏洞挖掘更像是"寻宝"，每个目标系统就是一座藏宝的庄园，庄园主人（厂商）会贴出一张告示，告诉你哪些角落是禁区（越权、核心数据），哪些宝贝值钱（高危漏洞、严重漏洞），哪些小玩意也收（低危问题、文案错误）。你要做的，就是在不破坏庄园的前提下，找到那些藏在角落里、别人没发现的"值钱玩意"。
1.1 厂商收洞逻辑：为什么有些低危漏洞也能给钱
先理解厂商的逻辑，这决定了你接下来的所有时间花在哪里。SRC的核心玩法是"漏洞定级"——每个漏洞提交上去，厂商会按照危害程度评一个等级，常见的是严重、高危、中危、低危四个级别，对应不同的积分和奖金。
这里有个新手最容易忽视的点：漏洞等级不完全取决于技术上的"危害"，而取决于这个漏洞在厂商眼里"值多少"。举个例子，一个反射型XSS，如果打在某个边缘业务上，可能只算低危；但如果打在那个业务系统的管理员登录页上，有可能会被定到中危甚至高危。同样的漏洞，不同的平台、不同的业务线，定价完全不同。
所以，入行第一课不是学技术，是花半天时间把目标平台的SRC规则、过往漏洞公告、历史榜单看上几轮，搞清楚哪些方向是"高产地段"。
1.2 新手选平台：别一上来就硬啃大头厂
选平台是个策略问题。头部大厂的SRC，资产庞大、防护严密、监控到处都有，新手过去大概率碰壁，提交的漏洞要么严重重复，要么被判定为"已知问题"直接忽略。我更推荐从三类平台入手：
第一类是正在快速扩张业务的中型互联网公司SRC，这类厂商资产多、安全团队人手不足，防护相对薄弱，出洞概率高。第二类是常年有众测项目或漏洞奖励计划的教育、医疗、政务类平台，功能单一但逻辑漏洞多。第三类是基础安全厂商自家的SRC，这些厂商为了打磨产品会非常认真审核漏洞，适合想深入了解漏洞原理的人。
选定平台之后，老老实实把目标范围画清楚。很多平台有个"授权范围"页面，里面写了哪些域名、哪些IP、哪些业务可以打，范围外的一律不能动。这条红线碰一次，轻则封号，重则有什么后果我就不多说了，圈子里有太多前车之鉴。
2. 信息收集才是真正的内功：资产梳理和攻击面扩展
不管在哪个SRC挖洞，前期信息收集的质量直接决定了你后面出洞的概率。我见过太多人，拿到一个域名就开始盲测，结果测了半天发现测的是CDN节点，真实源站在后面毫发无损，白白浪费时间。
2.1 从根域名到子域名的资产测绘
拿一个目标举例。假设你选了一家做教育信息化的中型厂商，SRC授权范围内给了主域名example-edu.com，这时候你该做什么？不是直接开扫，而是先把这个域名相关的所有资产摸清楚。
第一步是子域名收集。用被动收集的方式，把目标域名的所有子域名先捞一遍，像是证书透明度日志查询、DNS历史记录、搜索引擎收录的子域名，把结果先去重、再解析，看它解析到了哪些IP段。这里要特别留意的三类子域名：测试环境域名（常见前缀有test、dev、beta、pre、uat、staging），旧版本域名（v1、v2、old、backup），以及运维管理域名（admin、manage、ops、grafana、zabbix、jenkins）。
这三类为什么值钱？因为它们的防护等级往往比主站低好几个档次。测试环境经常直接挂着调试接口和默认口令，旧版本业务经常带着一堆历史遗留漏洞，运维管理后台一旦暴露弱口令，那就直接是一串高危洞。
第二步是端口和指纹识别。拿到所有解析出来的IP之后，做全端口扫描，重点关注非常规端口上的Web服务——比如8080、8888、7001、9200、9090。9200是Elasticsearch的默认端口，如果直接裸奔在外面，那基本就是送分题；7001是WebLogic的默认端口，历年爆过多少反序列化漏洞，不用我多说了。
2.2 JS文件分析：被大多数人忽略的信息金矿
前端JavaScript文件是信息收集阶段性价比最高的目标之一。现代Web应用基本都会打包一堆JS文件，里面经常硬编码了API接口路径、内网IP地址、OSS存储桶名、AccessKey的前缀、甚至是调试用的token。
我习惯的做法是：全站爬取一遍JS文件，然后做两件事。第一，提取所有接口路径，拼接成完整的URL列表，看哪些接口直接返回了JSON数据——这些接口里经常藏着未授权访问；第二，搜索敏感关键字，比如secret、token、accessKey、password、innerIP、debug，把命中结果一个个点开看。
有一次，我就是从一个不起眼的JS文件里翻出了一个内网接口地址，拼接路径后发现该接口未做鉴权，直接返回了全量用户手机号和邮箱。类似这种漏洞在报告里定级至少中危，好一点的能给到高危。
2.3 别忽略WAF识别和指纹识别
做信息收集的时候，顺手把目标站点的WAF情况也摸清楚。判断有没有WAF，最简单的方法是看响应头，X-Sec-FS、X-WA-Info这类头基本就是有WAF在中间挡着；更直接的办法是往URL里丢一个/?id=1'，看返回的拦截页面像不像某种安全产品的拦截特征。
确认WAF存在之后，后面测试的payload就要做编码绕过、大小写混写、注释符拆分等处理。也别忘了识别中间件和框架版本。Nginx、Apache、IIS、Tomcat大类要分清，Spring Boot、ThinkPHP、Struts2、Shiro这些框架的已知漏洞CVE，都是现成的洞——前提是版本对得上。
3. 漏洞类型的优先级排序：先打最容易出洞的赛道
信息收集做完，进入正式的漏洞挖掘阶段。SRC挖掘这么多年下来，我总结了一条经验：逻辑漏洞和越权漏洞是绝大多数新手最容易出成绩的方向，因为这类漏洞跟技术栈无关，跟业务逻辑强相关。
3.1 越权漏洞：一个ID引发的"血案"
越权漏洞的核心原因就一句话：服务端只校验了"是否登录"，没校验"这个数据是不是属于当前用户"。最常见的场景是水平越权——用户A能查看、修改、删除用户B的数据。
测试方法其实很简单：登录两个不同账号，用账号A的正常操作抓包，把请求里的用户ID、订单号、手机号、文件ID这些标识参数替换成账号B的，看返回结果是否包含账号B的数据。这一步在Burp Suite里用替换参数重放就可以完成，关键是测试要覆盖所有带ID参数的接口，不止是页面上能看到的。
我见过一个典型案例：某平台有一个"查看我的收货地址"接口，请求里的地址ID是连续的整数，把ID改成任意数字就能看到别人的详细收货地址——姓名、手机号、门牌号全在上面。这种漏洞定级直接高危，因为它涉及大量用户隐私。
3.2 逻辑漏洞：流程设计缺陷才是大户
逻辑漏洞比越权更"高级"一点，它不局限于参数，而是整个业务流程的设计缺陷。常见的类型包括：验证码不失效、密码重置流程绕过、支付金额篡改、优惠券重复使用、短信轰炸、以及各种"先操作后校验"的时序问题。
测逻辑漏洞的正确姿势是"逆向思考"。你是用户的时候，正常流程是注册→登录→下单→支付→完成。你要做的是在每一环节之间插入"异常操作"：跳过某一步、重复某一步、篡改某一步的参数、把某一步的请求重放多遍。
举一个我自己挖到的例子。某零售平台的优惠券系统，每张券限领一张，前端也确实只能领一次。但领券请求是一个POST接口，我直接把同样的请求用Burp的Repeater重放了5次，结果系统发了5张同样的券给我。虽然每张券面额不大，但叠加到支付环节就是典型的逻辑漏洞，报告提交后定级中危。
3.3 信息泄露：送上门的低垂果实
信息泄露是SRC中被严重低估的漏洞类型。很多人觉得泄露点信息无所谓，但厂商和审核员很看重"信息敏感度"。GitHub上泄露的源码、接口返回中多余的字段、目录遍历暴露的备份文件、错误页面里打印的SQL语句和绝对路径，这些都算。
最恶心的是目录扫描扫出后台备份文件，比如wwwroot.zip、site_backup.tar.gz、.git目录可访问，这些基本是直接拿到源码或数据库配置，运气好还能连上数据库。我建议新手在扫目录的时候把常见备份文件后缀名列表准备齐全，zip、tar.gz、sql、bak、old、swp各来一梭子，一个扫描命令下去，点开结果看有没有"惊喜"。
3.4 经典漏洞类型怎么兼着打
上面三条赛道是效率最高的，但你的知识面不能只有这三条。SQL注入、XSS、SSRF、文件上传、反序列化这些经典漏洞类型也该常备题库，遇到对应的中间件或框架版本直接上手测。投入产出比最高的做法是：逻辑漏洞、越权、信息泄露作为主攻方向，经典Web漏洞作为"遇到才打"的辅助方向。警惕一句话：别在低价值目标上花重炮，你的时间很值钱。
4. 从零到一的完整挖掘实例：某小厂商SRC的实战过程还原
前面讲的都是方法论，这一节我完整走一遍实战流程，让大家看看一个洞是怎么被"摸"出来的。这个案例发生在某做企业服务的厂商SRC上，授权范围明确，无敏感数据公开，只是单纯地走一遍思路。
4.1 定目标：从一个不起眼的子域名开始
当时我拿到了该厂商的资产列表，主域名下挂了十几个子域名。按照前面说的方法，我先用被动收集把子域名全部拉出来，比对授权范围，锁定了其中一个疑似新上线业务的子域名newservice.example-corp.com。这个域名没什么流量、没什么收录，看起来是刚部署的，而且回应头里显示服务器是某个老版本中间件。
我先做了两步快速验证：第一步，用目录扫描工具跑了一遍常见路径，结果扫出来根目录下有个/actuator路径返回了200；第二步，直接访问/actuator/health，返回了一段JSON，说明这是一个Spring Boot应用，而且Actuator管理端点暴露了。
这里插一句：Spring Boot的Actuator端点要是全部暴露，那可比单纯一个目录暴露严重多了。/actuator/env可能包含数据库连接信息，/actuator/heapdump可以直接下载JVM堆内存文件，里面往往能翻出各种密钥和token。
4.2 深入：从heapdump里翻出的"钥匙"
我继续访问/actuator/heapdump，发现竟然真的可以直接下载堆转储文件。文件不大，也就几十MB，我把它下载下来，用解析工具加载之后搜索关键字。我先搜的是password、secret、token这些通用关键词，结果没搜到明显的数据库密码，但在某个对象里发现了一串不太起眼的字符串。
这串字符串最终确认是OSS存储桶的AccessKey和SecretKey。有了这对钥匙，意味着我可以直接操作这家厂商的云存储，包括读取、上传、删除对象。接下来的事情就简单了：我用云存储客户端工具连接上去，看到里面存储着大量业务Excel和PDF文件，随意下载了一个确认能读取内容，并拍照留存。
4.3 收尾：验证危害、截图、写报告
我没有继续做越权操作，这是原则问题。确认能读取文件内容，危害已经足够清晰之后，我把请求包、访问路径、下载的文件截图全部整理好，按SRC平台的报告模板填写提交。审核员复现之后，直接定级高危。
这个案例复盘下来，真正"值钱"的步骤其实是最开始那个子域名收集和目录扫描——如果没有找到/actuator端点，后面的一切都不会发生。这个洞的技术难度是0，甚至不需要任何payload，全程就是"点链接、看页面"，但它的危害却实打实是高危。这就是SRC和CTF最大的不同：在SRC里，信息就是漏洞。
5. 报告撰写的门道：漏洞挖到了，别因为报告白干
很多人漏洞挖到了，结果报告写得稀烂，审核员看不懂复现步骤，来回沟通好几轮，最后一句"无法复现"直接给你打回来。这种亏我吃过不止一次，写报告真的值得认真对待。
5.1 一份合格报告的四要素
第一，漏洞描述要精确。不要写"某页面存在XSS"，要写"某页面某参数存在反射型XSS，当输入特殊构造的payload时，该参数原样输出至页面且未经过滤或转义"。审核员一天要看几十份报告，你要让他第一眼就知道问题出在哪。
第二，复现步骤要像"做菜教程"一样详细。第一步访问哪个URL，第二步输入什么内容，第三步点击什么按钮，第四步看到什么结果。每一步要配上截图，关键请求包用文字粘贴进去。这里的原则是：审核员不需要"思考"就能复现你的操作。
第三，危害说明要讲人话。技术细节之外，要写清楚这个漏洞"能让攻击者做什么"，比如"攻击者可利用该越权漏洞读取任意用户的身份证信息，造成大规模个人信息泄露"。最好附上一条简单的影响链路：攻击者→调接口→换ID→拿数据。
第四，修复建议要靠谱。不要只写一句"建议修复"，而是给出具体方案，比如"建议在服务端对用户请求中的ID参数与当前登录用户进行归属校验；建议对Actuator端点增加鉴权或直接在生产环境关闭"。靠谱的修复建议能提升审核员对你的评价，也方便后续合作。
5.2 与厂商沟通的三个心态
报告提交之后，你会经历审核、定级、可能出现的驳回和补充。整个沟通环节里，我建议保持三个心态：
第一，被驳回不一定是坏事。审核员说"无法复现"，可能是你写得不够清楚，也可能是他复现环境有问题。这时候别急，重新梳理步骤，补上更完整的截图和请求包，礼貌地请求重新审核。第二，定级不满意可以申诉。如果同一个漏洞不同平台或同平台不同审核员定级偏差过大，可以友好地提出申诉理由，引据同平台之前的漏洞公告作为对标。第三，不要泄露授权范围之外的任何信息。哪怕你测试的时候手滑看到了别的数据，报告里也一定要用脱敏方式展示，否则会给自己惹麻烦。
6. 容易被忽略的坑：重复漏洞、无效测试与合规红线
最后聊几个新手几乎都会踩的坑，提前说清楚，能帮你少走至少三个月的弯路。
6.1 重复漏洞是SRC的"沉默杀手"
SRC和漏洞众测最大的区别是：你提交的时候，可能已经有别的人先提交过一模一样的漏洞了。平台只认第一个提交者，后面提交的全部算"重复漏洞"，不计积分。
降低重复率有几个方法：第一，别测那些明显的、低垂的果实——比如首页SQL报错、登录框万能密码，这些早被人测穿了。第二，优先测冷门业务和新上线的功能模块，这些区域其他白帽还没顾上。第三，盯住信息收集阶段发现的非主流接口和参数，越偏门重复率越低。
6.2 别拿扫描器全梭哈
扫描器是效率工具，不是无脑工具。很多新手一上来就丢一整站的目录扫描，把目标站点扫得千疮百孔、响应缓慢，可能触发了厂商的熔断机制，被对方安全团队拉黑。更重要的是，大流量扫描很容易被判定为恶意攻击行为。
我自己的习惯是：目录扫描只跑一次，使用低线程、加延时、限定在深夜执行；漏洞扫描只用特定畸形请求，不做大范围Fuzz。遇到疑似WAF的站点，手动测试优先于自动扫描。
6.3 红线行为的边界，务必刻在脑子里
SRC授权范围内的测试是合法的，但越界就是另一回事了。有三个绝对不碰的行为：第一，不碰授权范围之外的任何系统、端口、域名——哪怕是同一家厂商的，不在列表里就不能碰。第二，不下载、不传播、不改动业务真实数据，看到数据要脱敏，绝不把敏感信息截图发到公共平台。第三，不对目标系统实施任何破坏性攻击，比如删库、批量注销用户、爆破后台管理员密码成功后又登录进去等。
合规的规则每一条都是用前人的教训换来的。你在SRC这条路上能走多远，技术只是一部分，更重要的是一以贯之的克制和边界感。
6.4 我的最后一条学习建议
回头看，零基础入坑SRC最有效的一条路径是：先花一周把信息收集工具链跑熟，再花两周在主攻方向上做系统性的手动测试练习，第三周开始实际提交第一个漏洞。不要沉迷于攒一堆工具，不要一上来就追求"挖到严重漏洞"，先把小洞一个个交起来，摸清平台的审核尺度和口味，后面自然会越挖越顺。
这篇文章写到这里，核心的思路、流程、坑点已经都铺开了。最后再分享一个小技巧：每次提交漏洞之后，不管有没有通过，都花十分钟复盘一遍——"这个洞为什么能找到？中间哪个环节是最关键的？如果重来一次怎么更快？"把这些复盘记在一个文档里，三个月后再看，那才是你真正的成长记录。
