⽀付逻辑漏洞思路⼩集合

---

⼀.直接的价格修改 
⼆.修改⽀付状态 
三.修改购买数量 
四：⽀付附属值修改 
➀：修改优惠劵⾦额 
➁：修改优惠劵⾦额及业务逻辑问题 ➂：修改积分⾦额 
➃：满减修改 
五：订单替代⽀付 
六：⽀付接⼝替换 
七：重复⽀付 
⼋.最⼩额⽀付及最⼤⽀付(⾦额溢出) ➀：最⼩⽀付 
➁：最⼤⽀付(⾦额溢出) 
九.四舍五⼊导致⽀付漏洞 
⼗.⾸单优惠，⽆限重购 
⼗⼀.越权⽀付 
⼗⼆.并发数据包 
⼗三.盲盒类抽奖 
⼗四.直播打赏类 

 一.直接的价格修改

在⽀付当中，购买商品⼀般分为三步骤：订购、确认信息、付款。
⽽我们修改哪⼀步呢？你可以在这三个步骤当中的随便⼀个步骤进⾏修改价格测试，如果前⾯两步有验
证机制，那么你可在最后⼀步付款时进⾏抓包尝试修改⾦额，如果没有在最后⼀步做好检验，那么问题
就会存在，修改⾦额我们同样也可以修改为负数等。

二.修改支付状态

这个就类似于我们之前说的登录的⼀些逻辑漏洞⼀样，⽹站直接通过响应码判断是否成功。例如200成
功，400失败等。
此外还有，例如A订单-0001完成——B订单-0002未完成
付款时尝试把订单B的单号给成订单A，也可能会导致未付款直接显示完成。 

三.修改购买数量

在⽀付中，例如你买⼀个蜜汁⼩汉堡为⼗块钱，⼗个就是10*10=100，如果我们修改数量为-10个，那
么是不是平台要反要倒给我们100，利⽤这个漏洞，我们就可以很便宜买到东⻄。 

 四.支付附属值修改

我们在⽀付的时候，常会给你⼀些优惠劵呀，积分呀，满减等等，⽽这些值同样都是没有操作的点。

1:修改优惠劵金额

我们可以直接对数据包中优惠价的价格数量等进⾏操作，如果服务器对其没有验证，就会导致漏洞产生

2:修改优惠劵⾦额及业务逻辑问题

有时候我们明明修改成功了，但是在⽀付时可能会失败或者显示⾦额不正确，这⾥不要放弃，我们还可
以试试其他操作，虽然⽀付失败了，但是订单可能创建了，价格还是原来的价格，我们照样可以进⾏⽀
付。
此外，很多平台可能存在⼀个钱包的功能，我们先充⼀点钱，然后选择⽤⾃带的钱包进⾏⽀付，那么也
是有可能直接成功的。

3:修改积分金额

有些⽹站⽀付时可以使⽤积分，积分⼜可以抵现，我们也可以尝试修改这个地⽅，进⾏测试；此外我们
也可以反向操作，例如下单10元送1积分，我们直接梭哈，修改个100，这样不也是⼀样嘛。

4:满减修改

例如每次双⼗⼀的跨店满减，300减100，我们可以对300修改，例如修改到101减100，降低满减⻔槛等操作 同时也可以⽤到运费等其他⽀付附属值，都可以进⾏修改

五:订单替代支付

我们创建⼀个A订单为10元，创建⼀个B订单为100元，如果在⽀付过程中，我们将B的订单号改
为A，服务器没有对其进⾏其他校验的话，我们是可以⽀付成功的，相当于10元撸到了100元的东⻄ 

这个操作简单就是说由于没有其他验证，我们可以先记下充值⼀元的单号，然后再替换0.01的单号，这
样我们⽀付0.01就变成了充值⼀元，可以看到账号⼜多了⼀块钱

 六:支付接口替换

⽐如⼀些⽹站⽀持很多种⽀付，⽐如⾃家的⽀付⼯具，第三⽅的⽀付⼯具，然后每个⽀付接⼝值不⼀
样，如果逻辑设计不当，当我随便选择⼀个点击⽀付时进⾏抓包，然后修改其⽀付接⼝为⼀个不存在的
接⼝，如果没做好不存在接⼝相关处理，那么此时就会⽀付成功。

七:重复支付

 到这个有⼈可能会说，⽀付⼀次搞个数据包不久⾏了，为什么要重复⽀付，多花钱。
这⾥举⼀个例⼦，京东存在试⽤商品卡，
⼀张卡可以试⽤⼀个商品，我们可以将这个试⽤商品的数据包
进⾏多次提交，如果服务端没有进⾏校验的话就会产⽣很多订单，⽽如果我们将这个订单退掉，那么这
个试⽤卡就会退回，如果我们将这些订单全部退掉，是不是就能获得很多试⽤卡呢？

八:最小额支付及最大支付

 1:最小支付

在很多⽩帽⼦测试⽀付的漏洞时候，修改的⾦额往往都是0.01等或者负数，我想说这很容易错失掉⼀些
潜在的⽀付问题，因为有些⼚商在设计时最低⽀付⾦额就是1元，低于这个全部算⽀付失败，所以我们
在测试时不能直接修改太低，哪怕⽐原始⾦额少⼀元，也是可以证明存在⽀付漏洞的。

2:最大支付

⼀般在开发当中，商品的⾦额都会⽤int 型来定义，那么 int 的最⼤值为2147483647，可以尝试修改为
2147483648。看是否造成整数溢出，有可能⽀付状态异常，从⽽导致⽀付成功。
利⽤公式：2147483647/物品单价+1=物品数量

九:四舍五入导致支付漏洞

我们以充值为例，余额值⼀般保存到分为⽌，那么如果我充值0.001元也就是1厘，
⼀般开发会在前端判
断我们的数字，或者将最后⼀位四舍五⼊，使⽤⽀付宝充值是直接报错的，因为第三⽅⼀般只⽀持到
分。
那我们如果充值0.019呢，由于⽀付宝只判断到分，所以导致只能⽀付0.01，⽽由于我们⽀付成功，前端
会将9四舍五⼊，直接变成0.02，所以等于直接半价充值。 

十:首单优惠  无限重构

很多⼚家为了留住⽤户，都会有⼀个⾸⽉半价，或者是免费等等的活动，我们可以抓取这个数据包，进
⾏多次⽀付，就可以⼀直优惠购买。(百度云去年有这个漏洞，可以⽆限6元⼀⽉超级会员。

 十一:越权支付

这个问题很早之前有过，现在可能很少存在这类问题，在⽀付当中会出现当前⽤户的ID，⽐如：
username=XXXXX，如果没有加以验证，其⽀付也是⼀次性⽀付没有要求输⼊密码什么的机制，那么就
可以修改这个⽤户ID为其它⽤户ID，达到⽤其他⽤户的账号进⾏⽀付你的商品。
或者使⽤CSRF漏洞操作等等。

十二: 并发数据包

这个思路就是在买⼀个商品的时候，⽀付操作抓包，⾼并发环境下反复多次购买，有可能会造成⽐如10
块钱的东⻄，⾼并发操作下，花10块钱买了很多个。有些环境下要先满⾜兑换条件，例如兑换2次，
⼀次1元，⾸先余额要够4元才可以。
(发散思路：退款等等也同样是可以并发操作的。)

 

十三:盲盒类抽奖

现在由于盲盒类的兴起，在线盲盒也多了起来，我们拿⼀个简单的举例，例如现在有三个盲盒，两个普
通款，
⼀个隐藏款，那我们如何100%能获得隐藏款呢，我们可以尝试修改盲盒的属性，例如隐藏款对
应的id为1，普通款都为2，我们就可以将所有抽到id为2的修改为1即可

十四: 直播打赏类

⼀些直播平台的礼物可能还是根据id值来进⾏划分，其中就有可能存在⼀些内部测试的礼物，我们可以
尝试对礼物的id值进⾏⼀个遍历，查看是否有其他隐藏信息。
暂时就简单总结这么多，这种⽀付类逻辑漏洞现在也有点难挖，⼚商很多都有token、加密等，但是这
类漏洞其实⼜很好挖，因为很多时候看你的思路有多宽，骚套路有多深，漏洞就能挖多深。
此外，⽀付类漏洞适可⽽⽌，搞太多可能还是会被请进去的。