第三方支付的一些安全测试总结
很多很多个月之前，我刚拿到我们项目的时候，一看有支付功能，当时怕怕的，万一有漏洞我没测出来，我们这个小小公司被挪走好几个亿，那我是不是责任很重大？我也很认真的看了大家的技术，现在我是直接扔到一些安全平台进行扫描，比如腾讯的金刚审计系统；所以这里只针对支付逻辑进行了一些总结
一、充值：
业务步骤：选择充值--输入充值金额--选择第三方支付方式--点击“充值”按钮--输入要充值的金额--调用支付API--返回带签名预付单信息--调用SDK 调起支付
这个过程需要测的是“调用支付API”到“返回带签名的预付单信息”这个过程，一般容易出现的问题是拦截这个接口，更改原先的大金额为一个小金额，如下图：
https://testerhome.com/photo/2016/8fc0901ad1e003b1aabfce7f98737fcb.jpg
继续走，如果支付0.01成功后，充值的值为最初我们输入的100的话，那这里就出问题了，但如果此方式充值完成后，最后成功充值的值为0.01那就是正确的处理方式，此数据应后台做判断，或者也可以对该输入值进行加签名的方式来保证正确，当然，此处还可以更改为0或负数，看后台是否做了判断
二、下单
我们app的下单业务并不像一般的电商那样一个订单有数量+金额这两个这段，我们只有金额，数量默认为1，且在接口中无该字段出现，可以像充值一样的测试方法去测试
三、支付完订单后订单的支付状态
先讲一个自己的亲身经历：今天早上我用12306买了一张火车票，支付宝支付的，支付完成后从支付宝返回到12306时，发现12306并未提示我支付完成，且在订单界面显示我的订单未支付，我就着急了（2011年，12306刚出来的时候，我有一次买票，票没买到，钱扣了的经历，后来经过客服把钱退回来了），刷新了好多次，还是未支付，正当我有点小焦虑的时候，短信通知我订票成功了。
此处的测试点是：很多开发或者产品会考虑支付完回到当前app去调一次支付成功的接口，这时很容易出现钱扣了，但是订单没完成，解决办法是利用第三方支付成功后的返回码判断是否支付，后台自动更改订单状态为已支付。
当然我们app的支付系统比较简单，更复杂的过程可能还有更多的测试方法，下面介绍一下我了解到的支付上可能出现的一些小漏洞
1、如上面说的，很多需要支付的订单是有数量+金额，如果开发没对数量进行签名，或后台进行判断的话，当我们像上面修改金额那样将数量修改成负数
2、未对异常的值进行处理
这种出现的情况比较少，比如某一个字段在客户端是无法输入的，但后台没做判断，收到这样的数据程序就出错了，但没对错误进行处理导致支付可以被绕过
最后无论如何要提醒开发对数据进行签名，或者判断，否则很容易出问题。
学无止境，还在学习更多的安全知识......
要测的点好多。。。
之前自如也出过一种情况，用户提现的时候点了一次，以为没有点到按钮，快速重复点击了两次，导致提现两笔且都成功了，然后账户的钱变成负的了，银行卡也收到钱了。
重复操作的情况也可能会出现，虽然每个订单都有不同订单号等其他判断。 感觉就是开发的if要够多，测试的case要全，整理的不错，先学习下，有机会也用用 一般支付不会是 明文传输，太low了，正规点的都 id串+token ，加密 和https， server端进行校验。
另外加密的过程放so库，代码混淆+加固+反调试以增加反编译的成本。
这些应该 测支付宝微信支付的同学们更有发言权的~ 多笔充值之间的参数替换，看是否能找到漏洞并推算规则。
页:
[1]
