支付逻辑常见测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#支付逻辑常见测试：

1、熟悉常见支付流程
选择商品和数量
选择支付及配送方式 生成订单编号 订单支付选择 完成支付

2、熟悉那些数据篡改
商品
ID ，购买价格，购买数量，订单属性，折扣属性，支付方式，支付状态等

3、熟悉那些修改方式
替换支付，重复支付，最
小额支付，负数支付，溢出支付，优惠券支付等

4、熟悉那些另类方法
无限试用，越权支付，并发兑换，四舍五入半价购，循环利用优惠券，支付签约逻辑等

支付逻辑如何挖掘

1
2
3
4
5
6
7
8
9
10
11

1、找到关键的数据包
可能一个支付操作有三四个数据包，我们要对数据包进行挑选。

2、分析数据包
支付数据包中会包含很多的敏感信息（账号，金额，余额，优惠等）
要尝试对数据包中的各个参数进行分析。

3、不按套路出牌
多去想想开发者没有想到的地方，如算法拼接，关闭开启返优惠券等

4、PC端尝试过，APP端也看看，小程序也试试

支付逻辑安全修复

1
2
3
4
5
6

1、在后端检查订单的每一个值，包括支付状态；
2、校验价格、数量参数，比如产品数量只能为整数，并限制最大购买数量 ；
3、与第三方支付平台检查，实际支付的金额是否与订单金额一致；
4、如给用户退款，要使用原路、原订单退回。如：退押金，按用户原支付订单原路退回；
5、加密、解密、数字签名及验证，这个可以有效避免数据修改，重放攻击中的各种问题；
6、金额超过指定值，进行人工审核等。

大米cms案例

篡改金额和数量

抓包对应的购买订单，如果此时我修改数量，或者金额是否就可以用低价购买了呢？

订单对冲

• 含义：
  • 以 A 产品的价格订单去购买 B 产品的订单价格
  • 对方只检测付款成功的状态，不考虑对应订单的产品，就会有这样的安全问题
• 感觉有点像就是修改订单数据包，只是这个不是自己随便修改，而是参照另一个商品订单进行修改

大米手机CMS购买的订单

大米测试产品购买的数据包

替换支付

• 将产生支付页面，或者支付二维码的数据包进行替换，例如将支付 6000 的数据包，替换为支付 5400 的数据包

• 那么支付 5400 是否会将 6000 的订单支付呢？

  1	个人理解：抓取生成支付二维码的那个数据包，然后将里面（如果可以）关于不同订单的特征值修改成价格低，就有可能用低价格去购买高价格的产品，或者还有一种思路，就是将微信和支付宝进行删除，那么在进行支付的时候，是否有可能生成一个临时的二维码，然后用同样的方式抓取生成二维码的数据包，对特定值进行修改。看看是否可以用低价格购买高价值的商品。

接口判断

• 购买商品进行支付时，抓取数据包，修改其调用接口为其他接口，如若可以重定向，将调用接口设置为对自己钱包的付款地址，或者将自己付款给自己，返回付款成功的响应

这种个人情况不好搭建，因为如果想要一个支付接口的话，需要企业的资质（小迪说的qwq）

Niushop开源商城

创建优惠劵：

创建商品：

生成完优惠劵之后，就可以在商品页面中刷新领取，然后每个账号可以领取一份。

优惠劵复用

抓取没有使用优惠劵的数据包 && 抓取使用优惠劵的数据包

抓包修改之后，可以看到这里生成了两个优惠之后的订单。

优惠券盗用

含义

• 服用：重复使用
• 盗用：算出优惠券规律，如你的优惠券 id 为 1，则别人的可能为 2,3,4,5……
  • 也可能是加密的值，逆向这个算法，自己修改为可用的优惠券编号

就是上面的实验，有优惠劵是1，没有是0，那么如果有其他优惠劵，是否可以遍历1~10000或者更多呢？这样是否可以直接盗用其他优惠劵呢？

积分对冲溢出

首先要设置一下积分。

将兑换余额发送的数据包进行修改：

如果将这个值修改为负数，是否可以达到让钱变多的效果

修改成-1，发现确实积分变多了，但是账户余额变少了。说明这里还有其他校验

同时如果你从100开始测试负数，会发现测试不了，个人猜测应该是有对总数量进行检测，从而无法在有100的积分下变多。

实战SRC支付购买挖掘分享案例

奇安信社区文章：https://forum.butian.net/share/1125

四舍五入漏洞

这个漏洞上次看小伙伴交的补天，获得了厂商1.2k的奖金，如何操作呢，我们来分析分析。我们以充值为例，余额值一般保存到分为止，那么如果我充值0.001元也就是1厘，一般开发会在前端判断我们的数字，或者将最后一位四舍五入，使用支付宝充值是直接报错的，因为第三方一般只支持到分。

那我们如果充值0.019呢，由于支付宝只判断到分，所以导致只能支付0.01，而由于我们支付成功，前端会将9四舍五入，直接变成0.02，所以等于直接半价充值。(这个漏洞京东也是有的，不过后来修复了。)

1

总结: 就是支付宝的金额单位不会低于分，所以就导致了，在充值的时候，如果充值的金额是可以低于分的话，就会出现半价充值的情况

并发提前全签到

1. 采用时间验证，修改当前设备时间绕过
2. 未采用验证，直接修改数据包对应发包

例子：比如说京东签到给一个金币，可以用并发，一次性多次签到，看看是否会到账多次签到的奖励，或者如果对方的签到日期，是按照本地的来的话，就可以修改本地的时间，从而达到提前领取签到的奖励。

循环利用优惠券

1. 使用优惠券创建一个订单，然后停留在支付界面
2. 关闭订单，返还优惠券
3. 使用优惠券再次创建订单，把第一个未支付的订单进行支付
   • 第一个未支付关闭返回优惠券后还存在可以支付才会存在这个漏洞
4. 商品从关闭，重新进入到了待发货的阶段

支付签约多逻辑

1. 使用 A 手机登录账号 A 打开要测试的业务，点击自动续费，文付时停留在支付界面
2. 使用 B 手机登录账号 B 打开要测试的业务，点击自动续费，文付时停留在支付界面
3. 重复多台手机进行同样操作。
4. A 手机点击支付进行签约。
5. A 手机支付成功后，在第三方 APP 中解除自动续费。
6. B 手机进行支付，支付成功后在第三方 APP 中解除自动续费。
7. 全部支付完成后，系统就会为你开通相应的次数，由于提前打开了支付界面
8. 所以金额都是享受到新用户首月优惠的金额。

建议：通常这种漏洞比较容易出现在活动页面的会员优惠开通。而且要考虑到支付后要比正常购买优惠才算是漏洞。