必测的支付漏洞（二）支付流程中“幂等性”

看到这个标题，你们一定一脸懵逼吧哈哈哈~最近拜读了一篇很棒的文章，学习到了计算机中的一种思想——幂等性。然后联想到了之前测支付漏洞时的一个测试点，今天用本文跟大家分享一下幂等性这种思想吧~

幂等性其实是源于数学，后来延伸到计算机领域。是指可以使用相同参数重复执行，并能获得相同结果的函数，这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。其实，幂等性指的就是指一次和多次请求某一个资源应该具有同样的副作用。

我们先从一个例子说起，假设有一个从账户取钱的远程API，我们暂时用类函数的方式记为：

bool withdraw(account_id, amount)

withdraw的语义是从account_id对应的账户中扣除amount数额的钱；如果扣除成功则返回true，账户余额减少amount；如果扣除失败则返回false，账户余额。一种典型的情况是withdraw请求已经被服务器端正确处理，但服务器端的返回结果由于网络等原因被掉丢了，导致客户端无法得知处理结果。如果是在网页上，一些不恰当的设计可能会使用户认为上一次操作失败了，然后刷新页面，这就导致了withdraw被调用两次，账户也被多扣了一次钱。如下图所示：

我们可以通过一些技巧把withdraw变成幂等的，比如：

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的语义是获取一个服务器端生成的唯一的处理号ticket_id，它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个ticket_id，一个ticket_id表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果。这样，idempotent_withdraw就符合幂等性了，客户端就可以放心地多次调用。
基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤：1.调用create_ticket()获取ticket_id；2.调用idempotent_withdraw(ticket_id, account_id, amount)。虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，加上idempotent_withdraw是幂等的，所以任何一步由于网络等原因失败或超时，客户端都可以重试，直到获得结果。如下图所示：

上面的例子是关于幂等性思想在取款流程的体现，其实支付是相似的。在取款流程中，服务器会生成一个唯一处理号ticket_id，而在支付流程中，会在提交订单时生成一个订单编号prepay_id，也叫预支付id。如果一个订单支付成功后，在支付页面（如下图）再次进行支付，应提示“该订单已支付”的提示。这就是幂等性在支付流程中的体现，同一个订单支付的操作只会进行一次，订单支付成功后，客户端尝试再次支付，此时会带着prepay_id进行请求，服务器会返回第一次支付请求的处理结果，所以同一个订单不会进行多次支付。

还有一种情况，就是提交订单、选择支付方式、跳转到支付宝二维码页面时，断掉网络，扫描二维码，进行支付。支付成功后，再次扫描二维码，看看会给出怎样的提示？我扫出的结果如下，提示我“该订单已支付”，也印证了“幂等性”的思想，一次请求和多次请求具有相同的结果。朋友们测试支付流程时可以测试一下~

其实幂等性的思想在http协议中也有体现，我会在以后的文章中继续与大家分享。