SRC漏洞挖掘实战指南：从信息收集到报告撰写的完整流程

1. 项目概述：从零开始理解SRC漏洞挖掘

最近几年，网络安全领域一个绕不开的话题就是SRC，也就是安全应急响应中心。很多朋友，无论是刚毕业的学生，还是想拓展技能的在职人士，都对这个方向产生了浓厚兴趣。原因很简单，它看起来像是一个能结合技术、兴趣和实际收益的“副业”选择。但说实话，网上很多资料要么过于零散，要么就是“秀操作”的截图，对于真正想入门的人来说，看完还是一头雾水，不知道从哪里下手。

我接触SRC漏洞挖掘也有些年头了，从最初提交一个低危漏洞都兴奋半天，到后来能稳定产出一些有质量的报告，中间踩过的坑、走过的弯路不计其数。这篇文章，我就想把这些年积累下来的、最核心的思路和手法，用最直白的方式梳理出来。我的目标不是给你一堆高深莫测的“炫技”案例，而是帮你搭建一个从零到一、再到精通的系统性框架。你会发现，漏洞挖掘并非玄学，它是一套有迹可循的工程方法。只要你按照正确的路径去学习和实践，完全可以从一个“脚本小子”成长为一名具备独立思考能力的白帽子。

那么，SRC漏洞挖掘到底是什么？简单说，就是安全研究人员（白帽子）在厂商授权的范围内，主动去发现其网站、APP、小程序、API等产品中存在的安全漏洞，并按照规范提交给厂商的SRC平台。厂商确认后，会根据漏洞的危害程度给予相应的积分、奖金或礼品作为感谢。这个过程，既帮助了企业提升安全性，也锻炼了研究者的实战能力，还可能获得物质回报，形成了一个多赢的局面。对于初学者而言，SRC提供了一个相对安全、合法的“练兵场”，是踏入网络安全实战大门绝佳的敲门砖。

2. 核心思路拆解：从“乱枪打鸟”到“精准狩猎”

很多新手一上来就打开扫描器，对着目标一顿狂扫，结果要么一无所获，要么扫出一堆误报和无关紧要的信息泄露，这就是典型的“乱枪打鸟”。高效的漏洞挖掘，核心在于思路的转变：从被动地等待工具输出结果，转变为主动地分析目标、理解业务、预测风险点。下面我拆解几个最核心的思路层。

2.1 目标资产梳理与攻击面测绘

在动手之前，你必须先知道“靶子”有多大。这里的资产远不止一个主域名。

2.1.1 子域名枚举与发现 这是信息收集的基石。一个大型互联网公司，其业务可能分散在数十甚至数百个子域名上。常用的方法包括：

• 字典爆破 ：使用 subfinder 、 ksubdomain 等工具，配合强大的子域名字典进行枚举。字典的质量直接决定发现的广度，需要自己长期积累和更新。
• 证书透明度日志 ：利用 crt.sh 、 censys 等平台，通过搜索域名关联的SSL证书，可以发现很多未在常规DNS记录中的子域名。
• 搜索引擎语法 ：使用 site:*.target.com 等语法在Google、Shodan、Fofa、ZoomEye等网络空间测绘引擎中搜索。
• DNS记录查询 ：检查域名的A、CNAME、MX、TXT等记录，有时能发现隐藏的后台或第三方服务地址。

注意 ：收集到的子域名列表需要去重和验证存活。可以使用 httpx 或 nuclei 的 -silent 模式快速探测HTTP/HTTPS服务，并初步识别Web服务器、框架、中间件等信息，为后续分析做准备。

2.1.2 端口与服务识别 一个IP上可能开放多个端口，运行着不同的服务（Web、数据库、缓存、RPC等）。使用 nmap 或 masscan 进行端口扫描，再结合 nmap -sV 进行服务版本探测。重点关注：

• 非常规端口上的Web服务 ：如8080, 8443, 9000等端口运行的Web管理界面。
• 老旧或有已知漏洞的服务版本 ：比如Struts2、Fastjson、Log4j2等组件的历史版本。
• 测试/开发环境服务 ：如Jenkins (8080), Docker Registry (5000), Redis (6379未授权访问)，这些往往是安全薄弱环节。

2.1.3 目录与文件探测 针对Web应用，使用 dirsearch 、 gobuster 、 ffuf 等工具进行目录和敏感文件扫描。目标不仅是找到后台登录页 ( /admin , /manage )，更要寻找：

• 源代码泄露 ： .git/ , .svn/ , .DS_Store 文件。
• 配置文件 ： config.php , application.yml , web.config 备份文件( .bak , .swp , .old )。
• 接口文档 ： /swagger-ui.html , /api-docs , /v2/api-docs 。
• 测试文件 ： /test , /phpinfo.php 。

这个阶段的目标是绘制一张尽可能完整的目标“地图”，并标记出所有可能的人口（入口点）和薄弱点（老旧服务、暴露的敏感信息）。

2.2 漏洞类型与攻击手法矩阵

有了攻击面地图，下一步就是针对不同的“地形”选择合适的“武器”。你需要建立一个自己的漏洞类型-检测手法矩阵。下面这个表格是我个人常用的一个简化版心智模型：

这个矩阵的意义在于，当你面对一个具体的功能点时（比如一个用户资料更新API），你可以快速在脑海里过一遍：这里有没有注入点？参数是否可能导致XSS？修改用户ID能否越权？响应里有没有泄露其他用户信息？调用的是什么组件，有无已知漏洞？这种系统性的思考方式，能极大提升测试的覆盖率和深度。

2.3 漏洞挖掘的核心心法：深度与广度的权衡

这是区分普通测试者和优秀研究者的关键。广度是指你能快速覆盖大量的目标点和漏洞类型；深度是指你能在一个点上持续钻研，发现复杂的、链式的高级漏洞。

对于新手，我建议 “先广度，后深度” 。

1. 初期（广度优先） ：使用自动化工具（如Nuclei配合大量模板）对大量目标进行浅层扫描，目标是快速发现“低垂的果实”，比如明显的信息泄露、默认口令、已知的组件漏洞。这能快速建立信心，熟悉流程。
2. 中期（深度探索） ：选择一个或几个重点目标，进行手工深度测试。关闭扫描器，像普通用户一样使用它的每一个功能，用Burp Suite记录所有请求，然后逐个参数、逐个功能点进行上面矩阵中的思考与测试。尝试理解业务逻辑，寻找工具发现不了的逻辑漏洞。
3. 后期（广度与深度结合） ：形成自己的方法论。对常见漏洞类型有自动化脚本或高效的手工测试流程（广度），同时对特定复杂场景（如OAuth授权流程、WebSocket通信、GraphQL接口）有深入的研究和专项测试方案（深度）。

3. 实战手法详解：一套可复现的漏洞挖掘流程

理论说再多，不如一次实战。下面我以一个虚构的“某电商平台”为例，展示一套从信息收集到漏洞提交的完整流程。请注意，所有操作均在获得授权的测试环境或合法SRC目标上进行。

3.1 第一阶段：高效信息收集与目标锁定

假设目标是 shop.example.com 。

1. 子域名枚举 ：

   subfinder -d shop.example.com -silent | httpx -silent -title -status-code -tech-detect -o subdomains.txt
   

   这条命令组合了子域名发现和存活探测，并获取标题、状态码和技术栈。输出文件里，你可能会发现 admin.shop.example.com (后台)、 api.shop.example.com (接口)、 dev.shop.example.com (开发环境) 等关键资产。

2. 端口与服务扫描 ：

   nmap -sV --script=vuln -p- -oA nmap_full api.shop.example.com
   

   对关键的API域名进行全端口扫描和版本探测，并运行漏洞脚本。可能会发现其运行在 8080 端口的 Spring Boot Actuator 管理端点。

3. Web目录扫描 ：

   dirsearch -u https://shop.example.com -e php,asp,aspx,jsp,html,js -w /path/to/big_dict.txt -t 50
   

   针对主站进行目录爆破。重点关注 /admin 、 /upload 、 /api/v1 等目录。

4. JS文件分析 ： 手动浏览网站，用浏览器开发者工具的“Sources”面板或使用 LinkFinder 这类工具，分析JS文件。常常能找到未文档化的API端点、API密钥、内部域名。

   python3 linkfinder.py -i https://shop.example.com/static/main.js -o cli
   

实操心得 ：信息收集阶段不要贪多求全，而要追求“精准”。对于大型目标，优先关注新上线的业务、二级域名、API接口和移动端H5页面，这些往往是安全防护的盲区，漏洞密度更高。

3.2 第二阶段：手工测试与漏洞验证

信息收集后，我们假设发现了几个有趣的点：一个用户订单查询API ( /api/order/list )， 一个商品评论提交功能，以及一个暴露的 Spring Boot Actuator 端点。

3.2.1 测试订单API越权

1. 用账号A登录，抓取查看自己订单的请求： GET /api/order/list?userId=12345 。
2. 将请求中的 userId 参数修改为账号B的ID（比如 67890 ），重放请求。
3. 观察结果 ：
   • 如果返回了账号B的订单信息，则存在 水平越权 漏洞。
   • 如果返回“无权访问”，则尝试在请求头或Cookie中寻找类似 X-User-Id 、 user_id 的字段，修改它们并重试。
   • 尝试直接访问 /api/order/list 不带参数，看是否默认返回当前用户订单。如果可以，尝试访问 /api/order/list?userId=all 或 /api/order/list?userId=* ，看是否能遍历所有订单。

3.2.2 测试商品评论存储型XSS

1. 在商品评论框内，不直接输入 <script> ，因为前端可能有过滤。先输入一段普通文本，如“测试评论”。
2. 用Burp Suite拦截提交的POST请求，将评论内容参数（如 content ）的值修改为精心构造的Payload： <img src=x onerror=alert(document.domain)> 。
3. 提交后，查看评论页面。如果弹窗显示 shop.example.com ，则证明存在存储型XSS。更隐蔽的测试可以使用 <svg onload=alert(1)> 或利用事件属性。

3.2.3 测试Actuator端点信息泄露与RCE

1. 访问 http://api.shop.example.com:8080/actuator ，查看暴露的端点列表。
2. 重点关注 /actuator/env (环境变量，可能泄露数据库密码、API密钥)、 /actuator/heapdump (内存转储，可分析敏感数据)、 /actuator/loggers (动态修改日志级别)。
3. 如果发现 /actuator/gateway/routes 等端点，且版本匹配，可尝试利用CVE-2022-22947等漏洞进行RCE。 （注意：此步骤仅用于原理讲解，实际利用需极度谨慎，且必须在授权范围内）

重要提示 ：在SRC挖掘中，对于RCE、SQL注入等高风险漏洞的验证，务必使用“无害化”的Payload。例如，SQL注入用 sleep(5) 而非 drop table ；命令注入用 ping 或 sleep 命令而非 rm -rf 。你的目的是证明漏洞存在，而非造成破坏。

3.3 第三阶段：漏洞报告撰写与提交

一份优秀的漏洞报告是获得认可的关键。它需要清晰、完整、可复现。

3.3.1 报告必备要素

1. 漏洞标题 ：精炼概括。如“【高危】shop.example.com 订单查询API水平越权漏洞导致任意用户订单信息泄露”。
2. 漏洞等级 ：参考目标SRC的定级标准，通常分为严重、高危、中危、低危。
3. 漏洞类型 ：越权访问、SQL注入等。
4. 影响URL ：完整的漏洞触发地址。
5. 漏洞描述 ：用文字说明漏洞点、产生原因及潜在影响。
6. 复现步骤 ：按1、2、3...列出详细操作，像教程一样让审核人员能完全复现。包括测试账号（如有）、每一步的请求和响应。
7. 请求与响应数据 ：粘贴原始的HTTP请求和响应包（可用Burp的 Copy as curl command 或 Copy to file 功能），关键部分可高亮。
8. 漏洞证明 ：截图或视频。截图需包含浏览器地址栏、请求响应关键信息。
9. 修复建议 ：给出具体的修复方案，如“对用户ID进行服务端会话校验”、“对输入参数进行严格的类型检查和过滤”。

3.3.2 提升报告通过率的技巧

• 一洞一报 ：一个报告只描述一个明确的漏洞点。不要把多个无关的发现塞在一起。
• 证据确凿 ：复现步骤必须100%成功。模糊的、概率性的问题很难被确认。
• 遵守范围 ：严格在SRC公布的测试范围内活动，不要测试未授权的业务、第三方服务或进行DDoS、暴力破解等攻击。
• 沟通态度 ：如果审核人员对漏洞有疑问，耐心、专业地补充说明。良好的沟通能解决很多问题。

4. 进阶技巧与深度挖掘策略

当你掌握了基础手法并能稳定产出中低危漏洞后，下一步就是向高阶迈进，挖掘那些更隐蔽、危害更大的漏洞。

4.1 业务逻辑漏洞的深度挖掘

这是最能体现技术深度的领域，完全依赖对业务的理解和创造性思维。

• 平行权限绕过 ：不止于修改ID。例如，在“修改收货地址”功能中，拦截请求，将地址ID改为他人的，看是否能成功修改别人的地址。或者，在“申请售后”时，修改订单号为一个不属于自己的订单。
• 流程顺序绕过 ：例如，一个抽奖活动需要先完成A任务，再完成B任务才能抽奖。能否直接调用抽奖接口？或者，支付流程是“生成订单->支付->回调确认”。能否在“生成订单”后，不支付，直接伪造一个“支付成功”的回调请求发给服务器？
• 条件竞争漏洞 ：多见于并发场景。比如，兑换优惠券时，余额检查和使用扣款不是原子操作。快速并发发送多个兑换请求，可能导致一张优惠券被兑换多次，或者余额被扣成负数。使用Burp Suite的 Turbo Intruder 或自己编写Python多线程脚本进行测试。
• 参数污染与篡改 ：关注所有客户端可控的参数，特别是那些影响价格、数量、状态的参数。例如，在购物车中将商品数量改为负数，总价是否变成负数？提交订单时，将商品单价改为0.01元？将优惠券的“满100减10”的“100”改为“1”？

4.2 新型技术栈与接口的专项测试

随着技术发展，新的攻击面不断出现。

• GraphQL API测试 ：GraphQL接口通常只有一个端点（如 /graphql ）。使用 InQL (Burp插件) 或 GraphQLmap 来探测其架构。测试重点包括： 内省查询 （通过 __schema 获取全部数据类型和字段）、 批量查询攻击 （通过别名发送大量查询耗尽资源）、 深度递归查询 （构造复杂的嵌套查询导致拒绝服务）。
• WebSocket测试 ：使用Burp的WebSocket抓包功能。测试点包括： 未经验证的消息注入 （能否向其他用户的频道发送消息？）、 序列化漏洞 （如果传输的是JSON/XML等序列化数据，能否进行XXE或反序列化攻击？）、 权限控制缺失 （连接后，能否请求本无权访问的数据？）。
• Serverless/云函数 ：关注其触发事件（HTTP API、对象存储事件等）的输入是否被充分过滤。尝试在事件参数中注入Payload。同时，检查其返回给客户端的数据是否包含云环境元数据（如AWS的 169.254.169.254 ）。

4.3 工具链的自动化与个性化

高手和新手的另一个区别在于工具的使用效率。

1. 打造自己的信息收集流水线 ：将 subfinder 、 httpx 、 nuclei 等工具用Shell脚本或Python脚本串联起来，一键完成从子域名发现到初步漏洞扫描的全过程。
2. 定制化Nuclei模板 ：Nuclei的强大在于社区模板，但更高阶的是为自己常挖的漏洞类型或特定目标编写模板。例如，为你常测试的某类CMS的特定版本写一个精准检测模板。
3. 开发辅助测试脚本 ：针对复杂的业务逻辑测试（如条件竞争、批量操作），编写专用的Python脚本，比手动操作或使用Intruder更高效、更可控。
4. 搭建知识库 ：用Notion、Obsidian等工具，记录每个目标的资产信息、测试过的功能点、发现的漏洞模式、有效的Payload。长期积累，你会形成自己的“漏洞模式识别库”。

5. 常见问题、误区与排查实录

这条路我踩过很多坑，也见过很多人踩同样的坑。这里集中解答一下。

5.1 新手常犯的五个错误

1. 盲目扫描，不看结果 ：开着扫描器就去干别的，回来看到一堆报告就提交。结果大部分是误报或无关紧要的信息。 一定要人工验证每一条疑似漏洞 。
2. 忽略错误信息 ：应用返回的500错误页面、SQL报错信息、堆栈跟踪，是宝藏。它们可能直接泄露数据库结构、绝对路径、代码片段。
3. 只测前端，不测接口 ：现代应用前后端分离，核心逻辑在API。一定要用Burp/Proxy工具拦截和分析所有的API请求，特别是移动端APP和小程序的请求。
4. 报告写得一塌糊涂 ：步骤不清晰、没有证据、语言混乱。请把审核人员当成对你技术一无所知的小白，手把手教他复现。
5. 违反测试规则 ：进行暴力破解、扫描非授权域名、测试生产数据库。这可能导致法律风险或被SRC拉黑。务必仔细阅读每个SRC的“测试范围”和“行为规范”。

5.2 漏洞无法复现的排查思路

有时候自己测试有漏洞，但提交后审核说无法复现。

• 环境差异 ：你测试的是测试环境，审核人员复现的是生产环境？缓存导致？清理Cookie和缓存再试。
• 账号权限/状态差异 ：你的测试账号有特殊权限？是否是刚注册的新账号？尝试使用和审核人员同权限的账号。
• Payload或步骤问题 ：你的复现步骤是否依赖了某个中间状态？Payload是否在某些条件下才生效？将复现步骤精简到最少、最直接的步骤。
• 网络或工具问题 ：Burp是否设置了拦截或修改规则？是否使用了浏览器插件影响了请求？尝试用纯净的浏览器环境或无痕模式。
• 漏洞已被临时修复 ：在挖掘和提交的间隙，厂商可能已热修复。在报告开头注明发现时间点。

5.3 如何提升漏洞挖掘的“感觉”

这需要长期的积累和思考。

• 多读高质量漏洞报告 ：去各大SRC平台、HackerOne的公开报告、安全社区，看别人是怎么发现漏洞的，学习他们的思路和角度。
• 代码审计辅助 ：如果目标开源或有部分源码泄露，尝试进行简单的代码审计。跟踪一个参数从入口到数据库或命令执行的全过程，能让你深刻理解漏洞成因。
• 建立攻击者思维 ：时刻问自己“如果我要攻击这个功能，我会怎么做？”“开发人员在这里最容易犯什么错？”“这个设计有什么隐含的信任假设？”
• 保持好奇与耐心 ：对一个看似正常的功能点多点几下，多改几个参数，多尝试几种排列组合。漏洞往往藏在那些“理所当然”的背后。

这条路没有捷径，它需要持续的学习、大量的实践和不断的总结反思。从看懂别人的报告，到自己复现，再到独立发现，每一步都是扎实的成长。收藏这篇文章只是一个开始，真正的精通，始于你打开Burp Suite，对准一个目标，敲下第一个请求的那一刻。