若为信息充值服务器,充值系列——充值系统安全问题（四）

这是充值系列的最后一篇，将讨论充值安全的问题。正如这个系列的其余文章提到的，充值系统的流程以下：算法

注意： 4,5执行顺序不肯定，步骤4是支付平台自动向服务器请求，步骤5是玩家点击“返回商家网站”时支付平台请求服务器，若是玩家不点击，这可能不会触发，因此这是一个不可靠的请求。数据库

支付的安全问题主要发生在步骤3和4中。下面是详细说明：编程

在步骤3中，客户端须要把订单信息提交给支付平台，好比玩家购买100个金币，他须要支付人民币10元。订单信息以下：安全

{服务器

"product_name" : 100金币,架构

"total_fee" 100,数据库设计

"currency": RMB网站

}加密

当玩家点击提交订单的时候，会把这个订单信息提交到支付平台，若是有人劫持这个请求，而且把订单信息的总费用修改成0.1元,那么支付平台只会扣除玩家0.1元，同时，这笔订单会顺利完成。也就是玩家只花了0.1元购买了原来100元的商品。spa

在步骤4中，支付平台会把订单处理结果和订单信息返回给服务器，例如返回的结果以下：

{

"status" : "fail"  // 表示支付失败

"product_name" : 100金币,

"total_fee" 100,

"currency": RMB

}

这里，若是某个玩家把这个URL劫持，而且修改其中的某些信息，例如把支付失败改成支付成功，或者本身拼接一个URL向游戏服务器发起请求，那后果可想而知。咱们须要保证订单除告终果没有被修改，同时还要保证这个请求来自于支付宝。

针对串改订单信息的问题，支付宝的作法是使用RSA算法加密订单信息，对于步骤4中发生的问题，支付宝要求服务器验证请求是否来自于支付宝，同时验证返回的订单信息，如订单信息是否被串改，支付状态是否为成功等。

RSA加密的思路： 把订单信息和商户私钥加密。同时把这个签名传给支付宝。只要不泄露商户私钥，订单信息基本上不可能会被串改。固然，服务器也会验证订单信息没有被修改。

服务器端验证订单信息是否被修改：

第一步：服务器端会接收到从支付宝返回过来的订单信息和以前签名的结果，这个时候，服务器在把订单信息签名，同时和以前的签名结果对比，若是一致，说明订单信息没有被修改。

第二步：获取支付宝返回的数据之一notify_id，按照支付宝要求的格式拼接成URL,提交给支付宝,若是返回为true，则说明这请求确实来自于支付宝。若是所示：

作支付系统的一些思考：

1：在作游戏后台的时候，须要常常向游戏服务器请求数据，这里就有一个安全问题，游戏服务器如何信任这个请求呢，这里就能够参考支付宝的签名机制：把须要向游戏服务器请求的数据和一个”密文“生成一个签名，把这个签名也提交给游戏服务器，当游戏服务器接受到请求后，再把请求的数据和”密文“加密，同时把结果和接受到的签名比对，这样就能够判断这个URL的合法性了。

2：支付平台接入都大同小异，关键是要理解支付的流程，更深刻支付流程的规范性和安全性，这对之后的编程也颇有帮助。

3：在接入360,91这样的平台的时候，须要理解oauth2.0，也涉及到URL请求合法性的问题，可是Oauth2.0和本篇文章的作法不一样。下一篇文章，将讨论一下oauth2.0的应用。