渗透测试-业务视角下的金融SRC快速挖掘思路

金融SRC各场景漏洞挖掘技巧

前言

挖掘金融类漏洞的核心不仅仅是技术点本身，更需要深入理解业务链路、资金流转规则、风控策略与账户体系，从而在“设计缺陷”中找到突破点。本文总结梳理常见的金融逻辑漏洞类型及关键节点的可利用点，帮助安全人员深入理解这些场景，快速定位高价值逻辑漏洞大大提升漏洞挖掘效率和准确度，减少资损信息泄露等高危问题的发生。

注册开户场景

首先我们来了解一下开户场景的大概流程

绕过信息校验开户

正常开户申请一般需要手机号+邮箱验证作为必填项，但往往只是在前端进行校验，符合正则格式则通过校验（手机号、邮箱、身份证号）

由于传过来的字段存在可选填项（如推荐码等），后端往往不会硬性要求全部字段都取，后端只会拿传过来的部分，这时候去掉手机相关字段仍可以正常开户

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 Exception as 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 Exception as e:
    print(f"发生意外错误：{e}")