微信开发过程中有关资金安全的一些想法

服务端的安全问题

我自己定义3个级别，由低到高

1. 数据库被攻破，可以随便改数据（这边牵涉到只是普通账号还是root账号)
2. 源代码被泄漏，对方知道所有处理的逻辑以及数据库的组织形式
3. 服务器root被攻破，对方知道所有的配置文件信息以及敏感的签名文件

我现在想到了1和2的防御方式，但是想不到3，因为微信会提供一个签名文件，所有的转账通过该签名文件加密后，调用微信接口，向特定用户转账。所以，理论上，即服务器被攻破的话，黑客拿到签名文件，能自己写转账逻辑，把钱都转给自己。

对于1的预防，分以下几种场景和预防措施

1. 直接修改自己拥有的余额数
   预防措施：数据库有专门的表用以对账使用，直接修改余额会导致对账失败，转账不能继续
2. 黑客对对账的表操作，分为如下几种
   a. 直接插入假的数据，表示自己有一笔收入。
   预防措施，所有的对账数据（即其他用户通过微信转给该用户的钱），都有一条微信的单号，可以通过调用微信的接口，判断这条数据是否有效。
   b. 修改数据，把付给别人的钱，标示为付给自己
   预防措施，在之前用户转账（此处转给公司）的时候，提供给微信接口额外的信息里面，包含未来被转账用户的ID，通过这个判断，这笔钱只能付给谁。[这个在预防上，与方法c类似，属于重复的方式]
   c. 已转账的对账单，重复执行转账。即只有1笔100元的有效单，被从已转账改为未转账，于是多次转账。
   这个问题我这里的处理是最没有底气，因为如果服务器被攻破的话，这个处理方法解决不了问题。主要通过2点。
   1） 数据库加入触发器，对于某些字段，比如转账的状态，不能从已转账变为其他状态（然并卵，可以攻破数据库改触发器）
   2）服务器存在一个key，对于数据库的数据，以被转账用户id，微信订单号，还有转账状态这个3个，通过加密，生成一个签名，作为数据库表的一个column存在。如果转账前，该签名验证不过，说明数据有更改，不让继续。

对于2的预防

主要还是逻辑中用到的一些key，不在代码里面出现，通过读取环境系统变量

对于3的预防

如果能做到T+N来延时支付，可以在N里面找到漏洞，但这块限制需要微信对于商户转账有T+N的支持。 但很可惜，微信没有，所以，最后的防御就是，账号里面没钱，需要打钱的时候，知道要打多少，先充值再打。

最后的方案

由于数据库只支持内网的连接，如果黑客能连接数据库，那么，说明服务器已经不安全了，服务器内部记录着数据库的登录信息。考虑到实现的难度和分享的可能性，只做了1和2的预防。
对于安全方案的选择，个人觉得没有完全安全的方案，要考虑的就是
1. 对方（黑客）的犯罪成本与收益。只要把犯罪成本提高到收益之上，或者把收益降低就行。比如默认账号没钱就是降低收益的做法。
2. 借用第三方做风险预防。比如，把重要的数据放到微信那边，如果对方为了那么点钱把微信也黑了，那么，只能说洒家这辈子算值了。