⼀.直接的价格修改
⼆.修改⽀付状态
三.修改购买数量
四:⽀付附属值修改
➀:修改优惠劵⾦额
➁:修改优惠劵⾦额及业务逻辑问题 ➂:修改积分⾦额
➃:满减修改
五:订单替代⽀付
六:⽀付接⼝替换
七:重复⽀付
⼋.最⼩额⽀付及最⼤⽀付(⾦额溢出) ➀:最⼩⽀付
➁:最⼤⽀付(⾦额溢出)
九.四舍五⼊导致⽀付漏洞
⼗.⾸单优惠,⽆限重购
⼗⼀.越权⽀付
⼗⼆.并发数据包
⼗三.盲盒类抽奖
⼗四.直播打赏类
一.直接的价格修改
在⽀付当中,购买商品⼀般分为三步骤:订购、确认信息、付款。
⽽我们修改哪⼀步呢?你可以在这三个步骤当中的随便⼀个步骤进⾏修改价格测试,如果前⾯两步有验
证机制,那么你可在最后⼀步付款时进⾏抓包尝试修改⾦额,如果没有在最后⼀步做好检验,那么问题
就会存在,修改⾦额我们同样也可以修改为负数等。
二.修改支付状态
这个就类似于我们之前说的登录的⼀些逻辑漏洞⼀样,⽹站直接通过响应码判断是否成功。例如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、加密等,但是这
类漏洞其实⼜很好挖,因为很多时候看你的思路有多宽,骚套路有多深,漏洞就能挖多深。
此外,⽀付类漏洞适可⽽⽌,搞太多可能还是会被请进去的。