作为一名网络安全爱好者,一直怯于写文章,总担心文章质量太水。最近运气好一周挖到两枚支付漏洞,在大壮老弟的鼓励下,写一篇关于支付漏洞的小总结,不妥之处还请各位师傅予以指正。
总述
支付漏洞是因编码过程中对支付逻辑限制不严格造成,导致实际支付金额小于标定金额。小学体育老师告诉我,支付价格=(单价*数量)- 优惠券,所以为了达到减少实际支付金额,可以通过三个途径来实现:直接修改支付总价(修改商品单价)、修改商品数量、使用优惠券。
直接修改价格
支付价格的漏洞就是通过在传参过程中任意修改支付价格,而后端未为对订单的价格做校验导致,可以直接跳转至支付界面。然而这种漏洞现在比较难遇到,最简单的支付逻辑都会通过订单信息来校验待支付价格是否一致。(以下案例图片摘自wooyun)


修改商品数量
修改数量溢出测试
因为之前做过嵌入式,所以对整形溢出比较敏感,从逻辑上来说,商品数量一般会使用int型,按照c语言的逻辑,对于16位编译器,int占用2字节16位,对于无符号整形来说,范围为0 ~ 65535,对于有符号整形来说,范围为- 32768 ~ 32767;对于32位和64位编译器,int占用4字节32位,所以对应两个范围分别是 0 ~ 4294967295 和- 2147483648 ~ 2147483647 。考虑包含上溢出与下溢出等多个敏感数据的情况,比如65536、32768、-32769、4294967296等数据多测试,说不定就有意想不到的收获。
多件商品合并购买,数量有正有负
有的支付逻辑会校验最终支付价格不能为0或者为负值,所以要构造总价必须为正。按照 总价 = (商品A单价 * 数量)+(商品B单价 * 数量),那么如果可以修改某商品的数量为负,就可以降低总价。(以下案例图片摘自wooyun)

使用优惠券
特定优惠券跨商品抵扣
某会员惠券,充值会员可满20元抵扣10元,但是由于逻辑限制不严格,导致可以构造相关支付请求,利用优惠券购买除会员外其他产品,如果一旦商品价格低于10元,则直接购买成功。
修改优惠券验证返回值
曾经看到过一个案例,某线上书店在提交支付的页面,可以验证优惠券,验证成功后可以抵扣相关费用,进入支付页面。该漏洞在验证优惠码后通过接口会返回优惠券对应金额,只要修改返回值,提交支付页面就会认为优惠券验证成功,并在总金额中核减对应的金额。
以上是一些小的总结,不妥之处请各位师傅指正,还希望抛砖引玉,得到各位师傅更好的思路。