安全分析：支付漏洞的三种常见类型

 

一：支付过程中直接发送含有需支付金额的数据包(常见)

 

危害指数：★★★★★

 

案例非常常见，主要针对支付宝等需要第三方支付的案例。开发人员往往会为了方便，直接在支付的关键步骤数据包中直接传递需要支付的金额，这种只需要开个Fiddler2，甚至是直接通过审查元素就可以修改到需要支付的金额。我们可以发现开发人员直接将金额(seriesPrice)和购买短信的数量(seriesNum)一起发送，这是十分危险的操作。黑客可以通过修改seriesPrice和seriesNum的值，来达到1元购买10000条短信甚至是更多的短信数量。

 

从经济利益上来讲，这对厂商来说是一个大的损失，中间差额非常巨大!不过，厂商非常负责任，当天就确认了漏洞并进行了排查。

 

修复方案：不直接在数据包中加入需要金额和数量等敏感数值。可以发送套餐的ID，然后由服务器来生产金额和数量，然后直接生成KEY走支付宝。

 

二：没有对购买数量进行限制(常见)

 

危害指数：★★★★

 

这种案例也比较常见，在乌云中也有挺多的案例。产生的原因是开发人员没有对购买的数量进行严格的限制，当购买的数量是一个负数时，总额的算法仍然 是”购买数量x单价=总价”，所以这样就会导致有一个负数的需支付金额。若仍然支付成功，则可能导致购买到了一个负数数量的产品，也有可能返还相应的积分 /金币到你的账户上。但是，这种情况不可能发生在通过支付宝支付的订单中(虽然我曾经也想过，但是是不行滴….)，因为显然支付宝是不支持一个负数金 额的订单，所以这种情况多数发生在一个有站内货币的网站。

 

一个修改后的数据包，number原本应该是一个正数，但开发人员并没有严格限制number的范围，所以当我们输入一个负数的情况下，就出现了下面的情况。由于一个错误的数量，所以就导致了我们的账户上多了30元。这种的危害比上一个就要小一些了，因为只是站内的货币，具体危害还要按网站的规模大小以及货币的对人民币的比率来区分。如果只是很小的网站，那就没什么意义;但如果是支付宝之类的，后果就比较严重了。

 

修复方案：严格控制购买数量的大小，不允许数量为负数，控制总支付金额是一个正常的数。

 

三：程序的异常处理

 

危害指数：★★★★(按站点类型而异)

 

程序的异常处理比较少见，不过也是有案例的。程序的异常处理，就是指支付的数据包异常的程序的错误处理。这种异常可以是数据与KEY不符，支付的 金额有错误，购买的数量不正确等等。程序的异常处理出现的原因主要是开发人员对出现异常后的处理不当造成的。

 

给大家举个例子：q是开通的月份，也就是数量。这里我们将其改成了9999999999999999999999999999999999999999999999999999999999999999999999999999999999(总 之很多个9啦)，程序的异常处理直接将应支付金额变为了0我们只需要输入一个安全密码，就可以使用0金额来支付这笔订单了~

 

这类问题的出现多数是程序员的大意造成的，没有对异常数据进行很好的处理，导致了问题的产生。

 

修复方案：根据网站的需要来调整异常处理的方案，发现异常，可以直接报错，拒绝继续运行。

 

来源：电子银行网