我们写代码在实现功能的同时还要兼顾安全，否则一旦发生安全事故，小则系统瘫痪，大则产生资损，本文结合作者在工作中遇到的实际案例，希望可以给大家普及一下安全方面的知识。

敏感信息泄露

事件回顾

业务场景是给客户通过有邮件方式发送一个水电煤的账单，样子就和我们看到的实体账单是一样的，这个账单上有姓名、家庭住址等敏感信息。

问题出在了这个账单图片的地址上，类似：http://www.abc.com/bill/123,  其中123就是账单编号，这个编号的生成方式采用的是数据库里的数字自动递增，攻击者可以通过自己拼装这个url, 遍历出所有的账单图片。

解决方案

含有敏感信息的资源数据一定要考虑安全问题，自增ID使用起来很方便但是做为接口中的关键要素必须要进行权限的验证，在此业务场景中并无登陆态，无法验证权限，需要更改编号的生成方案（比如UUID）,同时可以增加动态加盐的MD5值做信息完整性校验。

http://www.abc.com/bill/{编号}/{MD5}

账单表中增加 salt 字段作为盐值，{编号}通过UUID方式生成，{编号} + salt  生成MD5摘要，请求过来通过编号查询到这笔账单，校验MD5是否一致

篡改交易金额

事件回顾

某年国假期间突发黑客攻击，支付0.01元，可以修改成任意金额成交，比如可以付0.01元充500元手机话费，此次事故直接造成了资损。经查直接原因是接收第三方报文的验签代码被注释了，也就是说没有验签，而这个交易又是网银支付，也没有服务器间的IP白名单限制，稍有些抓包工具的黑客就可以轻松篡改支付金额。

解决方案

恢复验签代码

有关于金额的单据一定要注意，收到对方的响应报文后一定要验证签名并比对状态，金额是否一致

现金红包重复提现

事件回顾

很多网站在做营销活动会发送现金红包，这个问题就出现现金红包的提现上，点击某个红包的提现按钮，红包对应的金额会提现到客户的虚拟电子户，然后可以提现到银行卡或是直接用于消费。这个提现的动作在代码实现的时候的逻辑如下：

URL:  http://www.abc.com/tixian?id=001

判断001是不是属于当前登陆人的，如果属于，红包更新状态为已用，虚拟电子户++

攻击者故意制造高并发场景，导致一个红包提现了n次

解决方案

加锁，对红包加锁，可以用乐观锁，也可以用悲观锁，反正就一行。

幂等击穿，重复提现

事件回顾

在一次版本部署过程中，提现交易遭遇幂等击穿，多名客户提现一次，到账两次，资损不忍直视。经查此次迭代中对幂等字段做了变更，而部署的整个过程比较长，在此期间会出现A服务是新服务，而B服务是老服务，导致幂等失效。

解决方案

幂等字段不能轻易变更，尤其是涉及钱的接口

登陆密码击穿

事件回顾

多名用户反映密码输错让然可以正常登陆，经验证任意密码均可正常登陆。

经查，某程序员在开发过程中，会员中心的服务一致宕机，于是在把登陆逻辑注释了，改成了直接用登陆名查询用户信息，后面有跟其他改动一并提交。

解决方案

关键业务一定要列入回归测试用例。