★ FEATURED ARTICLE 做SRC漏洞挖掘这几年我最大的感受是这一行最稀缺的不是扫描器开得有多猛而是一条能稳定把漏洞从“看见了”变成“确认了”的思路。刚入门的时候我也犯过抱着工具到处跑的毛病结果目标没测明白还把自己累得够呛。后来慢慢理出一套可以复用的流程才发现漏洞挖掘真正拼的是信息收集的完整性、对业务逻辑的理解以及对报告负责的态度。在展开之前先把定位说清楚SRC漏洞挖掘是厂商或企业在自家安全应急响应中心Security Response Center上按照公开的授权范围与测试规则邀请安全研究者用攻击者视角去发现漏洞。它和传统渗透测试最大的区别在于“有合同、有边界、有评分”你的每次提交都会进入评审流程质量永远比数量重要。这篇笔记适合刚接触众测的入门者也适合有一定漏洞挖掘经验、但想把自己的测试流程系统化的朋友。1. SRC漏洞挖掘的基础认知不要把“找漏洞”理解成“攻击系统”1.1 一句话说清SRC漏洞挖掘SRC漏洞挖掘翻译成人话就是厂商搭建一个漏洞收集渠道把允许测试的资产列出来再给你一份行为守则。你在守则框架内测试找到问题写报告提交企业评估风险后给积分、现金或其他形式的奖励。整个过程本质上是企业和白帽子之间的合作体检而不是对抗。需要强调授权范围通常写在平台的测试规则里比如“允许测试哪些根域名和子域名禁止触碰生产数据库、禁止下载用户隐私数据”。我见过不少人第一单就被封号原因不是技术不够而是没读规则就顺手测了规则外的域名。起点错了后面再精彩也是白搭。所以SRC漏洞挖掘的第一个基本功不是Burp Suite怎么用而是学会在动手前把平台的授权边界、敏感目录、数据使用条款全部读一遍。宁可前半小时都在做规则分析也不要为了抢一个首发漏洞把自己搭进去。1.2 动手前先想清楚这三件事每次接到新项目我都会先问自己三个问题答案想清楚了再碰键盘。第一范围是什么。主域名、子域名、IP段、移动端、小程序分别在不在授权列表里。范围以外的目标就算看起来漏洞满满也坚决不碰。很多人觉得“顺手测一下也没关系”这个念头恰恰是封号的起点。第二数据边界在哪里。测试过程中不可避免会遇到真实用户数据我的原则是只做存在性验证不做下载、导库、修改。比如一个越权漏洞证明“能读到不属于当前账号的订单概要信息”就是有效证据没必要把订单详情全部扒下来当展示材料。第三万一踩到高危点怎么处理。如果已经进入敏感环境比如不知不觉摸到了后台或数据接口立刻停手把已掌握的证据整理成报告提交给平台。千万别因为好奇继续往下走那是把“安全测试”变成“事故”。这三个问题想清楚后面的测试才会有节奏。很多人做SRC漏洞挖掘容易上头看到接口就硬怼看到参数就盲测结果要么把自己绕晕要么触碰了不该碰的数据。把“边界感”内化成习惯这条路才能走得持久。1.3 摆脱“漏洞越多越好”的错觉我最早吃过的亏就是习惯在同一平台连续提交一堆低危发现比如反射型XSS、信息泄露页面、小目录可访问以为量大就能攒积分。结果是审核记录里一片“忽略”理由基本都是“无效、重复、不影响核心资产”。后来我才想明白SRC平台对漏洞的价值判定完全取决于该漏洞对目标业务的实际影响。比如某个信息泄露如果暴露的是内网拓扑可能中危甚至高危如果只是在某个静态页面上多出个版本号那就属于噪音。与其每天产出十几个低质量提交不如把一个高危或中高危的洞挖透、写清楚。所以我的策略是每个目标先做分层把时间优先投入到核心业务、登录后功能、API接口这些更可能出问题的位置低危发现先记录在案攒到一定量再集中提交避免给审核带来噪音污染。这个习惯调整之后我的报告通过率和被采纳数量反而都上去了。2. 信息收集是地基做不全就别谈漏洞挖掘2.1 资产盘点先把散落的目标集中起来很多新手拿到一个域名就开始扫目录这是反的。正确做法是先做资产盘点搞清楚目标到底由多少子域名、多少IP、多少系统构成。子域枚举时我会先用子域枚举工具配合证书透明度日志拉一批线索再做DNS解析最后用存活探测工具过滤出真正在线的Web资产。多个数据源交叉验证很有必要单独一个数据源可能漏掉不少旁路资产。端口层面用端口扫描工具扫常用端口即可注意不要用过于激进的时间模板否则轻易触发目标防护授权范围内也不该把目标打挂。扫描结果里80、443、8080、8443这些端口优先看其余端口等服务识别完成后再判断是否有开放的管理端或调试接口。这一步的目标是生成一张“资产-指纹-入口”清单不需要特别花哨但必须完整。没有这份清单后续的所有测试都是撞运气。很多高质量的SRC发现恰恰都来自那些容易被忽略的子域名或冷门端口上。2.2 JS文件与接口分析别人把秘密写在明处Web应用的JS文件藏了太多东西。很多业务系统的前端会把API接口、内部域名、甚至硬编码密钥写在JavaScript里。我的习惯是信息收集阶段把所有页面的JS文件全部拉下来然后用关键字符串做一轮检索比如“api”“admin”“internal”“test”“debug”“token”“secret”。曾经在某个授权测试里我盯着主站首页看了半天没有突破口顺手拉了一个较大的业务脚本一搜直接找到一个只在测试阶段开放的接口路径。拼上参数试了试发现该接口没有做访问控制可以直接读到新功能的数据。这类问题如果靠目录扫描是扫不出来的因为JS文件里的路径自带业务语义。对新手来说这一步完全可以用浏览器开发者工具完成不需要额外工具。打开任意页面的Network面板JS文件逐个点开看再全局搜索字符串习惯之后五分钟就能筛出有价值的线索。等熟练了再换用脚本自动抓取所有JS文件做批量分析效率会更高。2.3 指纹识别决定你往哪个方向深挖指纹识别非常关键。同一个漏洞在不同框架上的利用路径完全不同。实践中我会先看响应头里的Server、X-Powered-By再看favicon、页面特征、特定路径最后配合指纹识别工具确认组件版本。识别出组件版本之后对照公开的组件漏洞情报库看是否存在已知漏洞或者老版本才有的弱点。如果目标是企业自研代码指纹的意义更多是判断技术栈如果目标是开源CMS或通用框架指纹直接决定了后续测试的核心方向。这里多说一句识别WAF也算指纹的一部分。最简单的判断方法发一个正常的请求再发一个带有明显测试特征的请求看响应内容或状态码是否被拦截。如果存在WAF后续测试要更克制不要因为恶意流量把目标整体限流否则后面所有正常测试也会被牵连。2.4 建一张可复用的资产表我建议用表格工具维护一张资产表每个目标下面至少记录域名、IP、端口、Web指纹、发现的JS接口、是否需要登录、已测试的功能点、风险备注。这张表一多就不会出现测着测着忘了自己已经测过什么的情况。刚开始做SRC漏洞挖掘时我习惯把信息收集结果直接写在对话窗口里过两天就找不到了。后来改成统一模板记录效率肉眼可见提升。表格不要求一步到位每多一个发现就补一行等提交报告时这些记录就是复现步骤的素材来源。对做漏洞挖掘笔记的人来说这套资产表本身就是一个可以反复回看的“目标档案库”。3. 最容易出成果的漏洞方向基本都在这些类型里3.1 越权SRC里性价比最高的方向越权漏洞指的是应用没有正确校验“当前用户是否有权访问该数据”分水平越权和垂直越权。水平越权最常见的场景登录账号A后把请求中的订单ID、用户ID、文件ID等参数换成账号B的数据编号如果接口照样返回数据就存在越权。测试越权不需要任何复杂工具抓包工具Repeater就能完成。建议准备两个账号账号A和账号BA正常访问自己的资源并抓包再把请求中的ID替换成B的资源ID比较响应差异。如果返回了B的内容记录下请求包和响应包即可。这类漏洞之所以值得优先是因为很多业务系统在功能开发时只注重“登录后才能访问”却忽略了“登录后也要校验数据归属”。对SRC而言越权往往意味着大量用户数据可被未授权访问评分普遍偏高。唯一的注意点验证到“可读”就停不要真的去翻大量数据更不要尝试写操作。3.2 业务逻辑漏洞审核眼里的大鱼业务逻辑漏洞比传统漏洞更依赖对业务的理解。常见形态有验证码可复用、支付流程可篡改、订单状态可任意跳转、优惠券可重复使用、积分计算存在负值。这些问题的特点是“技术上没有注入点但流程上存在可被利用的缺陷”。我的观察是SRC平台对业务逻辑漏洞的评价往往两极分化。如果逻辑缺陷能导致资金类损失或批量薅羊毛通常会被定为高危甚至严重如果只是某个流程校验形同虚设但影响可控也可能只算中低危。所以测试前先想想这个逻辑漏洞如果被恶意利用会造成多大损失报告里把损失场景写清楚审核才会认。具体测试时尽量走自己的账号、自己的订单不要随便动他人数据和真实生产数据。某些平台会提供专门的测试账号优先使用。比如测试支付金额修改可以下一个小额订单改一个字段看是否成功验证完立即取消订单而不是真的用低价买下商品这是边界问题。3.3 注入类问题需要更克制地验证SQL注入和命令注入是漏洞挖掘里老牌高危方向但在SRC环境里有一个容易被误解的点证明存在性就够了不需要拿数据。我的测试思路是找到输入点后先在参数里构造一个能闭合语法的测试载荷观察后端响应是否出现数据库错误、超时或布尔差异如果怀疑存在注入再选择无危害的布尔条件做二次确认比如构造一个永远为真和一个永远为假的查询对比响应长度。自动化工具如通用的注入检测工具当然能用但前提是目标在授权范围且配置了合适的风险和等级参数。很多事故都是因为有人开着默认等级盲目跑工具结果把表拖垮。记住SRC要的是“能证明风险的最小样本”不是一次完整的渗透攻击。命令注入相对少见主要由后端调用系统命令拼接输入导致。发现思路是关注文件下载、压缩、导出、调用外部程序的功能输入特殊字符观察报错或结果文件内容。这类漏洞一旦确认基本是严重级别报告里要给出影响面推演但同样不需要实际执行恶意命令。3.4 前端漏洞别只看有没有弹窗XSS和CSRF在评分上不如越权和注入但也不能忽视。反射型XSS在很多平台可能只是个低危存储型XSS如果打到了后台或管理端价值就高得多。测试XSS时我会在可输入的位置构造一段无害的JavaScript比如弹出一个固定字符验证浏览器确实执行了然后提交说明。如果只是自己账号里的自XSS不建议提交绝大多数平台会直接忽略。存储型XSS要特别注意影响面看它被触发的位置是放在“所有用户可见”的页面还是只有管理员可见的评论区。前者一旦确认至少中危起步。CSRF在如今普遍使用Token的架构下越来越少但一些老系统或内嵌工具仍然存在。判断标准是关键操作请求中是否缺少不可预测的Token参数以及服务器是否校验来源。这类漏洞单独提交可能分不高但和其他漏洞组合使用时价值会放大。我自己的习惯是前端类漏洞宁可多花时间确认影响面也不要急着提交。3.5 文件上传与组件漏洞按版本打文件上传漏洞的核心是Web应用是否对文件类型、内容、后缀做了完整校验。测试时我用一个最简单的思路先传一个正常文件再传一个伪装后缀的文件比较响应差异如果报错信息里透露了校验逻辑就据此调整文件名和内容。确认能上传可执行文件且能访问到路径时漏洞基本成立。上传漏洞还有一个常见变体是编辑器历史漏洞比如某些富文本编辑器在旧版本中允许上传脚本文件。这类目标往往一眼就能识别如果指纹里看到老版本编辑器直接去组件漏洞情报库查相关历史漏洞。组件漏洞的方向则更直接拿到指纹后确认版本再查询公开的漏洞编号和修复建议。如果一个目标的组件版本长期未更新很多时候只需要把已有的公开漏洞描述翻译成当前场景的复现步骤就是一份合规报告。漏洞方向常见评分优先度测试注意越权高高证明可读即可不下载数据业务逻辑依损失而定高用自己的账号和最小金额注入高中只做存在性验证不拖库前端XSS/CSRF低至中中存储型才更有价值文件上传/组件依资产而定中对照组件版本4. 从拿到目标到提交报告一条完整可复现的路径4.1 用决策式流程代替盲目扫描在开始测试之前我会把目标资产划分成几条线Web应用、API接口、移动端。每条线再按“登录前”和“登录后”分两类。登录前更多地看信息泄露、未授权访问、登录接口的验证码与逻辑登录后则重点看越权、业务逻辑、上传和二次校验。然后按下面的顺序走先正常使用一遍应用把每个功能点都点一遍在关键功能处抓包记录请求参数针对参数名和值做小范围的修改测试最后再把异常情况往逻辑层面推演。这样做的最大好处是每次测试都有上下文不会凭空乱测。很多新手一上来就开目录扫描扫出几千条路径却不知道这些路径对应什么功能。目录扫描只是辅助真正有价值的线索永远来自对业务流的理解。所以建议流程是“先业务后扫描”扫描结果出现时才去验证而不是被扫描结果牵着走。4.2 最小复现与PoC设计能用三步证明就别写十步提交到SRC的报告本质是一份“最小复现说明书”。审核员每天要处理很多份报告如果你的复现步骤需要登录、切换账号、改十个参数、等五分钟缓存刷新大概率会被放到后面甚至忽略。我的习惯是在确认漏洞后花时间把复现步骤压缩到最简单形式用什么账号、访问哪个URL、改哪个参数、得到什么异常结果。最好可以给出一条请求、一个响应、一个说明。如果漏洞需要前置条件也尽量一句话说清楚而不是把整个测试过程原样粘贴。同时要遵守一个隐形原则不要为了证明危害而扩大影响。比如越权漏洞证明到了“能读取他人的订单概要信息”就足够清晰不需要把分页参数拉到最大去遍历所有订单。最小复现不仅是报告效率要求也是SRC玩家的职业素养。4.3 报告怎么写审核才容易通过一份容易通过的SRC报告信息层级是完整的第一行写明漏洞标题和风险等级第二段说明漏洞所在的URL、接口和参数再往下是复现步骤用简洁的序号列出最后是影响范围和修复建议。截图一定要包含关键请求和响应最好带上时间信息。有时候平台需要你说明“为什么这个漏洞会造成影响”这一点很容易被忽略。比如一个支付逻辑漏洞要写清楚“恶意用户可以通过篡改数量字段让优惠券无限使用导致平台资金损失”而不是只写“可以修改请求”。标题也别偷懒拒绝“某处漏洞”这种模糊表达。例如“某订单接口存在水平越权可查看他人手机号”就比“存在越权漏洞”清晰得多。审核员一看标题就能判断优先级也会更容易给你合理评分。把报告当成给同事的一份交接文档写清楚比写得多更重要。4.4 提交之后被忽略怎么办被忽略是SRC漏洞挖掘的常态。收到“忽略”时先冷静翻看平台给出的原因无非是三种漏洞影响面不成立、属于重复提交、优先级过低。如果确实复核后仍然成立可以在允许范围内发起沟通把影响分析重新梳理一遍用证据说话。但不要因为被忽略就抄着同一份报告换另一个目标提交。每个平台对漏洞的定义和关注点不同同样的反射型XSS在一个平台可能算低危在另一个平台可能完全不算。把精力放在下一轮更高质量的目标上才是更划算的选择。5. 工具链和配置长期实践沉淀下来的参考5.1 工具不必求多够用且顺手最重要阶段常备工具使用注意子域与资产子域枚举脚本、证书透明度查询、存活探测结合多个数据源交叉验证端口服务端口扫描工具用温和的参数避免打崩目标HTTP抓包Burp Suite正确安装证书掌握Repeater目录/接口目录爆破、模糊测试工具控制字典大小和并发移动端静态分析工具解密、分析配置文件后跟进接口工具多不代表强我见过有人电脑里装了几十个工具实际常用的可能还是Burp Suite加终端。工具选择的逻辑只有一个为了让某个测试步骤更快更准而不是为了展示装备。每当有一个新需求先思考“现有工具能不能覆盖”再决定是否引入新的工具尽量避免工具堆砌。5.2 Burp Suite的几处必要配置Burp Suite是SRC漏洞挖掘中绕不开的抓包工具。拿到新机器之后我第一件事是配置本地证书让浏览器和Burp之间能正确解密HTTPS流量。否则没有证书HTTPS请求全是密文后面的分析都没法展开。其次是学会用Repeater和Intruder。Repeater用来手动改包重发是越权测试和逻辑测试的主场Intruder用来做参数枚举和字典碰撞但要注意设置合理的速率。很多新手在Intruder里一次跑上万条字典目标直接限流反而把自己的测试卡死。另外把抓包过滤规则里的静态资源图片、CSS、JS、字体等排除掉能大幅减少噪声。Burp里还可以做响应高亮标记把包含敏感关键字如password、token、api_key的响应单独标色一眼就能扫到重点。这些配置都属于“一次设置、长期受益”的类型。5.3 字典和Fuzz策略少而精优于大而全目录爆破和参数Fuzz需要字典但字典不是越大越好。我的习惯是准备三套字典一套通用目录字典覆盖admin、api、swagger、api-docs、actuator、backup、upload这些常见路径一套参数名字典包含id、uid、file、url、path、type、status、role这类业务常用名还有一套文件和备份字典覆盖.git、.svn、.bak、.old、.txt等。使用时要克制并发。字典跑完一轮后先看返回包大小和状态码再对重点目标手工验证。不要在每个目标上都把三套字典跑满大多数系统只要跑到核心接口和常用管理路径就足以发现问题了。过度的Fuzz不仅低效还容易把目标侧的安全告警全部刷出来反而干扰后续测试。6. 实际测试中经常踩的坑以及我常用的排查方法6.1 提交被忽略的常见原因表现可能原因对策平台回复“已有重复”没先搜索历史漏洞提交前在平台重新测一遍相同姿势确认无重复报告回复“无影响”报告没写清楚业务影响补上损失场景和攻击路径推演回复“不可复现”复现步骤不够规范压缩步骤、附完整请求响应、注明前置条件直接低分目标非核心资产判断清楚资产价值后再决定投入6.2 遇到登录限制和图形验证码测试登录功能经常被验证码挡住。我的思路不是强行绕过而是先看验证码是前端校验还是后端校验。最简单的方法是本地看一下生成验证码的接口逻辑或者尝试把同一验证码复用一次看后端是否校验时间戳和会话绑定。如果验证码绑定不严格就会形成验证码复用或验证码可预测的逻辑漏洞这是可以提交的有效发现。如果验证码校验严格就不要硬碰把目标转到登录后的功能点。毕竟SRC平台要的是有效漏洞不是证明自己多能绕过验证机制尤其是“爆破登录”这种动作在多数授权场景里都不被鼓励。6.3 WAF拦截测试请求怎么办WAF识别出来之后常见选择是换一种更温和的测试姿势而不是硬碰硬。比如先用正常业务功能完整走一遍摸清输入点再针对具体参数做小范围测试减少批量恶意特征的暴露。WAF拦截本质上只是目标的一种防护机制绕过它不等于漏洞盲目寻找绕过路径可能把简单问题复杂化。如果多次触发拦截我的建议是先停下来过段时间再试。拦截记录可能已经进入目标侧告警继续测试只会让双方都难做。在授权范围内测试也要给对方带来不必要的负担这个分寸必须把握好。6.4 等级判断别把中危写严重也别把高危写低漏洞等级判断是报告的一部分。等级定得太高审核会有负面观感定得太低自己吃亏。我的参考标准很简单能直接导致资金损失、批量获取用户数据、服务器权限受控的往高危以上评需要依赖特殊条件或影响范围有限的给中低危纯反射型XSS、自用页面的信息泄露通常低危。最稳妥的做法是参考平台的历史公告和漏洞样例每个SRC都有自己的一套价值判断。多研究平台近期收录的漏洞类型再调整自己在报告中的等级描述通过率会明显提升。等级判断本身也是一个学习过程多对比几次真实报告和最终奖励很快就能建立起准确的直觉。7. 最后分享几条从实践中沉淀下来的真心话按我自己的体会SRC漏洞挖掘是一门“越往后越吃积累”的技术。前期最容易被工具和刷量诱惑中期开始理解业务后期才真正体会到资产梳理和逻辑推演的价值。如果让我给刚入行的朋友一个忠告那一定是先学会把一个目标测明白再想着测更多目标。还有一点做漏洞挖掘时留一份自己的笔记记录每轮目标的测试状态、发现过的接口、踩过的坑。这比任何教程都有用因为笔记会随着你的经验自动定制成长路线。每次从旧笔记里翻到一段当时没看懂的技术细节再回头验证时理解会深很多。合规是底线也是长期主义的基石。SRC漏洞挖掘真正的职业价值在于你既具备攻击者思维又懂得用最克制的动作去证明问题。守住授权边界尊重平台规则你的每次测试才会越走越稳而不是越走越窄。
阅读完成 · 觉得有帮助？
