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都严禁以下行为拒绝服务攻击DoS/DDoS任何可能影响业务可用性的测试包括大量请求、慢速攻击等。社会工程学欺骗客服、员工获取信息。物理安全测试尝试进入办公场所。隐私数据泄露如果测试中意外获取到用户真实数据如手机号、身份证号必须立即停止测试不得查看、下载、传播并在报告中说明情况。最好的做法是在测试涉及用户数据的接口时使用测试账号或确保请求不会返回真实敏感信息。自动化工具滥用使用扫描器时必须设置合理的速率限制Rate Limiting避免对服务器造成压力。像sqlmap这类工具一定要用--delay和--threads参数控制节奏。破坏性操作绝对不要进行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可以自动化这个过程。在合规范围内发现并报告这类信息泄露漏洞通常评级不低且技术难度相对较小。业务逻辑理解真正的高价值漏洞往往藏在业务逻辑里。你需要花时间去试用目标的应用注册、登录、支付、订单修改、个人信息更新、权限申请等流程。画出关键业务的数据流图思考“如果一个恶意用户在这里他能做什么不该做的事” 比如能否修改订单金额能否越权查看他人订单能否重复领取优惠券目标筛选策略从“边缘”到“核心”优先测试非核心业务系统、新业务或边缘业务模块。这些地方安全投入可能不足但同样在奖励范围内。关注“变化”企业并购新业务、上线新功能、进行重大架构升级时往往是安全漏洞的“高发期”。关注其技术博客、招聘信息招聘某特定技术栈工程师可能意味着新项目、App版本更新日志。利用“共性”如果你在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的参数uididorder_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 11。你需要提供一个完整的、能清晰证明漏洞存在的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通过响应时间延迟来证明。在任何情况下都不要执行rmcat /etc/passwdwget等可能造成破坏或信息泄露的命令。3. SSRF服务器端请求伪造探测关注所有能控制URL、IP地址的参数如图片加载、文件导入、PDF生成、远程API调用等功能。利用链单纯的能访问http://169.254.169.254云元数据可能只是中危。如果你能证明通过SSRF可以访问内网Redis、MySQL等未授权服务或者结合gopher协议写入Redis进而实现RCE那价值就巨大了。在报告中要详细描述从外网SSRF到内网横向移动的完整路径。合规验证使用你自己可控的服务器如Burp Collaborator、ceye.io来接收请求证明服务器确实发起了对外请求。不要尝试访问或攻击目标内网的其他真实业务系统。3.3 漏洞组合与攻击链构建单个漏洞可能评级有限但多个低中危漏洞串联起来可能就能构成一个高危的攻击场景。审核人员非常看重这种“攻击面”和“实际危害”的评估能力。经典组合举例信息泄露 越权通过信息泄露获取到其他用户的标识ID再利用越权漏洞操作其数据。XSS CSRF利用存储型XSS在后台页面植入恶意脚本当管理员访问时脚本自动发起CSRF请求添加后台管理员账户。SSRF Redis未授权访问通过SSRF攻击内网的Redis写入Webshell实现RCE。逻辑绕过 支付漏洞绕过优惠券使用次数限制组合支付金额篡改漏洞实现零元购或超额退款。在提交这类组合漏洞时报告的逻辑必须极其清晰。你需要像写一个侦探故事一样一步步展示攻击步骤第一步我发现A处存在一个信息泄露漏洞获得了用户B的user_id。第二步在C功能点我通过修改user_id参数成功越权访问了用户B的隐私数据附POC。第三步综上攻击者可以利用A漏洞获取大量用户ID再通过C漏洞批量窃取这些用户的隐私数据造成大规模数据泄露。这种报告方式不仅展示了你的技术深度更体现了你对业务风险的整体评估能力更容易获得审核人员的认可和高额赏金。4. 报告撰写、提交与沟通的艺术4.1 漏洞报告的结构化写作让审核人员一眼看懂一份优秀的漏洞报告是技术能力和专业素养的集中体现。它应该让审核人员可能不是该业务的具体开发在最短时间内理解漏洞是什么、在哪、有多严重、如何复现。报告必备要素模板漏洞标题精炼概括。如“【高危】XX业务订单查询接口存在ID参数越权可导致全量用户订单信息泄露”。漏洞等级根据平台标准自评高危/中危/低危/提示。影响组件/URL精确到存在漏洞的URL地址、API接口、功能模块。漏洞描述现象用一两句话说明你发现了什么。原理分析简要说明漏洞产生的原因如服务端未校验用户权限、SQL语句拼接未过滤。潜在危害说明漏洞可能被利用后造成的具体影响如数据泄露、资金损失、权限提升等。这部分要具体避免空泛。复现步骤这是核心必须做到傻瓜式、可复现。使用编号列表1 2 3...。每一步都包含操作点击哪里、输入什么、HTTP请求建议附上Burp Suite的Raw请求包关键参数高亮、服务器响应。从正常登录开始到最终触发漏洞结束。证明截图/视频截图需清晰包含浏览器地址栏、请求响应关键信息。对于逻辑漏洞或复杂交互录制一个简短的GIF或视频不超过30秒是非常加分的。在截图和视频中务必对自己的个人信息测试账号名、Token等和任何可能泄露的真实用户数据进行打码处理。修复建议提供切实可行的修复方案。例如SQL注入建议使用参数化查询或预编译语句。越权在服务端对每次请求进行严格的权限校验基于会话或Token而非前端传入的参数。XSS对用户输入进行严格的过滤和转义建议使用成熟的安全组件。这体现了你的建设性而不仅仅是“找茬”。其他信息测试使用的浏览器版本、工具、测试账号等。我的实操心得我习惯用Markdown写报告因为它格式清晰方便粘贴代码和截图。在提交前我会自己按照报告步骤完整地复现一遍确保任何一个拿到这份报告的人都能成功复现。避免使用“可能”、“也许”这类模糊词汇所有陈述都要肯定、有证据支持。4.2 提交后的沟通与跟进做一个“专业”的提交者报告提交后工作并未结束。良好的沟通能极大提升漏洞的处理效率和你的个人形象。耐心等待SRC审核人员通常任务繁重处理需要时间。除非平台有明确的SLA服务等级协议否则不要刚提交就频繁催促。理性回应审核反馈如果报告被退回或评级有争议仔细阅读审核意见。如果是误判礼貌、清晰地提供额外的证据或解释。例如审核认为无法复现你可以检查步骤是否描述清楚提供更详细的流量包或屏幕录像。如果确实不合规或无效虚心接受。可能是测试范围搞错了或者是漏洞已被知晓。从中学习调整策略。避免情绪化争论就事论事用技术证据说话。记住你和审核人员是协作关系共同目标是提升产品安全性。确认修复与申请复测当状态变为“已修复”时平台可能会邀请你进行复测。这是一个重要的环节。认真测试修复是否彻底是否存在绕过可能。如果修复成功确认关闭如果修复不完整提交新的证据。你的严谨是对企业安全的负责也会让平台更重视你的提交。建立个人声誉长期、高质量、合规的提交会让你在SRC平台和整个安全社区建立起良好的声誉。你可能会获得更高的初始漏洞评级、更快的审核速度甚至被邀请参加私密测试项目。5. 高级策略与长期成长规划5.1 工具链的自动化与效率提升手工测试是基础但要想持续产出必须借助自动化。这里的自动化不是无脑扫描而是将重复、繁琐的工作交给工具让你聚焦于逻辑分析和深度测试。资产监控与发现编写脚本定期爬取目标SRC的新增域名、子域名并自动进行基础指纹识别和端口扫描将结果推送到你的工作台。漏洞初步筛查使用Nuclei这类基于模板的扫描器。它的优势在于社区模板丰富更新快且POC通常经过设计相对温和。你可以针对目标的技术栈如Spring BootThinkPHP运行特定的模板集。关键是要自定义模板将扫描速率调低并且只针对授权目标进行。信息收集聚合搭建或使用类似Arjun参数发现、waybackurls历史URL收集、GF模式匹配的工具链将分散的信息聚合起来快速定位潜在的测试点比如找到所有可能有id参数的URL进行越权测试。自定义POC脚本对于常见的漏洞类型如简单的越权、未授权访问可以编写一些简单的Python脚本进行批量、快速的验证提高测试覆盖率。安全提醒自动化工具必须置于严格的速率控制和目标控制之下。一个失控的扫描脚本几分钟内就可能对目标服务器造成DoS攻击这严重违反合规原则会导致你的IP甚至账号被永久封禁。5.2 从漏洞挖掘到安全研究的思维转变当你掌握了基本的挖洞技巧后应该尝试向更深层次迈进这能让你脱颖而出。代码审计如果你有开发背景或者愿意学习尝试对开源组件、框架进行代码审计。发现一个通用框架的0day漏洞其价值和影响力远大于在单个应用上找到一个SQL注入。你可以从一些流行的、用你熟悉语言编写的开源项目开始。协议与架构安全研究新兴的协议如gRPCGraphQL、架构如微服务、Serverless中可能存在的安全问题。例如GraphQL的接口信息泄露、内省功能滥用、复杂度攻击等都是比较新的方向。供应链安全关注第三方库、依赖包的安全。使用npm auditpip-audit等工具检查目标网站可能使用的有漏洞的组件。报告一个被广泛使用但存在已知高危漏洞的旧版本组件同样有价值。建立知识体系不要满足于复现别人的漏洞。每挖到一个洞去深入理解其根本原因阅读相关的CVE分析文章思考修复方案。将同类漏洞进行归纳总结形成自己的方法论。5.3 风险规避与法律意识这是贯穿始终的生命线。数据保密在测试过程中接触到的任何非公开信息都必须严格保密。不得在公共社区、社交媒体、博客上披露漏洞细节直到厂商完全修复并公开披露。授权测试只测试明确获得授权的目标。对于没有SRC或漏洞奖励计划的企业不要擅自进行测试。如果想帮助他们可以通过负责任的漏洞披露渠道如邮件联系安全部门进行沟通。法律边界始终明确你的行为必须在法律和合约SRC条款允许的范围内进行。任何未经授权的入侵、数据窃取、破坏行为都是非法的。合规挖洞是白帽子的行为与黑产有本质区别。保险措施在进行可能有风险的测试如SSRF探测内网前可以在自己的VPS上搭建一个简单的日志服务器来接收回连而不是去探测可能存在真实业务的内网IP。所有测试流量尽量通过可控的代理进行便于追踪和证明自己的操作是合规的。挖洞这条路技术是引擎合规是方向盘。没有引擎跑不快没有方向盘则迟早会翻车。希望这些从实战中总结出的技巧和避坑指南能帮助你更安全、更高效地在SRC的世界里航行将你的技术能力稳稳地转化为应得的认可和回报。记住最强的黑客不是最能破坏的而是最懂规则、并能利用规则创造最大安全价值的人。
)
