业务驱动挖金融SRC：从逻辑漏洞到越权的高价值挖掘思路

做金融SRC这五六年我最大的体会是漏洞挖掘的瓶颈往往不在工具而在你对业务的理解深度。同样一批人手里工具差不多漏洞库也差不多但产出高价值漏洞的能力可以差出好几倍。通用扫描器擅长发现组件版本漏洞和已知CVE而金融SRC里真正值钱的问题绝大部分集中在业务流程的逻辑环上一个接口没做归属校验、一个订单状态可以被重复消费、一个金额判断只发生在前端。你把业务链路拆得越细越能发现这类问题。这篇内容就围绕“业务驱动”这条主线聊聊我自己的金融SRC高价值漏洞挖掘思路。先定个调子所有测试必须基于SRC官方的明确授权SRC本身就是厂商对外收集漏洞的受控渠道测试范围、禁止事项都写在规则里我们只在这个边界内验证问题。接下来讲的方法都是在这种合规前提下沉淀的。1. 金融SRC里的“高价值”到底怎么定义1.1 先弄明白SRC在奖励什么SRC本质上是一个厂商自建的外部安全测试通道。安全研究者发现问题后按规范提交厂商审核确认后给积分、奖金或者其他形式的奖励。对厂商来说相当于用可控成本换取持续的外部测试力量对白帽子来说是在真实业务环境下合法练手、积累经验、获取回报。金融类SRC和普通互联网SRC的差异集中体现在资产属性上。金融业务的核心资产是资金和个人敏感信息这两类东西一旦出问题后果不是“品牌声誉受损”能概括的可能直接是真实财产损失、账号资产被盗、大规模隐私泄露甚至触发监管事件。因此金融SRC对漏洞的响应速度和奖励力度通常高于普通平台同时对测试行为的约束也更严格。理解了这个背景才能正确把握“高价值”的定义。它不是说漏洞名称听着吓人就有价值而是要看它是否真正碰触到资金、账户、敏感数据这三条核心资产线。1.2 钱、账户、数据金融场景的三张资产清单我习惯把金融业务的核心资产抽象成三张清单排查时对着清单找问题而不是漫无目的地扫接口。第一张是资金清单。包括支付下单、余额变更、充值提现、转账汇款、退款、优惠券、积分、红包、理财赎回转出这类直接涉及钱的流程。任何一个环节出现校验缺失都有可能被改写成资金损失或资金篡改风险。第二张是账户清单。包括注册、登录、找回密码、实名认证、绑卡、换绑手机号、修改支付密码、登录态管理这类身份与凭证链路。账户环节的漏洞往往能升级为账户接管破坏力比单点技术漏洞大得多。第三张是数据清单。包括用户资料、交易流水、绑卡信息、授信额度、借款记录、风控特征等敏感数据。金融系统里的数据泄漏不是简单丢一个字段经常是手机号、身份证号、银行卡号批量一起出去。判断一个漏洞是否高价值先问它对这三张清单有没有实际影响。一个任意文件读取在普通博客系统里可能只是中危但如果读到了加密密钥、数据库连接配置、支付回调密钥在金融系统里基本就是严重级别。同样一个名字的漏洞在业务链路上的位置决定了价值这就是业务驱动判断和纯技术判断的差别。1.3 业务驱动思路和通用挖洞思维的差别通用挖洞思维通常是这样的先收集资产然后扫描端口、指纹、组件版本凭已知漏洞库比对发现匹配项后验证利用。这套流程适合快速覆盖大量目标但在SRC场景里能拿到的高价值结果非常有限。原因很简单大厂金融业务的组件补丁速度通常不慢公开的通用漏洞往往已经被关注和修复剩下的大概率是小众版本或配置问题奖励级别也不会太高。业务驱动思路走的是另一条路选定一个真实业务功能顺着资金链路走一遍观察系统在哪些关键位置信任了不该信任的输入哪些判断只存在于前端或只在某一个环节做了校验哪些状态可以在业务流程中被逆序、重复、并发触发。可以打个比方。通用思路像拿着金属探测仪在停车场满场扫能发现遗落的钥匙但发现不了“某道侧门根本没接入监控系统”。业务思路像先看懂停车场的出入口、缴费流、人车分流逻辑再推演哪条通道可能被异常绕过。前者依赖装备覆盖率后者依赖对运行逻辑的理解。SRC拼到最后拼的是后者。2. 把业务拆开金融系统的可测点是这样梳理出来的2.1 一条主线从注册到提现的完整资金链路对任何金融App第一步都不急着测接口而是先走通一遍完整业务流程。这条主线至少要覆盖注册、登录、实名认证、绑卡、充值、购买产品或者下单、支付、提现、退款以及注销或者换绑。每一步都要记录页面调用了哪些接口、传了哪些参数、返回了什么字段。这一步的价值是低成本的。你只是把App当普通用户用了一遍但抓包工具已经把整个核心链路的所有请求都记下来了。接下来做接口分析、参数修改、状态回滚测试都是在这些真实业务请求上改不会凭空去猜接口路径。走主线时还有个习惯对每个关键接口记录三样东西。一是请求参数里有什么可疑的自定义字段比如金额、数量、用户ID、状态码二是响应里是否比页面展示多返回了字段比如多返回了手机号、内部用户编号、风控标记三是这个接口是否有独立的鉴权逻辑还是完全依靠前置页面做了隐藏。2.2 在流程节点上找异常分支主线是太阳异常分支才是要找的金矿。金融业务里我更关注这几类异常分支。第一类状态反复。一个订单支付成功后能否再次支付退款完成后能否再次发起退款撤单后能否重新确认登录失效后原token是否还能调用部分接口这类问题的本质是状态机设计得不严密一个状态允许了重复流转。第二类边界条件。金额能不能传0、负数、小数、超长数字数量能不能传很大分页参数能不能传超大偏移量很多逻辑漏洞就是后端没有对业务参数做二次校验前端页面限制了但接口没限制。第三类身份边界。普通用户操作时接口是否校验了资源归属请求里修改用户ID、订单号、卡号能否访问到别人的数据这些是越权类漏洞的土壤。第四类信任边界。前端隐藏按钮或者置灰状态能不能被强行触发图片、附件、回调地址这类输入是否会被篡改是否所有关键决策都由后端完成而不是依赖前端参数整理成表格会更直观流程环节典型异常风险注册 / 登录批量注册、撞库、验证码绕过、登录态盗用实名认证 / 绑卡四要素绕过、他人身份冒用、绑定关系越权充值 / 提现金额篡改、提现账户篡改、提现状态回退下单 / 支付价格篡改、数量篡改、支付回调伪造、重复支付优惠 / 积分重复领取、并发刷取、叠加规则突破退款重复退款、退款后资金状态不一致借款 / 授信额度越权、审批状态篡改、风控绕过消息通知短信轰炸、验证码内容泄漏每张表里的风险点都还能继续往下拆但第一步先把这些场景列出来测试时就有明确方向了。2.3 用功能入口反推接口不靠盲扫很多新人喜欢拿到域名就直接上扫描器这是效率很低的做法。金融系统往往有全流量监测、WAF、风控拦截扫描行为本身就可能触发风控不但测不出东西还可能把账号和IP搭进去。更高效的方式是以业务功能为入口正常操作一次把流量抓下来。抓包数据里有真实的API路径、参数结构、接口鉴权方式这些比扫描器枚举出来的路径有价值得多。除此之外还可以看前端JS文件很多管理端入口、隐藏接口会出现在JS文件中PC端Web系统尤其明显登录后的JS包里经常能翻到完整的后台API清单。移动端App可以看客户端代码里的API配置。我这里不做具体工具推荐但要提醒一个原则拿到任何接口先判断它是不是当前用户身份可以访问的再判断当前会话的权限边界。不要尝试越权访问SRC规则里明确排除的管理后台、内网地址或其他企业资产只测授权范围内的目标。2.4 可测点优先级排序业务功能梳理完会得到一大张接口清单。不可能每个点都花同等精力必须排序。我的排序公式是优先级 资产影响 × 可利用难度 × 被业务复用的概率。资产影响看是否关联资金或敏感数据可利用难度看是否只需要改一个参数、不需要复杂前置条件被业务复用的概率看这个接口是否在核心链路里被高频调用。按这个公式支付下单、转账、提现、绑卡、验证码下发、订单状态更新、借款授信这几个点永远排在最前面。它们要么直接动钱要么直接影响账户状态而且每个请求都是用户真实路径的一部分不需要额外前置条件。相反一些只有管理端才会调用的接口即使影响很大因为触达难度高、可能触犯授权边界通常放在后面慎重处理。3. 高价值漏洞的主要类目与实战判级原则3.1 业务逻辑漏洞金融SRC里最容易被低估的那类业务逻辑漏洞是我在金融SRC里投入精力最多的类目。它不是靠版本比对发现的而是靠流程推演发现。常见形态有优惠发放逻辑可被重复消费、订单状态可被回退后再次支付、退款流程结束后资金状态错乱、转账金额校验只在页面层完成、绑定关系可被覆盖替换。举一个典型的场景。某金融平台做了一个新用户注册送体验金的活动常规校验是“每个手机号领取一次”。但从业务驱动的角度去拆要问的是这个“每个手机号”的判断放在哪一层如果只在前端页面做标记直接调用领取接口是否会绕过如果后端有判断判断是基于手机号还是基于用户ID当接口被并发请求同时打到时两个请求都查到“未领取”是否都会放行这一系列问题才是逻辑测试的关键。注意做这些验证要控制影响。我的做法是优先使用自己在平台上注册的虚拟测试账号金额类测试只做最小单位验证绝不在生产环境里制造真实资金流水。测试的目的是证明漏洞存在、影响可控而不是把这个逻辑缺陷放大到造成实际损失。3.2 越权类漏洞金融系统里的高频高伤越权是金融SRC里提交量最大的高危类别之一同时又经常被新手漏掉因为它的测试方式非常基础登录两个自己在平台上注册的测试账号用A账号的请求凭证访问B账号的资源。水平越权在金融场景里很典型订单查询接口、交易流水导出、理财持仓查询、绑卡信息查看、地址管理如果接口只校验“是否登录”而没校验“是否资源归属者”那么任意登录用户都能读取他人数据。这种问题一旦出现在银行卡号、身份证号、交易流水上定级基本就是高危以上。垂直越权相对少见但更严重。普通用户访问管理端接口查看审核列表、风控规则配置、用户资金调整接口。这类验证要特别谨慎如果SRC规则没有明确允许测试管理端就不要主动越权尝试而是把“疑似存在暴露的管理接口”作为线索写进报告由厂商确认。合规边界永远排在技术验证前面。3.3 账户与认证链路上的风险点账户认证类问题直接影响账号是否会被接管。几个典型方向验证码类。短信验证码长度是否足够、有效时间是否合理、接口是否有频率限制、验证码是否绑定手机号和会话。金融系统里经常出现测试环境验证码固定、验证码不失效、验证码在下发时直接返回在响应里这类问题。登录类。登录接口是否有暴力破解防护输错密码是否触发锁定或者延迟是否对同一IP、同一设备、同一账号做多维限速。这里要注意测试只做有限次验证确认限速机制是否存在即可不要真的跑字典。找回密码类。验证方式是否可被跳过、重置凭证是否可预测、重置后旧会话是否失效。密码找回链路经常被拆成多个接口很多漏洞是某个接口只验证了前置参数、没验证会话来源。支付类认证。支付密码是否可绕过、免密支付开关是否可被篡改、更换设备时是否有二次验证。账户里动钱的环节任何一道认证被绕过都是严重。3.4 数据接口与信息泄漏金融系统中敏感数据批量暴露的价值非常高但很多时候不是以漏洞的形式出现而是以“设计如此”的形式出现。比如一个查询交易流水的接口响应里同时返回了预留手机号、银行卡后四位、证件号脱敏字段这些字段如果与前端展示无关就可能是敏感数据过度返回。测试方向很明确关注响应包里的字段尝试修改分页大小或偏移量关注文件导出类接口是否有权限校验。一个接口如果能导出全部用户的交易明细就是严重的批量数据泄漏。发现这类问题要特别注意证据处理截图先脱敏不要完整展示他人真实信息报告里只描述数据范围和字段名不贴大量真实数据。3.5 风控绕过类风险金融业务的风控往往隐藏在业务前端。比如大额转账要人脸识别、提现要二次验证、优惠活动限制同一设备领取。风控绕过就是从这些规则的反向找问题修改设备标识参数能否绕过活动限制提前清理本地状态能否绕过前置判断直接调用业务接口能否跳过风控检测环节风控类问题的验证要非常克制。绕过风控本身可能意味着绕过合规要求测试时只验证“某一步可以被跳过的路径是否存在”不要实际完成一笔绕过风控的大额交易。证明前置校验可以被绕过报告的价值就已经足够。3.6 判级三问我在实战里判断高价值的依据提交之前我会对候选漏洞做三个自问这三个问题决定了报告里建议的严重程度。第一问影响面有多宽。是单个用户数据暴露还是全量用户数据可批量拉取是测试账号可用还是任何真实用户都可受影响影响面决定价值上限。第二问利用链路有多长。是否需要多重前置条件、特定环境、特殊权限链路越短、越靠近主流程危害越高。改一个参数就能造成影响通常比需要复杂构造的漏洞更严重。第三问能否组合放大。一个中危信息泄漏如果恰好泄漏的是用户手机号和身份证号就能成为账户接管链条的拼图。单个漏洞定级可能不高但组合成攻击链后整体风险会被明显放大。这也解释了为什么报告里应该写清楚影响链路而不只是描述一个孤立缺陷。4. 一次业务驱动的实操复盘4.1 先选一个试点功能假设场景是某金融App的“实名认证与绑卡”模块这也是我比较推荐新手优先选择的试点功能。原因很实在它位于账户核心链路涉及身份、银行卡、手机号三类敏感要素流程长通常包含四五个子接口大量状态切换前后端交互复杂一旦出问题大概率是账户接管或绑定关系篡改这类高价值结果。4.2 用状态图拆流程实名认证和绑卡的正常流程一般是提交身份证信息、调用实名认证接口、发起人脸识别、通过后进入绑卡页、输入银行卡号和银行预留手机号、银行四要素验证、设置支付密码、完成绑卡。在这个流程里要区分哪些状态是服务端强校验的哪些只是本地标记。例如“已完成实名”这个状态如果只是一个字段在后续绑卡接口中被读取而未被验证那么跳过认证直接调用绑卡接口就有可能实现未实名绑卡。测试时并不需要真的绕过人脸识别只需要观察每个关键接口是否重新校验了前置状态。4.3 按规则设计测试用例我的测试用例设计顺序是先走通正常流程记录每个接口的正常请求和响应结构然后单参数变动逐个改动关键参数看响应差异再测关系边界切到自己的另一个测试账号去访问刚获取的资源凭证接着测状态回退看一个已完成的操作能否反复触发最后测并发边界在优惠、积分、付款等关键业务上做有限并发确认是否存在“检查-然后-更新”的竞态缺陷。最后一步并发测试尤其要注意金融系统真实业务并发最高但测试并发也最容易引发线上故障。我的原则是每次并发只用一个测试账号只触发不影响真实资金的操作比如查看类、优惠券领取类、状态查询类不碰真实转账和支付流程。4.4 最小化验证与现场记录验证到“确实存在异常”时就要开始记录证据了。我的记录习惯是保留触发时间点方便厂商查日志保留完整的请求链从进入功能页到触发异常的每个关键请求标注正常请求和异常请求的对比差异让审核人员一眼看出问题所在敏感信息先脱敏再截图。报告里的证据要能复现但也要避免把测试过程变成对生产业务的实际破坏。4.5 骑墙问题的判断方式测试中经常遇到一种情况某个点看起来可以继续深挖但再往前一步可能超出SRC授权范围。我的判断标准很简单如果这个操作会触碰真实用户数据、真实资金、管理后台或者需要越权访问SRC规则未覆盖的资产就到此为止把已有线索写进报告。宁可把难题留给厂商去验证也不要做越界操作。合规底线一旦破了技术成果就没有意义了。5. 报告会写漏洞才能被认定为高价值5.1 一句话标题和标准结构报告标题要直接点明两个信息模块名加漏洞类型。类似“实名认证接口存在逻辑缺陷可绕过绑卡限制直接绑定他人卡”或者“订单查询接口水平越权可查看任意用户交易流水”。标题里带上模块和类型厂商分单和审核都会快很多。报告正文我按五段式来写漏洞描述、影响分析、复现步骤、修复建议、证据附录。漏洞描述交代背景和原理影响分析从资金、账户、数据角度说明后果复现步骤从登录开始写到最后一步每步附上请求和响应关键片段修复建议不只写“加强校验”而是给出具体的校验思路比如“建议在接口层重新校验用户ID与资源归属关系不信任前端传入的归属字段”证据附录放脱敏后的截图和报文。5.2 把影响链写清楚很多提交者在报告里只写“这个接口存在越权”这样的信息量不够。厂商审核人员拿到报告要花时间想这漏洞能造成什么后果这时“影响链路”就派上用场了。我通常会把影响链拆成两层写。第一层是直接后果比如接口返回了手机号、身份证号。第二层是放大后果比如“泄露的手机号和身份证号可以用于配合找回密码流程实现对任意用户的账户接管”。直接后果决定这个报告的定级下限放大后果决定上限。厂商看到清晰的影响链定级和修复优先级都会明显提高。5.3 与审核沟通的正确姿势提交之后被驳回或降级在SRC里是常态不用急着争。我的经验是先看对方的定级口径如果对方认为影响面有限我就补充证据说明这个接口的实际调用规模和上游来源如果对方认为需要更多前置条件才能利用我就补充说明前置条件的常见性。沟通的目的不是吵架是让厂商看清风险。反过来如果自己确实测错了、影响没描述清楚也要敢于修正。一个长期合作的价值远大于单次漏洞的积分。5.4 常见审核驳回原因对照驳回或降级原因对应的优化方法复现步骤不完整审核人员按报告走不通每一步写明请求方法、完整URL、关键参数、前置状态影响描述空洞没有落到业务后果补充资金、账户、数据层面的影响链路分析使用了真实用户数据证据截图未脱敏报告里一律使用虚拟账号截图关键字段打码在授权范围外测试测试前仔细阅读SRC规则不确定的入口先询问厂商漏洞依赖多个账号和复杂操作把前置条件列清楚并说明这些条件在真实场景中是否容易达到6. 实战里的雷坑和个人经验6.1 别把测试做成线上事故我在金融SRC里见过太多新手踩同一个坑做并发测试时不克制一瞬间跑出几百个真实请求把生产环境打慢了或者用回调接口模拟器反复触发支付回调造成测试资金流水堆积。这类行为即使最终提交了有效漏洞也会让厂商对你整体评价打折扣。控制影响的做法是并发请求控制在个位数到十几位之间只打自己账号下的业务优先使用厂商提供的测试环境或沙箱没有沙箱时选择对真实资金影响最小的功能点。另外记录每一次发起的请求万一厂商问起来能说清楚。6.2 数据安全是最不能破的底线泄露数据不传播、不留存、不外发这是行业的铁规矩。我处理敏感信息的习惯是本地测试数据加密存储分析完成后及时清理报告里只描述字段名和数据样例样例也要脱敏不做任何“下载所有用户数据然后统计验证”的操作。一个漏洞的价值再高也不能以触碰真实用户隐私为代价来证明。6.3 持续发现高价值漏洞的小习惯长期保持产出率我有几个持续在用的习惯。关注功能更新公告新功能上线周期是问题高发期关注厂商补丁看它修复的方式是否可以被逻辑绕过关注同类业务的竞品产品同一个业务逻辑在这个App上安全可能在另一个App上就是漏洞这不是攻击别人而是用来积累不同实现方式的安全判断经验。还有一点不要轻视低危漏洞。很多高危漏洞的前置条件是某个低危问题贡献的比如一个中危信息泄漏为高危越权铺了路。日常测试中把情报点都记下来再组合成链路价值常常超出单独提交的总和。6.4 收尾给我自己也是给新人的三条心法做了几年金融SRC真正沉淀下来的其实是三条心法我一直跟身边的新人反复讲。第一永远先理解业务链路再动手测接口把资金、账户、数据的流转图画出来漏洞往往自己就浮出来了第二最小化验证是基本功能用一个测试账号搞定的问题绝不用两个能在测试环境验证的绝不碰生产第三报告比漏洞本身更重要一个写清楚影响链路的报告能让你的努力被看见也让厂商愿意持续信任你的提交。金融业务的复杂度决定了漏洞挖掘没有标准答案。但业务驱动这条思路至少能让你在纷繁的接口和参数里找到最值得投注注意力的那几条路。希望这篇内容能帮你少走一些弯路也欢迎同路人在评论区聊聊你自己在这个方向上的心得。