0x01 简介
挖掘金融类漏洞的核心不仅仅是技术点本身，更需要深入理解业务链路、资金流转规则、风控策略与账户体系，从而在"设计缺陷"中找到突破点。本文总结梳理常见的金融逻辑漏洞类型及关键节点的可利用点，帮助安全人员深入理解这些场景，快速定位高价值逻辑漏洞大大提升漏洞挖掘效率和准确度，减少资损信息泄露等高危问题的发生。
本文仅用于技术学习与合规交流，严禁非法滥用。因违规使用产生的一切后果，由使用者自行承担，与作者无关。
现在只对常读和星标的才展示大图推送，建议大家把渗透安全HackTwo"设为星标"，否则可能就看不到了啦！****
末尾可领取挖洞资料
0x02 正文详情
注册开户场景
首先我们来了解一下开户场景的大概流程
绕过信息校验开户
正常开户申请一般需要手机号+邮箱验证作为必填项，但往往只是在前端进行校验，符合正则格式则通过校验（手机号、邮箱、身份证号）
由于传过来的字段存在可选填项（如推荐码等），后端往往不会硬性要求全部字段都取，后端只会拿传过来的部分，这时候去掉手机相关字段仍可以正常开户
KYC信息复用伪造
攻击者可利用已认证的同一套资料（如身份证正反面、人脸信息）去注册第二个账户
正常上传证件信息，会对图片进行统一化格式处理，然后sdk加签存到数据库中，然后调用ocr对图片进行信息提取再去比对校验
如下图为上传证件信息的api接口，会返回一个加密的filekey文件名
很多时候后端为了节省资源开销，会优先调用缓存数据库结果，判断是否已经上传过，这时候就会导致一个证件信息可以开多个账户
申请状态查询越权
我们渗透时候可以找到"申请/状态查询"相关接口或页面，修改post参数重放请求（id、orderNo、ticketId、userId等），观察响应是否返回不同用户的数据或敏感字段，然后利用自动化脚本/爆破可预测 ID
如下面这个例子存在 request_id
可通过遍历request_id获取其他用户手机号、身份证和银行卡信息
支付场景
高并发下单/提现
后端没有加分布式锁，会导致重复下单 / 重复提现，攻击者可使用burp一秒内提交多次订单，连续发起多笔提现
成功创建多笔提现订单
负值反冲
在支付或退款接口中，如果传入的金额参数为负数，且后端没有严格校验金额必须为正，可能导致用户账户余额不减反增
金融类转账严格要求不能为负数，当修改金额为负数时就会导致负值反冲
int64 导致金额溢出
金融系统常见操作：
-
金额 × 精度（比如 ×10000 或 ×100000）
-
金额求和（累计 risk amount）
-
transfer/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可作为查询参数，越权查询他人的信息
Toc&ToB网关配置错误接口混用
在 gRPC + Gateway 架构里，越权问题通常发生在普通用户能调用原本只允许管理员的 RPC 方法。
-
生成的 HTTP 路由没有绑定权限检查，任何人都能访问
-
Gateway 没加角色校验，或者拦截器配置错误，token 可以被忽略或者被默认当作 admin
假设admin管理端域名为a.com，toc用户端域名为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, mode="w", newline="", encoding="utf-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", errors="ignore")
except Exceptionas e:
print(f"Base64 解码失败: {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 == "POST"else""
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/cloudTools
SSRF及绕过
服务端存在可发起外部网络请求的接口（如图片加载、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?env=prod这种设计虽然便于统一管理，但等同于主动为攻击者开放后门接口
下面就是从SSO外部接口获取最新系统密码的实战例子
0x03 总结
挖金融 SRC 其实就像拆盲盒，盯着开户、支付、优惠券这三大块猛冲就对了。前端校验随便绕、并发没锁随便刷、金额负值能反冲，优惠券叠着用更是家常便饭。只要摸透业务套路，避开风控套路，高危漏洞随手就来，主打一个懂业务比纯堆技术更吃香，轻松实现 SRC 快速上分。最后****愿各位师傅在后续挖洞之路中，精准定位漏洞、高效挖掘，天天出高危、次次有收获，挖洞顺利、不踩坑、多拿奖励，共同提升支付业务安全测试能力！****🔥喜欢这类文章或挖掘SRC技巧文章师傅可以点赞转发支持一下谢谢！