接手SRC运营和漏洞挖掘这些年我最大的感受是真正能稳定产出高危漏洞的人靠的从来不是运气也不是无脑跑一遍扫描器而是对攻击面的理解和对业务逻辑的敏感度。很多新人一上来就打开Burp抓包看到参数就往里塞SQL注入和XSS payload折腾一晚上最后交上去一个中危甚至低危审核还被驳回。反观那些SRC榜上靠前的人他们更像是在做一场有准备的狩猎先把目标资产摸得明明白白再挑最可能出问题的业务逻辑下手一发命中直接击穿防线。这篇文章我想把自己在SRC漏洞挖掘实战里的完整思路拿出来复盘重点是两件事攻击面管理和业务逻辑漏洞的精准确认。前者解决“测哪里”的问题后者解决“怎么测才值钱”的问题。适合刚入门半年、已经会基础Web漏洞利用但产出不稳定的朋友也适合企业安全团队里负责SRC运营和自测的同学参考。1. 攻击面管理所有漏洞都藏在“被遗忘的资产”里1.1 为什么做攻击面管理而不只是资产枚举很多人觉得攻击面管理就是收集子域名、扫端口、跑指纹其实这只是个起点。我理解的攻击面管理核心是搞清楚三件事目标系统对外的边界到底在哪里这些边界里哪些页面承担了核心业务逻辑以及哪些入口被有意无意隐藏了起来。SRC测试和普通渗透测试最大的区别就在这里普通渗透可以什么接口都打一打但SRC是有授权范围、有规则约束、有业务边界的你只能在厂商给的范围和作用域里打不能越过红线。所以攻击面管理在SRC场景下更准确的说法是“在合规授权前提下把允许测试的所有资产梳理成一张可用地图”。只有把地图画清楚了后面找业务逻辑漏洞才不会漏掉关键的页面。很多高危漏洞都出在连主办方自己都忘了的旧接口、测试环境页面、后台管理入口、开发调试API上这些恰恰是扫描器不容易发现的也是业务逻辑漏洞最容易藏身的地方。1.2 攻击面梳理的完整流程我的习惯是分四个步骤走域名与资产收集、端口与指纹识别、Web目录与API提取、入口分类与价值排序。每一步都有对应的工具和注意点我具体展开说说。域名与资产收集方面除了常见的子域爆破工具我更依赖证书透明度日志和备案信息。证书透明日志能查到很多没有在DNS里公开记录的子域这些往往是对外测试环境、灰度环境或者老系统的域名。备案信息则能帮你把目标集团旗下其他品牌的域名一起纳入视野很多SRC平台是按整个集团来算奖励范围的你只盯着主域名很容易错过集团下面其他系统的漏洞。端口与指纹识别这里我习惯先用轻量级的端口扫描确定哪些端口开放了HTTP/HTTPS服务再用指纹工具确认中间件、框架、服务器类型。这一步不用太贪多关键是搞清楚哪些端口是Web服务哪些是数据库或中间件管理端口。如果发现测试环境直接暴露了管理面板那后面值得重点记录因为这类管理后台如果存在弱口令或者未授权访问往往直接就是高危。Web目录与API提取是攻击面管理里最容易被低估的一步。很多业务逻辑漏洞的入口并不在导航菜单里而是藏在JavaScript文件里的接口地址。我会用爬虫把目标站点的所有JS文件拉下来再用正则提取里面的URL、API路径、参数名这一步能发现不少隐藏接口。还有个细节是看JS文件里有没有调试用的开关比如debugtrue、test1这种参数有时候改一个值就能让服务端返回完全不同的逻辑。入口分类与价值排序是攻击面管理的最后一步。我会把所有收集到的入口整理成一个表格标注入口类型、所属业务模块、是否需要登录、是否存在参数交互、以及初步判断的价值。价值判断依据是这个入口如果出问题会造成什么影响能改别人数据、能未授权访问后台、能操纵资金或订单那就优先级很高如果只是一个纯静态页面价值就低一些。这步做好后整个测试方向就非常清晰了。入口类型典型路径优先级判断依据登录/注册/找回密码/login, /register, /forgot认证相关优先级最高用户中心/个人资料/user/profile, /member存在越权和信息泄露可能订单/支付/退款/order, /payment, /refund资金相关业务逻辑高危区后台管理入口/admin, /manage未授权访问直接高危API接口/api/v1/xxx需关注鉴权是否一致文件上传与下载/upload, /download文件型漏洞高发区第三方回调/callback, /notify容易伪造逻辑绕过点1.3 攻击面地图的优先级排序方法收集完攻击面之后我不建议立即开始盲测而是先做一轮排序。排序的核心逻辑是“业务重要性×可达性×参数复杂度”。业务重要性决定漏洞的上限比如订单支付模块出问题可能就是严重可达性决定测试成本一个不需要登录就能访问的接口明显比藏在五级菜单后面的页面更值得先测参数复杂度决定漏洞概率接口参数越多、越复杂越容易有逻辑考虑不周全的地方。排序的时候我还会特别留意一种情况同一个功能在两个入口都有实现一个做了校验另一个没做。比如Web端下单时校验了金额和库存但App端的对应接口没校验这不就是典型的横向越权加业务逻辑漏洞的温床吗攻击面管理做到位了这种双入口对比的思路自然就会浮现出来。所以不要只收集资产然后拉倒一定要带着“哪里可能有两个入口、哪里可能有新旧版本并存”的视角去看地图。2. 业务逻辑漏洞从攻击面到精准狩猎的转场2.1 业务逻辑漏洞为什么是SRC高危的主力攻击面是地图那业务逻辑漏洞就是宝藏。SRC平台对SQL注入、XSS这类通用漏洞的审核越来越严格一方面因为这些漏洞很多人都在测很容易重复另一方面很多厂商都已经上了WAF和代码审计通用漏洞的生存空间在被压缩。但业务逻辑漏洞不一样它依赖的是厂商自己的业务规则和实现代码每个系统都不一样第一批测试的人挖到就是独有的重复概率远低于通用漏洞。更重要的是业务逻辑漏洞往往能直接打穿业务本身。比如你通过修改负数的购买数量把订单金额变成负数或者通过修改用户ID越权查看别人的订单这种漏洞的影响是立竿见影的审核方很容易理解你的严重性定级给高危甚至严重都不奇怪。而且这类漏洞无法用通用扫描器发现必须靠人去理解业务链路所以这正是SRC挖掘里最值得投入精力的方向。2.2 业务逻辑漏洞的六大经典模式从实战归纳来看绝大多数业务逻辑漏洞跑不出这六种模式身份验证与授权绕过、流程顺序篡改、请求参数篡改、并发与条件竞争、状态机异常、业务数据可信校验缺失。我用大白话逐一讲讲。身份验证与授权绕过是最好理解的一类。你登录一个普通账号结果能访问管理员的接口这叫垂直越权你能查看或修改另一个普通用户的数据这叫水平越权。这类漏洞的根源是后端接口没有校验当前用户的权限只信任了前端传过来的ID号。我见过很多电商平台一个订单详情接口把订单号换成别人的就能看到别人的姓名、电话、地址这数据量一累积问题就严重了。流程顺序篡改是指原本必须按步骤走的业务流程你跳过了某一步。比如正常的购买流程是选商品、确认订单、支付、回调通知结果有平台因为支付回调接口没做验证攻击者可以直接伪造一个支付成功的通知跳过真实支付订单就变成已支付状态。还有投票、抽奖、签到这类活动先判断是否能参与再走流程但如果你直接调用后续接口有时候就能绕过参与资格校验。请求参数篡改最典型的就是金额和数量。下单时把单价改成0把数量改成负数把优惠券金额改成超过订单金额这些都属于参数篡改。开发同学如果只在前端页面做了价格校验后端没有重新计算这类漏洞就很容易被利用。这里的重点不是参数本身而是后端是否完全信任了前端提交的数据。并发与条件竞争是近两年SRC里很火的方向。简单说就是同一时间发大量请求绕过对某个状态的校验。最经典的就是电商平台的优惠券领取或账户充值服务端先查余额发现是0然后进入加钱逻辑但由于没有加锁你同时发100个请求全部通过了“余额为0”的检查然后每个请求都加了10块钱结果账户多了1000块。这就是典型的并发竞态漏洞。状态机异常是指业务流程在某个状态下做了不该做的事情。比如订单已经退款了但系统还允许你继续申请售后一个抽奖活动已经结束了但接口还能继续抽奖。很多状态流转的判断依赖一个布尔值或者一个枚举值如果服务端没有在每个状态节点都做校验就存在状态跳跃的可能。业务数据可信校验缺失说白了就是后端把不该信任的外部数据当成了可信数据。比如把用户输入的JSON、XML、跳转地址、回调地址直接拿来用没有做白名单校验。最经典的场景是支付回调回调里带了订单号和支付结果如果服务端只校验签名不校验订单归属你就能用自己的订单状态影响别人的订单。还有一种常见情况是跨业务线数据串用比如A应用的token拿去访问B应用的接口如果鉴权体系没打通就可能造成越权。2.3 如何挖掘业务逻辑漏洞思路与切入点挖掘业务逻辑漏洞核心方法论就八个字梳理链路、对比差异、突破边界。这不是什么高深理论而是实操者的经验总结。先梳理链路。以电商下单为例完整链路是登录-浏览商品-加入购物车-提交订单-选择支付方式-支付-支付回调-订单状态更新-物流发货-确认收货。你要先把这条链路的每个节点列出来再挨个问这个节点是从哪里接收数据的谁生成的数据数据是否被校验校验是在前端还是后端链路梳理得越细找漏洞的抓手就越多。再对比差异。对比不同角色普通用户和管理员、不同入口Web端和App端、不同版本新旧接口之间的差异。差异的地方就是漏洞可能藏身的地方。比如同是修改用户昵称Web端传的是nicknameApp端传的是user_id加nickname这就不一样了App端那个接口可能就没做归属校验。最后突破边界。突破边界的意思是在正常操作之外试着给参数添加一些“计划外”的值。比如正常金额是正整数你试试负数、0、极大值、浮点数、字符串拼接、数组传参。比如正常商品数量是1你试试0.5、-1、99999999。这些“计划外”的值最容易让后端处理逻辑崩溃或者产生非预期结果。提示挖掘业务逻辑漏洞时一定要把目标当成一个“有业务规则的系统”而不是一堆HTML和接口的堆砌。你要站在开发者的角度想如果我来实现这个功能哪些地方我只做了前端校验哪些地方我可能会偷懒不校验这些偷懒的地方就是你的突破口。3. 精准狩猎实战一个完整的SRC挖漏洞流程复盘3.1 前期侦察与目标选定拿一次考核来举例目标是一个电商类SRC平台本身名气不算大但是用户量还可以注册用户可以下单、领券、充值。按照第一部分的方法我先做了攻击面梳理。子域收集阶段发现了一个很奇怪的双字母子域看起来像是内网网关旁挂的一个老系统直接访问能打开一个只有登录框的页面。指纹识别显示这个页面用的是某老版本PHP框架登录框下方的版权信息写着“只限内部测试使用”。这个入口我直接标了高分因为内部测试系统往往没有严格的权限校验甚至可能有固定的测试账号。注册了一个普通用户之后我先把能用到的正常功能全部走了一遍改头像、填收货地址、下单、领券、取消订单。每一步都开着抓包工具记录下来。走流程的主要目的不是找漏洞而是理解这个系统的正常业务规则长什么样。你连正常流程都不清楚怎么可能判断出哪里是非正常的3.2 挖掘过程的关键尝试与思路转化在下单流程中我发现了一个很有意思的细节提交订单时前端请求里带了两个参数一个是sku_id商品编号另一个是price商品价格。价格参数我一眼就注意到了很明显这是前端把商品单价传给了后端。我第一反应是如果后端直接用这个price来算总价那就是参数篡改漏洞了。于是我找一个便宜的商品抓包把price改成0.01元提交订单结果订单结算页真的显示应付0.01元。我继续支付了一分钱订单状态变成已支付后台模拟出库正常流转。到这里我已经确认了一个高危候选但我没有立刻提交而是继续往深处打了几个组合拳。我试着把price改成负数比如-1元结果更离谱订单价格算出来是负数结算页显示“应付金额-1元”系统甚至提示我支付时可以获得1元退款。这就是典型的业务数据可信缺失后端完全没有对price参数做范围和类型校验。我立刻把这个链接到了“影响资金安全”这个严重性判定上明确了这会带来资金损失风险。同一平台上我又顺藤摸瓜测了优惠券模块。领券接口返回了一个券码提交订单时带上券码再改一个优惠金额参数原本5元的优惠券被我改成了500元系统也照单全收。这进一步证实了后端对订单金额计算链路的校验形同虚设。我接下来把整个订单生命周期里的参数都整理了出来重点标注了哪些是前端可控的、哪些是后端生成的做了一张对比表这为后面的报告编写打好了基础。3.3 复现验证与影响范围确认挖到这一步还不能松懈关键的打法已经找到但影响范围必须确认好。我先用了两个账号做交叉验证。账号A发起一个删除收货地址的请求抓包后把address_id换成账号B的地址ID结果A的请求成功删掉了B的地址这就是水平越权这两个漏洞叠加在一起伤害值直接拉满。为了验证影响是否覆盖所有用户我再看了一下接口文档和前端JS代码发现接口路径里带了一个/api/v1/的版本标识新老版本接口同时存在。我顺手测了一下老版本的接口发现老版本的数据校验更松连登录态都可以不怎么校验。这下影响面就不只是某一个功能了而是整条订单和用户链路都存在越权和参数篡改问题。SRC审核方看到这种影响面大概率会给一个高分定级。在复现时我注意了一个原则能用最小权限、最少数据量验证就绝不扩大测试。比如修改价格我选的是平台上标价最低的商品目的就是证明漏洞存在而不是想着怎么薅羊毛。不要为了展示危害真的把大量券领走或者真的删掉别人的核心数据一旦越过了测试边界性质就变了。这个底线在SRC挖掘里非常非常重要。3.4 编写报告的关键细节报告写得好不好直接决定了你的漏洞被定级为严重还是被退回这里面的门道不少。我提交报告遵循一个固定结构漏洞名称、漏洞等级、涉及域名与接口、漏洞描述、复现步骤、影响范围、修复建议。每一部分都有讲究。漏洞名称强烈建议直接点名业务影响比如“订单接口未校验价格参数导致任意金额下单支付”而不要写“价格参数可控”。前者一眼就知道严重性后者还需要审核方自己去脑补业务影响体验差距很大。漏洞等级也要结合业务影响来写你能影响资金、越权访问数据就往严重了评但要有论据支撑不能瞎写。复现步骤要精确到每一步的输入和输出最好附上抓包截图和请求响应对照我还会把关键的请求报文格式化成可复现的文本方便审核方直接复测。修复建议这块很多新人容易漏掉或者写得比较敷衍。我的看法是提建议要贴合具体代码逻辑。比如这个订单金额问题你要建议的不是空泛的“加强防护”而是具体到“服务端应重新从数据库读取商品价格计算订单金额忽略前端传入的price参数金额类型应使用整型分而不是浮点元对价格和数量参数做上下限与正数校验”。审核方看到这种建议会明显感觉你是认真分析过的。3.5 与厂商审核的沟通经验报告提交之后审核周期一般在几天到几周不等。如果遇到审核方不理解漏洞原理我会主动根据对方反馈补充演示数据、重新整理流程甚至录一个短视频展示如何从头复现。不要觉得这是在麻烦你实际上每一次跟审核方的沟通都是拉高漏洞定级的机会前提是你的漏洞是真实有效的。这里有几个沟通的节奏要点提交后如果一周没动静可以在SRC平台上礼貌地问一句审核进度如果审核方反馈说无法复现第一时间重新自查是不是环境变化导致然后把每一步重新跑一遍带着操作录屏或更详细的报文回复如果对方问了漏洞影响范围干脆利落给出具体的数据量和受影响的用户量不要含糊其辞。整个沟通始终围绕“真实、准确、可复现”这三个词展开审核方是不会亏待这种报告的。4. 常见问题与排查技巧实录4.1 SRC挖漏洞日常踩坑记录我见过太多人在SRC上栽跟头踩的坑无非就那几种。最常见的一个坑是看到啥测啥完全没有梳理攻击面就开始扫描和payload轰炸结果不是测了一堆重复漏洞就是测到了授权范围之外的资产。还有一种是不做登录态管理明明可以访问后台或用户中心却只测公开页面白白浪费了宝贵的攻击面。另一个坑是不会抓关键节点。很多人抓包只会看请求头和请求参数看响应只看状态码完全不关心整个业务流程存在哪些可信边界。你看到的是一个一个孤立的HTTP包人家看到的是购物车、订单、支付、售后整条链路上可能存在的校验缺失这两种视角的产出差距是巨大的。再有一个高频坑是工具依赖过重一门心思用扫描器跑全站结果被WAF封了IP还被平台警告。扫描器不是不能用但它只能帮你完成攻击面发现的阶段真正让漏洞值钱的还是人对业务逻辑的思考和验证。有些平台对自动化扫描有明确限制测试前一定要看清SRC的规则说明别辛辛苦苦扫出来的漏洞最后因为违规操作被判定为无效。典型问题常见原因解决思路提交的漏洞被标记为重复只测了通用公开入口没有深入业务链路从攻击面地图中找新入口多测业务逻辑报告被忽略或退回复现步骤含糊影响描述不清晰报告按固定结构写带请求响应和截图测试过程中被封IP或验证码扫描频率过高单IP大量请求控制测试频率必要时使用代理池但注意合规挖了很久没有高危一直在重复测老页面和通用漏洞重新梳理攻击面优先测认证与业务交互接口审核回复无法复现复现依赖于当时的脏数据或登录态优化复现步骤提供完整环境前置条件4.2 如何有效收敛自动化扫描的风险SRC测试里搞自动化要有分寸。我的经验是针对单一URL可以用低频扫描比如设置线程数不超过5每个请求间隔至少几百毫秒如果目标站点有验证码或限流机制要主动降低请求频率。曾经碰上过某目标只在凌晨2点到5点放开测试流量的限制白天一旦频率高就弹出滑块验证整批代理IP全被拉黑血泪教训。除了频率还要控制测试范围。自动化扫描前务必配置好作用域匹配规则只允许访问授权范围内的域名和IP。曾经有次我跑目录扫描时脚本跟着响应里的一个外链跳到了第三方的CDN域名幸好巡检及时拦住不然后果不好说。做SRC测试边界意识要刻在骨子里宁可少测两个目录也不要让流量越过授权范围。4.3 排查业务逻辑漏洞时的高效姿势业务逻辑漏洞的排查思路我总结了一个三步走的习惯基本可以应对绝大多数目标。第一步是列“操作链”。把目标的每个核心业务线注册登录、下单支付、优惠营销、售后申诉、后台管理等全部列出来每条线画出从开始到结束的所有状态节点和动作节点。哪个节点涉及钱、哪个节点涉及权限、哪个节点涉及数据返回全部标注清楚。第二步是对“角色权限集”。整理目标系统有哪些角色比如游客、普通用户、VIP用户、运营、客服、管理员。然后在每个节点上问一个问题这个节点的操作是否判断了当前角色是否允许做如果没判断或者判断条件可以绕过那垂直越权或水平越权的机会就出现了。最典型的就是修改个人资料时把角色参数从member改成admin如果后端只判断前端传参里的角色字段漏洞就出来了。第三步是试“异常输入集”。对每个关键参数按类型、范围、符号、逻辑四个维度构造异常输入。类型上试字符串、数组、JSON对象、数字浮点范围上试负数、0、极小值、极大值、越界值符号上试、-、%、空值、null、Unicode特殊字符逻辑上试重复请求、并发请求、乱序请求、过期重放请求。这一步工作量最大也是最需要耐心的但往往就是某个异常输入触碰到了开发逻辑里没考虑到的分支。4.4 如何判断一个漏洞是否值得提交判断漏洞是否值得提交我有几条硬性标准。第一是影响真实性你要能证明漏洞可以产生实际影响而不是你臆想出来的影响第二是影响独特性如果这个漏洞全网其他人都已经提交过一百遍了你那就是浪费时间第三是漏洞可达性攻击者是否真的能在合理权限下触发第四是危害可量性能不能用“可以读取多少用户数据”“可以造成多少金额损失”“可以操作多少账户”这种量化的语言来描述。只要这四条里有两条成立我就认为这个漏洞值得打磨后提交。如果四条全中那基本是必高危的种子选手。这里我要强调一句很多新人容易把“有影响”和“有价值”混为一谈。比如你发现后台登录页面可以爆破理论上算是有影响但既然你已经处于后台登录页面前在没有其他条件配合时这种影响不足以支撑一个高分漏洞。真正有价值的漏洞是能够走完一整条攻击链的比如“未授权接口获取手机号批量遍历用户ID垂直越权访问后台”三个问题串在一起说服力就出来了。5. 测试范围与合规边界每位测试者都必须守住的分寸5.1 为什么SRC挖掘不能踩到业务红线SRC注册时都有一份平台规则里面明确定义了允许测试的范围、禁止操作的行为、以及漏洞提交的格式。绝大多数SRC都明确规定禁止测试生产环境中的恶意攻击行为禁止获取或篡改真实用户数据禁止批量扫描禁止利用漏洞获取不当利益。这些规则不是摆设一旦违反轻则漏洞作废、账号封禁重则影响个人信誉甚至触及相关管理规定这个后果没有任何一个漏洞奖励值得去冒。实战操作里我给自己划了三条硬边界。第一条绝对不读取、不下载、不修改真实用户的非授权数据。即使测试中偶然发现数据返回也只是为了证明漏洞影响能证明就行不扩大接触范围。第二条绝对不对业务系统做破坏性的操作比如删除核心数据、清空数据库、恶意消耗资源、利用漏洞提现等。第三条绝对避开涉及资金转移、已支付订单改价、敏感个人信息拿取等可能引发严重后果的操作一旦确认漏洞存在影响已成立就立刻停止。5.2 授权范围之外的不碰原则SRC平台一般会给一个明确的测试对象范围域名、IP段、特定系统都会列出不在范围内的资产一律不碰。有些测试者在信息收集时会发现和主站在同一台服务器上的其他站点看起来很像“顺带可以测试的目标”甚至资产指纹显示同一个中间件或同一个CMS。这种情况哪怕技术上很容易打也不要去碰因为你没有授权超出授权范围的测试就是不规范行为哪怕测试结果再厉害也不值得。范围管理不只是为了合规也是为了保护你自己。我早期曾有次碰到一个边缘子域没有明说是否在该SRC的测试范围里因为疏忽直接测了一个SQL注入点虽然没有造成破坏但平台方看到流量告警后追查过来沟通成本极高还差点导致之前所有有效漏洞被清零。从那以后每次测试前我都会先把域名列表和IP段列表爬出来逐一比对SRC的授权范围不在清单里的一律不测。这已经不是防守策略而是职业习惯。5.3 从单一漏洞到攻击链的价值提升合规边界内能让漏洞变得更有价值的方向是攻击链串联。发现一个越权接口后顺着这个接口往深走一层看能不能摸到管理员接口找到一个未授权数据接口后看能不能跟其他功能串联实现更高权限的操作。攻击链的每个点单独看可能只有中危串起来可能就是高危甚至严重。而且这类报告天然具备不可重复性审核方也会更认真对待因为攻击链往往比单点漏洞更能还原真实攻击者的行为。我需要提醒的是串联攻击链的时候同样不能越界。用几个低危漏洞拼出一个高危的攻击路径没问题但如果中途需要碰到真实用户数据才能证明那就必须停止。证明影响范围的方式很多你完全可以自己注册两个测试账号、构造测试数据来模拟不一定非要动真实的业务数据。只要漏洞的触发逻辑清晰、条件明确审核方不会因为你在测试环境复现就降低定级。6. 写在最后从“挖洞工具人”到“业务安全思考者”SRC漏洞挖掘这条路越往后走越会发现真正拉开差距的不是手里有多少工具、脚本跑得有多快而是理解业务的能力。有一天你能从业务规则的角度预判开发会在哪里偷懒、在哪里信任了不该信任的输入、在哪里因为历史遗留问题留下了双入口你就不再是单纯拿着Burp的测试者而是一个能站在整体业务视角思考安全的人这个转变之后发高危漏洞会变成一件越来越自然的事。我个人在实际操作中的体会是每次碰到一个新SRC平台先别急着去试漏洞花一到两天时间把业务链路和攻击面地图彻底吃透甚至比直接开测的产出高出不少。攻击面管理解决广度业务逻辑漏洞思路解决深度报告编写和合规意识解决的是这条路能走多稳。希望这套流程能给你的SRC挖洞之路带来一些启发也期待在某个榜单上看到你的名字。