SRC合规挖洞实战指南：从技术到规则的高效漏洞挖掘

1. 项目概述：从“野路子”到“正规军”的蜕变

在安全圈混了十几年，我见过太多新手朋友兴冲冲地冲进SRC（安全应急响应中心）平台，吭哧吭哧挖了几个洞，结果提交报告时要么被判定为“无效”，要么因为不合规被扣分甚至封号，最后只能对着“审核不通过”的提示干瞪眼，赏金没拿到，热情也浇灭了大半。这感觉，就像你费尽心思做了一桌好菜，结果因为没按规矩摆盘，直接被取消了参赛资格。今天，我就想结合自己这些年踩过的坑和总结的经验，聊聊“合规挖洞”这件事。它绝不仅仅是提交报告时填对格式那么简单，而是一套贯穿从目标选择、漏洞发现、到报告撰写、沟通跟进全流程的“生存法则”。核心目标就一个：让你挖到的每一个有效漏洞，都能顺利、高效地转化为实实在在的赏金和声誉，避开所有可能导致你“白忙活一场”的审核雷区。

很多人把漏洞挖掘想象成纯粹的技术比拼，认为只要技术够硬，找到的漏洞够“狠”，就一定能拿到高额赏金。这种想法在十年前或许还勉强行得通，但在今天各大企业SRC运营日益规范化、专业化的背景下，已经完全不适用了。现在的SRC，更像是一个有明确规则和裁判的竞技场。技术是你的入场券，但“合规”才是你能在这个竞技场里走多远、拿多少奖金的决定性因素。不合规的操作，轻则让你的辛苦付诸东流，重则可能被平台标记，影响你后续在所有关联SRC的提交。所以，我们今天讨论的“技巧”，有一大半其实是关于如何理解并遵守游戏规则，在规则的框架内最大化你的技术产出。

2. 合规挖洞的核心原则与前期准备

2.1 理解SRC的“游戏规则”：范围、规则与底线

在动手之前，最重要的一步不是打开扫描器，而是仔细、反复地阅读目标SRC的官方公告、漏洞提交指南、奖励规则以及法律声明。这是你的“宪法”，一切行动都必须以其为准绳。我见过太多人，一上来就对着主域名一顿猛扫，结果那个域名根本不在测试范围内，或者明确声明禁止测试，这种行为无异于“自杀式攻击”。

第一，明确测试范围。这是最容易踩雷的地方。通常，SRC会明确列出哪些域名、IP段、移动应用或业务系统在授权测试范围内。例如，*.example.com可能代表所有子域名，而app.example.com则仅限该子域。有些SRC还会提供资产列表或测试专用环境。绝对不要测试范围外的资产，哪怕你发现了一个惊天漏洞。例如，公司的内网办公系统、员工邮箱、第三方服务商提供的系统（除非明确说明），通常都不在范围之内。一个实用的技巧是，将官方范围列表整理成一个清单，用工具（如subfinder、assetfinder）自动化获取这些域名的子域名，并定期对比更新，确保你的目标始终在“安全区”内。

第二，吃透漏洞评级规则。不同SRC对漏洞的严重程度定义和奖励金额计算方式差异巨大。同样是一个存储型XSS，在A平台可能被评为“中危”，奖励500元；在B平台可能因为触发条件苛刻、影响面小而被评为“低危”或“提示”，奖励50元甚至没有奖励。你需要仔细研究平台的漏洞定级标准文档，重点关注那些“一票否决”或“降级处理”的情况。比如，很多平台规定：需要复杂交互或社会工程学才能触发的漏洞会降级；仅影响单个低权限用户且无法扩大影响的漏洞可能不计入奖励；涉及第三方组件但官方已有补丁的漏洞可能评级很低。理解这些，能帮助你在测试时更有针对性，优先寻找那些符合“高奖励特征”的漏洞。

第三，严守测试行为底线。这是红线，绝对不能碰。几乎所有SRC都严禁以下行为：

1. 拒绝服务攻击（DoS/DDoS）：任何可能影响业务可用性的测试，包括大量请求、慢速攻击等。
2. 社会工程学：欺骗客服、员工获取信息。
3. 物理安全测试：尝试进入办公场所。
4. 隐私数据泄露：如果测试中意外获取到用户真实数据（如手机号、身份证号），必须立即停止测试，不得查看、下载、传播，并在报告中说明情况。最好的做法是，在测试涉及用户数据的接口时，使用测试账号或确保请求不会返回真实敏感信息。
5. 自动化工具滥用：使用扫描器时，必须设置合理的速率限制（Rate Limiting），避免对服务器造成压力。像sqlmap这类工具，一定要用--delay和--threads参数控制节奏。
6. 破坏性操作：绝对不要进行INSERT、UPDATE、DELETE等数据库写操作，不要删除或修改任何文件。对于文件上传漏洞，只能上传无害的文本文件（如test.txt）作为证明，并在报告中承诺会立即删除。

我的实操心得：我习惯为每个重点关注的SRC建立一个“规则备忘”文档，用表格列出其范围边界、高危漏洞定义、禁止行为等关键信息。每次测试前快速过一遍，能有效避免低级失误。记住，安全测试的第一原则是“不造成伤害”，合规性是你专业素养的体现。

2.2 情报收集与目标筛选：聪明的猎人先选战场

在合规的框架内，如何选择高价值目标，直接决定了你的投入产出比。无差别地全网扫描效率极低，我们应该像狙击手一样，锁定最有价值的目标。

信息收集的维度：

• 资产测绘与暴露面梳理：使用Amass、Subfinder等工具获取子域名，用httpx、nuclei探测存活服务和标题。重点关注新上线的子域名（*.new.example.com）、测试环境（test、staging、dev）、管理后台（admin、manage）、API接口（api）以及移动应用对应的API域名。这些往往是安全防护相对薄弱、却又可能涉及核心业务逻辑的地方。
• 技术栈指纹识别：使用Wappalyzer（浏览器插件）或whatweb、ObserverWard等工具识别网站使用的框架、组件、中间件、JS库版本。老旧版本的Spring Boot、Apache Struts、ThinkPHP，或者存在已知漏洞的Fastjson、Shiro等组件，都是极佳的突破口。
• 源码与敏感信息泄露：定期用GitHub、GitLab搜索公司相关关键词，寻找泄露的源码、配置文件（含数据库密码、API密钥）、.git目录、DS_Store文件。工具如gitleaks、truffleHog可以自动化这个过程。在合规范围内，发现并报告这类信息泄露漏洞，通常评级不低，且技术难度相对较小。
• 业务逻辑理解：真正的高价值漏洞往往藏在业务逻辑里。你需要花时间去试用目标的应用：注册、登录、支付、订单修改、个人信息更新、权限申请等流程。画出关键业务的数据流图，思考“如果一个恶意用户在这里，他能做什么不该做的事？” 比如，能否修改订单金额？能否越权查看他人订单？能否重复领取优惠券？

目标筛选策略：

1. 从“边缘”到“核心”：优先测试非核心业务系统、新业务或边缘业务模块。这些地方安全投入可能不足，但同样在奖励范围内。
2. 关注“变化”：企业并购新业务、上线新功能、进行重大架构升级时，往往是安全漏洞的“高发期”。关注其技术博客、招聘信息（招聘某特定技术栈工程师可能意味着新项目）、App版本更新日志。
3. 利用“共性”：如果你在A公司的某个子域名发现了一种特定类型的配置错误，那么用同样的思路去检查B公司、C公司的同类资产，很可能会有收获。许多企业的运维模式和配置模板是相似的。

3. 漏洞挖掘实战技巧与合规验证

3.1 低危漏洞的高效挖掘与价值提升

很多新手看不起低危漏洞，觉得费劲巴力挖一个才几十块钱。但我的经验是，低危漏洞往往是通往高危漏洞的“钥匙”，并且通过巧妙的组合与描述，其价值可以显著提升。

1. 信息泄露漏洞的深度利用：单纯的js文件泄露路径可能只是“提示”级别。但如果你能证明，通过这个泄露的路径，结合其他漏洞（如目录遍历、未授权访问）能获取到配置文件、源码、甚至数据库备份，那它的危害等级就完全不同了。在报告时，不要只说“发现了/WEB-INF/web.xml可访问”，而要描述一个完整的攻击链：“通过/static/../WEB-INF/web.xml路径遍历，我获取了数据库连接池配置，其中明文密码为xxx。进一步测试发现，该数据库端口对外网开放且未授权访问，可导致全量用户数据泄露。” 这样，一个低危信息泄露就可能升级为高危甚至严重的漏洞。

2. 前端漏洞的“后端化”思考：一个反射型XSS（非存储型）通常被认为是低危。但你需要深入探究其根源。这个XSS的参数是否来自后端数据库？是否在其他更重要的功能点（如后台管理、API接口）也存在同样的问题？是否可以通过这个XSS点，结合CSRF漏洞，诱使管理员执行操作？在报告中，除了提供POC，还应分析漏洞的根源（是输出未过滤，还是某通用组件的问题），并指出其潜在的、更大范围的危害。

3. 逻辑漏洞的细心发掘：这是低危变高危的富矿。例如：

• 越权漏洞：通过修改用户ID参数，能查看或操作他人数据。测试时，要系统性地遍历所有带ID的参数（uid，id，order_id等）。
• 业务流程绕过：比如，在支付流程中，能否直接跳转到支付成功的页面？在验证码校验环节，能否重复使用同一个验证码？或者直接置空验证码参数？
• 竞争条件：在领取优惠券、抢购商品时，同时发起大量请求，是否可能超领？这类漏洞需要编写简单的并发脚本进行测试，但务必控制并发量，避免对服务器造成DoS影响。

注意事项：在测试逻辑漏洞时，务必使用你自己的测试账号，或者平台提供的测试账号。绝对不要使用或影响任何真实用户的数据。所有测试操作都应该是可逆的、无副作用的。

3.2 中高危漏洞的精准打击与POC构造

对于中高危漏洞，如SQL注入、命令执行、SSRF、文件上传Getshell等，技术要求更高，但回报也更丰厚。关键在于“精准”和“无害化证明”。

1. SQL注入：

• 探测：除了常规的'、"、sleep()测试，更要关注JSON格式参数、HTTP Header（如X-Forwarded-For）中的注入点。使用sqlmap时，务必加上--level和--risk参数逐步升级，并且永远使用--batch和--smart模式，避免任何交互式写操作。更推荐的方式是，先手工通过报错信息、布尔盲注的差异判断注入存在，再用sqlmap进行无害化的数据获取验证（如--current-user，--current-db），而不是一上来就尝试--dump。
• POC构造：在报告中，POC不能是简单的1' and '1'='1。你需要提供一个完整的、能清晰证明漏洞存在的HTTP请求包（包括URL、Headers、Body），并说明注入的参数、数据库类型、以及你获取到的非敏感信息（如数据库版本@@version、当前用户user()）。绝对不要在POC中展示获取到的真实业务数据。

2. 文件上传与命令执行：

• 绕过技巧：除了常见的后缀名（.php5，.phtml）、大小写、双写、空格、00截断，更要关注解析漏洞（Apache的1.php.jpg）、内容校验绕过（在图片尾部追加恶意代码）、以及前端校验绕过（直接抓包修改）。
• 无害化POC：这是合规的核心。证明文件上传成功后，不要上传一句话木马或执行whoami。正确的做法是：
  • 上传一个内容为<?php echo md5('安全测试');?>的文本文件，尝试以.php后缀执行。
  • 如果成功，访问该文件，查看是否输出了预期的md5值。这足以证明代码执行能力。
  • 对于命令执行，可以尝试执行echo [一串随机字符]或ping -c 1 [你的VPS IP]（需谨慎，部分SRC允许，部分不允许，务必先看规则）。更好的方式是执行sleep 5，通过响应时间延迟来证明。在任何情况下，都不要执行rm，cat /etc/passwd，wget等可能造成破坏或信息泄露的命令。

3. SSRF（服务器端请求伪造）：

• 探测：关注所有能控制URL、IP地址的参数，如图片加载、文件导入、PDF生成、远程API调用等功能。
• 利用链：单纯的能访问http://169.254.169.254（云元数据）可能只是中危。如果你能证明通过SSRF可以访问内网Redis、MySQL等未授权服务，或者结合gopher协议写入Redis进而实现RCE，那价值就巨大了。在报告中，要详细描述从外网SSRF到内网横向移动的完整路径。
• 合规验证：使用你自己可控的服务器（如Burp Collaborator、ceye.io）来接收请求，证明服务器确实发起了对外请求。不要尝试访问或攻击目标内网的其他真实业务系统。

3.3 漏洞组合与攻击链构建

单个漏洞可能评级有限，但多个低中危漏洞串联起来，可能就能构成一个高危的攻击场景。审核人员非常看重这种“攻击面”和“实际危害”的评估能力。

经典组合举例：

1. 信息泄露 + 越权：通过信息泄露获取到其他用户的标识ID，再利用越权漏洞操作其数据。
2. XSS + CSRF：利用存储型XSS在后台页面植入恶意脚本，当管理员访问时，脚本自动发起CSRF请求，添加后台管理员账户。
3. SSRF + Redis未授权访问：通过SSRF攻击内网的Redis，写入Webshell，实现RCE。
4. 逻辑绕过 + 支付漏洞：绕过优惠券使用次数限制，组合支付金额篡改漏洞，实现零元购或超额退款。

在提交这类组合漏洞时，报告的逻辑必须极其清晰。你需要像写一个侦探故事一样，一步步展示攻击步骤：

• 第一步：我发现A处存在一个信息泄露漏洞，获得了用户B的user_id。
• 第二步：在C功能点，我通过修改user_id参数，成功越权访问了用户B的隐私数据（附POC）。
• 第三步：综上，攻击者可以利用A漏洞获取大量用户ID，再通过C漏洞批量窃取这些用户的隐私数据，造成大规模数据泄露。

这种报告方式，不仅展示了你的技术深度，更体现了你对业务风险的整体评估能力，更容易获得审核人员的认可和高额赏金。

4. 报告撰写、提交与沟通的艺术

4.1 漏洞报告的结构化写作：让审核人员一眼看懂

一份优秀的漏洞报告，是技术能力和专业素养的集中体现。它应该让审核人员（可能不是该业务的具体开发）在最短时间内理解漏洞是什么、在哪、有多严重、如何复现。

报告必备要素（模板）：

1. 漏洞标题：精炼概括。如“【高危】XX业务订单查询接口存在ID参数越权，可导致全量用户订单信息泄露”。
2. 漏洞等级：根据平台标准自评（高危/中危/低危/提示）。
3. 影响组件/URL：精确到存在漏洞的URL地址、API接口、功能模块。
4. 漏洞描述：
   • 现象：用一两句话说明你发现了什么。
   • 原理分析：简要说明漏洞产生的原因（如服务端未校验用户权限、SQL语句拼接未过滤）。
   • 潜在危害：说明漏洞可能被利用后造成的具体影响（如数据泄露、资金损失、权限提升等）。这部分要具体，避免空泛。
5. 复现步骤：这是核心！必须做到傻瓜式、可复现。
   • 使用编号列表（1， 2， 3...）。
   • 每一步都包含：操作（点击哪里、输入什么）、HTTP请求（建议附上Burp Suite的Raw请求包，关键参数高亮）、服务器响应。
   • 从正常登录开始，到最终触发漏洞结束。
6. 证明截图/视频：
   • 截图需清晰，包含浏览器地址栏、请求响应关键信息。
   • 对于逻辑漏洞或复杂交互，录制一个简短的GIF或视频（不超过30秒）是非常加分的。
   • 在截图和视频中，务必对自己的个人信息（测试账号名、Token等）和任何可能泄露的真实用户数据进行打码处理。
7. 修复建议：提供切实可行的修复方案。例如：
   • SQL注入：建议使用参数化查询或预编译语句。
   • 越权：在服务端对每次请求进行严格的权限校验（基于会话或Token，而非前端传入的参数）。
   • XSS：对用户输入进行严格的过滤和转义，建议使用成熟的安全组件。
   • 这体现了你的建设性，而不仅仅是“找茬”。
8. 其他信息：测试使用的浏览器版本、工具、测试账号等。

我的实操心得：我习惯用Markdown写报告，因为它格式清晰，方便粘贴代码和截图。在提交前，我会自己按照报告步骤完整地复现一遍，确保任何一个拿到这份报告的人都能成功复现。避免使用“可能”、“也许”这类模糊词汇，所有陈述都要肯定、有证据支持。

4.2 提交后的沟通与跟进：做一个“专业”的提交者

报告提交后，工作并未结束。良好的沟通能极大提升漏洞的处理效率和你的个人形象。

1. 耐心等待：SRC审核人员通常任务繁重，处理需要时间。除非平台有明确的SLA（服务等级协议），否则不要刚提交就频繁催促。
2. 理性回应审核反馈：如果报告被退回或评级有争议，仔细阅读审核意见。
   • 如果是误判：礼貌、清晰地提供额外的证据或解释。例如，审核认为无法复现，你可以检查步骤是否描述清楚，提供更详细的流量包或屏幕录像。
   • 如果确实不合规或无效：虚心接受。可能是测试范围搞错了，或者是漏洞已被知晓。从中学习，调整策略。
   • 避免情绪化争论：就事论事，用技术证据说话。记住，你和审核人员是协作关系，共同目标是提升产品安全性。
3. 确认修复与申请复测：当状态变为“已修复”时，平台可能会邀请你进行复测。这是一个重要的环节。认真测试修复是否彻底，是否存在绕过可能。如果修复成功，确认关闭；如果修复不完整，提交新的证据。你的严谨是对企业安全的负责，也会让平台更重视你的提交。
4. 建立个人声誉：长期、高质量、合规的提交，会让你在SRC平台和整个安全社区建立起良好的声誉。你可能会获得更高的初始漏洞评级、更快的审核速度，甚至被邀请参加私密测试项目。

5. 高级策略与长期成长规划

5.1 工具链的自动化与效率提升

手工测试是基础，但要想持续产出，必须借助自动化。这里的自动化不是无脑扫描，而是将重复、繁琐的工作交给工具，让你聚焦于逻辑分析和深度测试。

• 资产监控与发现：编写脚本，定期爬取目标SRC的新增域名、子域名，并自动进行基础指纹识别和端口扫描，将结果推送到你的工作台。
• 漏洞初步筛查：使用Nuclei这类基于模板的扫描器。它的优势在于社区模板丰富，更新快，且POC通常经过设计，相对温和。你可以针对目标的技术栈（如Spring Boot，ThinkPHP），运行特定的模板集。关键是要自定义模板，将扫描速率调低，并且只针对授权目标进行。
• 信息收集聚合：搭建或使用类似Arjun（参数发现）、waybackurls（历史URL收集）、GF（模式匹配）的工具链，将分散的信息聚合起来，快速定位潜在的测试点，比如找到所有可能有id参数的URL进行越权测试。
• 自定义POC脚本：对于常见的漏洞类型（如简单的越权、未授权访问），可以编写一些简单的Python脚本进行批量、快速的验证，提高测试覆盖率。

安全提醒：自动化工具必须置于严格的速率控制和目标控制之下。一个失控的扫描脚本，几分钟内就可能对目标服务器造成DoS攻击，这严重违反合规原则，会导致你的IP甚至账号被永久封禁。

5.2 从漏洞挖掘到安全研究的思维转变

当你掌握了基本的挖洞技巧后，应该尝试向更深层次迈进，这能让你脱颖而出。

1. 代码审计：如果你有开发背景，或者愿意学习，尝试对开源组件、框架进行代码审计。发现一个通用框架的0day漏洞，其价值和影响力远大于在单个应用上找到一个SQL注入。你可以从一些流行的、用你熟悉语言编写的开源项目开始。
2. 协议与架构安全：研究新兴的协议（如gRPC，GraphQL）、架构（如微服务、Serverless）中可能存在的安全问题。例如，GraphQL的接口信息泄露、内省功能滥用、复杂度攻击等，都是比较新的方向。
3. 供应链安全：关注第三方库、依赖包的安全。使用npm audit，pip-audit等工具检查目标网站可能使用的有漏洞的组件。报告一个被广泛使用但存在已知高危漏洞的旧版本组件，同样有价值。
4. 建立知识体系：不要满足于复现别人的漏洞。每挖到一个洞，去深入理解其根本原因，阅读相关的CVE分析文章，思考修复方案。将同类漏洞进行归纳总结，形成自己的方法论。

5.3 风险规避与法律意识

这是贯穿始终的生命线。

• 数据保密：在测试过程中接触到的任何非公开信息，都必须严格保密。不得在公共社区、社交媒体、博客上披露漏洞细节，直到厂商完全修复并公开披露。
• 授权测试：只测试明确获得授权的目标。对于没有SRC或漏洞奖励计划的企业，不要擅自进行测试。如果想帮助他们，可以通过负责任的漏洞披露渠道（如邮件联系安全部门）进行沟通。
• 法律边界：始终明确，你的行为必须在法律和合约（SRC条款）允许的范围内进行。任何未经授权的入侵、数据窃取、破坏行为都是非法的。合规挖洞是白帽子的行为，与黑产有本质区别。
• 保险措施：在进行可能有风险的测试（如SSRF探测内网）前，可以在自己的VPS上搭建一个简单的日志服务器来接收回连，而不是去探测可能存在真实业务的内网IP。所有测试流量，尽量通过可控的代理进行，便于追踪和证明自己的操作是合规的。

挖洞这条路，技术是引擎，合规是方向盘。没有引擎跑不快，没有方向盘则迟早会翻车。希望这些从实战中总结出的技巧和避坑指南，能帮助你更安全、更高效地在SRC的世界里航行，将你的技术能力，稳稳地转化为应得的认可和回报。记住，最强的黑客不是最能破坏的，而是最懂规则、并能利用规则创造最大安全价值的人。