业务视角下的金融SRC快速挖掘思路

0x01 简介挖掘金融类漏洞的核心不仅仅是技术点本身更需要深入理解业务链路、资金流转规则、风控策略与账户体系从而在“设计缺陷”中找到突破点。本文总结梳理常见的金融逻辑漏洞类型及关键节点的可利用点帮助安全人员深入理解这些场景快速定位高价值逻辑漏洞大大提升漏洞挖掘效率和准确度减少资损信息泄露等高危问题的发生。本文仅用于技术学习与合规交流严禁非法滥用。因违规使用产生的一切后果由使用者自行承担与作者无关。现在只对常读和星标的才展示大图推送建议大家把渗透安全HackTwo“设为星标”否则可能就看不到了啦末尾可领取挖洞资料0x02 正文详情注册开户场景首先我们来了解一下开户场景的大概流程绕过信息校验开户正常开户申请一般需要手机号邮箱验证作为必填项但往往只是在前端进行校验符合正则格式则通过校验手机号、邮箱、身份证号由于传过来的字段存在可选填项如推荐码等后端往往不会硬性要求全部字段都取后端只会拿传过来的部分这时候去掉手机相关字段仍可以正常开户KYC信息复用伪造攻击者可利用已认证的同一套资料如身份证正反面、人脸信息去注册第二个账户正常上传证件信息会对图片进行统一化格式处理然后sdk加签存到数据库中然后调用ocr对图片进行信息提取再去比对校验如下图为上传证件信息的api接口会返回一个加密的filekey文件名很多时候后端为了节省资源开销会优先调用缓存数据库结果判断是否已经上传过这时候就会导致一个证件信息可以开多个账户申请状态查询越权我们渗透时候可以找到“申请/状态查询”相关接口或页面修改post参数重放请求id、orderNo、ticketId、userId等观察响应是否返回不同用户的数据或敏感字段然后利用自动化脚本/爆破可预测 ID如下面这个例子存在 request_id可通过遍历request_id获取其他用户手机号、身份证和银行卡信息支付场景高并发下单/提现后端没有加分布式锁会导致重复下单 / 重复提现攻击者可使用burp一秒内提交多次订单连续发起多笔提现成功创建多笔提现订单负值反冲在支付或退款接口中如果传入的金额参数为负数且后端没有严格校验金额必须为正可能导致用户账户余额不减反增金融类转账严格要求不能为负数当修改金额为负数时就会导致负值反冲int64 导致金额溢出金融系统常见操作金额 × 精度比如 ×10000 或 ×100000金额求和累计 risk amounttransfer/settlement 金额偏大企业/跨境/贷款/还款如果攻击者传入一个极大的数值可能导致系统计算时溢出变成一个负数或一个很小的数repayAmount : precision.ConvertAmountByBase( bo.RepayAmount.String(), eaBo.MoneyMultiBase, ) userName, email : f.getUserInfo(ctx, userInfo) now : time.Now() provisionExpireTime : f.getProvisionExpireTime(ctx, bo.ChannelId, bo.UserId, bo.PlatformUserId, now) paymentExpireTime : f.getPaymentExpireTime(ctx, bo.ChannelId, now)常见于后端使用 int64 处理金额int64 的范围有限只有 9.22e18金额乘倍率比如 ×100000后很容易超过这个范围一旦超过CPU 会直接把高位截掉并且go不会自动检查溢出传参过大会导致 price / amount 可被改为负数、0.01 等篡改参数免手续费进行转账在涉及外币或虚拟币的交易中攻击者尝试修改接口中传输参数使最终结算金额显著降低计算最终金额的时候会有很多参数参与运算如渠道、汇率等这时候可以尝试纂改相关参数免除手续费转账时如果传入xx_id值为0的情况下使后端 ampaign_result.code 0 , 导致可以实现无手续费进行转账if remittanceTicketReq.GetFeeWaivedAmount() ! 0 { if remittanceTicketReq.GetCampaignId() { logger.Error(ctx, format: invalid_fee_xxx_id) return common.ErrWalletInvalidRequestParam } }优惠券场景优惠券码爆破优惠券码未采用加密并且没配置网关限流策略导致可以高并发遍历通过对voucher_code进行遍历根据回显字段长度不同判断优惠券是否存在如下图存在为820、819不存在为798优惠券无锁限制重复领取优惠券核销时系统未严格校验该券的唯一使用记录或总使用次数加锁安全的情况func applyCouponWithLock(amount float64) float64 { coupon.mu.Lock() // 加锁 defer coupon.mu.Unlock() // 解锁 discounted : amount - coupon.Discount if discounted 0 { discounted 0 } coupon.UsageCount return discounted }后端未加锁导致可以重复领取func applyCoupon(amount float64) float64 { discounted : amount - coupon.Discount if discounted 0 { discounted 0 } atomic.AddInt64(coupon.UsageCount, 1) return discounted }优惠券叠加使用系统允许用户在单笔订单中同时使用多张原本设计为互斥或限用一张的优惠券正常单张使用多张优惠券叠加使用信息查询场景越权查询他人敏感信息金融类对越权漏洞是十分严格的像一般的越权查看个人信息、订单是渗透测试的必测项目例如用户 A 在查询自己的信息时通过修改请求参数为用户 B 的订单 ID成功查询到用户 B 的账单信息稍微复杂一些的隐藏参数情况函数实现是优先从post传参userid去查询的然后再去解token提取uid进行查询但是正常调用的时候post传入的是{}因此走到第二优先级的解token提取uid进行查询那我们该如何去挖掘这类的漏洞呢我们可以通过搜集history返回包中的参数组成字典去fuzz如下图返回包中有userphone、uid、role等字段通过fuzz发现uid可作为查询参数越权查询他人的信息TocToB网关配置错误接口混用在 gRPC Gateway 架构里越权问题通常发生在普通用户能调用原本只允许管理员的 RPC 方法。生成的 HTTP 路由没有绑定权限检查任何人都能访问Gateway 没加角色校验或者拦截器配置错误token 可以被忽略或者被默认当作 admin假设admin管理端域名为a.comtoc用户端域名为b.com通过burp history导出一份a.com右键选中 save item导出对应的xml文件导出文件格式还需要做进一步的处理Base64 解码将 XML 中的request元素的内容进行 Base64 解码解码得到完整的 HTTP 请求内容。解析请求根据 HTTP 请求格式第一行包含了请求方法和路径例如POST /api/login HTTP/1.1提取/api/login提取 POST 数据通过检查是否遇到 HTTP 请求头结束标志\r\n\r\n来提取请求体写入 CSV 文件将提取到的请求方法、API 路径和 POST 数据写入到 CSV 文件中导出文件命名为burp_history.xml导出文件为burp_history.csv脚本文件import os import xml.etree.ElementTree as ET import csv import base64 input_file burp_history.xml output_file burp_history.csv if os.path.exists(output_file): try: os.rename(output_file, output_file) except PermissionError: print(f文件 {output_file} 正在被占用请关闭相关程序后重试。) exit(1) tree ET.parse(input_file) root tree.getroot() try: with open(output_file, modew, newline, encodingutf-8) as csvfile: csv_writer csv.writer(csvfile) csv_writer.writerow([Method, API Endpoint, POST Content]) for item in root.findall(./item): request_element item.find(request) if request_element is not None and request_element.text: try: request_data base64.b64decode(request_element.text).decode(utf-8, errorsignore) except Exceptionas e: print(fBase64 解码失败: {e}) continue header_body_split request_data.split(\r\n\r\n, 1) if len(header_body_split) 2: headers header_body_split[0] body header_body_split[1].strip() header_lines headers.split(\r\n) if header_lines: first_line header_lines[0].strip() parts first_line.split( ) if len(parts) 2: method parts[0].upper() path parts[1] else: method UNKNOWN path first_line post_content body if method POSTelse csv_writer.writerow([method, path, post_content]) else: csv_writer.writerow([ERROR, INVALID REQUEST, ]) else: csv_writer.writerow([ERROR, EMPTY REQUEST, ]) print(f已成功将数据整理为 {output_file}) except PermissionError: print(f无法创建或写入文件 {output_file}请检查权限。) except Exceptionas e: print(f发生意外错误{e})处理效果intruder测试选择Pitchfork模式进行发包payload encoding取消勾选开始测试资源存储场景合同资料遍历获取合同、发票等敏感文件存储在一个可预测的路径下如/docs/contract/2025/ID_0001.pdf攻击者通过爆破或递增 ID 的方式可批量下载其他用户的合同文件S3存储桶配置不当/泄露许多金融机构使用云存储服务如 AWS S3 或阿里云 OSS来存储文件。如果存储桶 Bucket 的权限配置错误如设置为 Public Read可能导致所有存储的资料对外公开。https://github.com/dark-kingA/cloudToolsSSRF及绕过服务端存在可发起外部网络请求的接口如图片加载、URL 抓取。攻击者利用此接口让金融服务器作为跳板访问其内网敏感资源或未授权的云服务 API。但通常企业内部会有白名单域名当我们请求的url匹配则可以绕过检测成功触发dnslog使用第三方厂商开发JWT/密码硬编码未修改某盘系统中系统初始化的工程中定义了默认值的appid和jwttoken加密密钥导致攻击者可以利用该密钥伪造任意用户的 JWT Token从而绕过身份验证机制运维后门第三方运维有时候为了方便更新维护会在内部脚本、后端代码中直接引用外部 URL 来获取密码例如curl http://password.example.com/db-prod-pass wget http://x.x.x.x/getKey?envprod这种设计虽然便于统一管理但等同于主动为攻击者开放后门接口下面就是从SSO外部接口获取最新系统密码的实战例子0x03 总结挖金融 SRC 其实就像拆盲盒盯着开户、支付、优惠券这三大块猛冲就对了。前端校验随便绕、并发没锁随便刷、金额负值能反冲优惠券叠着用更是家常便饭。只要摸透业务套路避开风控套路高危漏洞随手就来主打一个懂业务比纯堆技术更吃香轻松实现 SRC 快速上分。最后愿各位师傅在后续挖洞之路中精准定位漏洞、高效挖掘天天出高危、次次有收获挖洞顺利、不踩坑、多拿奖励共同提升支付业务安全测试能力喜欢这类文章或挖掘SRC技巧文章师傅可以点赞转发支持一下谢谢