目录
（切莫因所的处环境，蒙蔽了双眼）
一、简介：
支付漏洞（业务逻辑漏洞）
使用burpsuite等抓包工具，抓取数据包后，修改数据包中的参数从而达到支付篡改的目的
篡改的参数：商品ID，购买价格，购买数量，手机号码，订单ID，支付状态……
常见漏洞利用手段：替换支付，重复支付，最小额支付，负数支付，溢出支付，优惠卷支付……
二、原理：
2.1、支付成功原理：
购物平台接入支付结果的两种方式：
浏览器进行跳转通知购物平台支付成功
服务器端异步通知支付成功
2.1.1、浏览器跳转：
用户访问的浏览器，并在银行页面支付成功后（银行会返回一个支付成功数据包），使得从银行支付跳转到支付成功结果页面（购物平台页面），购物平台网站就将收到支付成功通知。
可能出现的问题：
在银行界面支付成功后未等待返回跳转数据包，就关闭了页面（购物平台收不到支付成功信息）
在浏览器接收的数据容易被篡改（因为中间多了一个用户）
2.1.2、服务器端异步通知：
（少了一个用户）
当支付成功以后，支付公司服务器直接向用户指定的异步通知URL发送参数，购物平台接收异部参数的URL对应的程序中，对返回的支付结果进行签名验证成功后，进行支付逻辑处理（验证金额、订单信息，支付时间……）
大多数都使用服务器端异步通知
三、漏洞产生的原因：
3.1、订单金额的验证：
价格未保存在数据库中
未校验商品价格与数据库中是否匹配
3.2、不安全的传输：
对订单相关信息未进行加密传输
（话说你加密的地方一定是重要地方，你不加密，你就是有病，哈哈哈）
3.3、验证规则不完整：
订单号与用户未进行绑定
四、危害：
顾名思义了，老表
修改商品的价格、修改订单号、修改订单的数量、修改支付状态值……
五、环境准备：
（2021年版的购物平台，存在支付漏洞的可能性很小，但是不妨碍试验）
我找的购物系统
链接：https://pan.baidu.com/s/13U9ys493l-nHsbC-8xFk7Q?pwd=hj12
提取码：hj12
六、利用过程：
6.1原理：
支付流程：提交订购信息------生成订单------付款
在每一步流程之间，如果没有做好验证机制，篡改将会被成功执行
在这三个步骤中，只要有一个能抓包修改，就将达成目的
6.2修改支付价格
6.2.1、第一步：尝试在订购过程中修改
goolds（物品的英文单词）id（编号）Spec（规格）Num（数量）type（类型）
goodsId=82&goodsSpecId=49&buyNum=1&type=1&rnd=0.5643189757982099
请求数据包改为3的话，他的实际价格应该会跟着变
上面那个数据包发出后，就显示添加成功
说明上面那个传参就是对应的商品编号，价格，数量……
第一步完了，他的价格跟着数量变了，失败啦
6.2.2、第二步：尝试在生成订单过程修改
能发现的基本信息
pkey秘钥
没有抓到什么有用信息，失败啦
6.2.3、第三步：付款截断尝试修改
抓住数据包了，发现没地方让我来改
这个地方的支付密码是明文传输的
虽然还是失败了，但是也有所发现
6.3、扩展：
既然都是越权，那我们来换一个方法
对管理员功能分析
可以添加用户在本平台的金额
如果能获得这个操作的URL，尝试越权修改
（这个要看cookie的验证完不完全）
知道修改的URL后，就要看对cookie的验证完不完全了
这个是我拦截的普通用户的cookie
这个是管理员执行操作的cookie
换为用户的cookie后进行尝试修改
发现操作成功了
说明对cookie的验证不完全
6.4、修改支付状态
6.4.1、原理：
如果支付状态的值未和实际订单支付状态进行校验，攻击者点击支付时抓包修改支付状态的参数为支付状态的值就能实现修改支付状态
6.5、 修改购买数量
6.5.1、原理：
抓包并修改商品的数量，如果修改数量后，总价格没有跟随数量的变化而变化；再者将数量修改为负数，如果总价格跟着变为负数。这二种可能都导致支付问题的产生
6.6、 修改优惠券、积分
6.6.1、原理：
根据优惠券的使用条件方式，尝试修改优惠劵金额、商品价格、折扣程度等
6.7、修改支付接口
6.7.1、原理：
因为支付肯定会有提供很多支付平台供用户选择，每个支付接口的值肯定是不一样的，如果支付的逻辑存在漏洞，或者接口相关处理存在不足，此时对支付过程抓包，将支付接口修改为不存在的接口，等待平台的支付处理结果（一般不可能了）
6.8、交叉替换支付
6.8.1、原理：
顾名思义，选择2个不同商品，分别产生两个订单支付，对其都进行抓包，修改其订单一的值为订单二的值，如果平台没有验证商品相关信息和用户应支付价格，就可以尝试用订单二的支付价格去买到订单一的商品，因此产生了替换支付。
6.9、无限制试用
6.9.1、原理：
试用类商品，如果产生多个订单并进行提交的校验，那么就可导致无限制刷牌子，每次提交的订单号不一样，相当于对同一个商品的多次试用的订单，如果存在逻辑漏洞的话，假设你全部申请退出试用，那么就会退相应数量的试用资格到你用户
6.10、最小支付额限制
6.10.1、原理：
最小支付额是平台对支付价格的一个限制规则，当恶意修改支付价格后，如果支付价格小于最小支付额，会导致支付失败等问题（失败不代表不存在漏洞，可能是价格改的太小了）
6.11、最大值支付问题
6.11.1、原理：
当支付值过大，超过逻辑处理规则（即存在支付逻辑漏洞），可将支付价格、优惠券等尝试修改为最大值，并观察支付结果的变化。
6.12、试用接口问题
6.12.1、原理：
毋庸置疑，对于产品的试用，一个账户一般只能试用一次，如果接口1是试用接口，接口2是支付接口，如果抓包后将接口改为接口2，如果接口存在逻辑处理问题，以试用价格去支付，就是可能为0元。
903
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
