在线支付逻辑漏洞总结

声明：这个只是我自己在网上原文不动的扒下来的，只是为了以后用到方便快捷的找到。

背景介绍

随着网民越来越习惯于网上购物，出现了越来越多的电商网站，在线交易平台等。

其中肯定要涉及在线支付的流程，而这里面也有很多逻辑。

由于这里涉及到金钱，如果设计不当，很有可能造成0元购买商品等很严重的漏洞。

检测方法与案例

根据乌云上的案例，支付漏洞一般可以分为五类，如果发现其他的类型，欢迎补充：

1、支付过程中可直接修改数据包中的支付金额

这种漏洞应该是支付漏洞中最常见的。

开发人员往往会为了方便，直接在支付的关键步骤数据包中直接传递需要支付的金额。

而这种金额后端没有做校验，传递过程中也没有做签名，导致可以随意篡改金额提交。

只需要抓包看到有金额的参数修改成任意即可。

我们来看一看几个案例：
http://www.2cto.com/Article/201205/129790.html
http://www.2cto.com/Article/201207/138493.html
http://www.2cto.com/Article/201211/167402.html
2、没有对购买数量进行负数限制

这种案例也比较常见，产生的原因是开发人员没有对购买的数量参数进行严格的限制。

这种同样是数量的参数没有做签名，导致可随意修改，经典的修改方式就是改成负数。

当购买的数量是一个负数时，总额的算法仍然是"购买数量x单价=总价"。

所以这样就会导致有一个负数的需支付金额。

若支付成功，则可能导致购买到了一个负数数量的产品，也有可能返还相应的积分/金币到你的账户上。
案例：

http://www.2cto.com/Article/201205/129965.html

最后一个漏洞与其他不同的是把数量改成一个超大的数，而不是负数。

结果导致支付的金额可能超过一定数值而归0。

3、请求重放

购买成功后，重放其中请求，竟然可以使购买商品一直增加~

阿里云主机多次下订单，会出现0元订单情况，不知道程序员后端是如何写的……

4、其他参数干扰

此案例金钱已经做了签名认证，修改后不通过。

但是仍然有一个参数会对最后的金额产生影响而没有一起做签名导致问题产生。

修复方案
其实修复方案很简单，对传递的金钱，数量等对最后支付金额会产生影响的所有参数做签名。

并且注意签名算法不可被猜测到。

这样攻击者修改数据的时候验证便不会通过。

同时注意对已经交易的订单不可重复而造成重复重置的漏洞