那些需要自己开发的安全需求（服务端）

最近在实施App安全方面的方案，下面是一些思考。有些安全方面的产品需要购买，本文中的却要自己集成。需要开发的组件很多，所以依个人经验，简单做了下分层，不包括App端和主机环境。

数据处理

通讯层

http协议简单易懂、使用方便，我们大多数网络应用都是基于它开发的。数据展示，移动互联网已经占据了大量市场，对于App端开发，已经进入了混合协议的时代。这就是通讯层，数据传输的通道。

请求可能来自这些地方：
一、APP。 某些移动应用
二、Web端。 大多数网页请求或者H5
三、小程序。 被封装的各种调用（大多数要遵循平台开发方式）
四、开放平台。 各种SASS、PASS。

通讯层的破解难度是：
Socket（自有二进制协议）>WebSocket（wss、ws等）> Https > Http。

通讯层的加密主要是提高攻击者的分析成本，并不能够防御所有的攻击。通讯层独立的好处是可以随时进行交互协议的切换或者升级，并不影响下方的业务与策略。

加密层

加密是由调用者和服务者进行约定的一个算法层。目前，有对称加密与非对称加密之分。

对称加密是指维护一个密钥，解秘方即可通过密钥还原出被保护的数据。比较流行的对称加密算法有

DES 3DES AES

对称加密的密钥管理比较难，容易被破解，更换起来成本也比较大，但它的速度比非对称加密快几个数量级。

相对应的，非对称加密是指加密密钥和解密密钥不同的算法。安全性相对较高，但运行速度比较低。常见的非对称加密有：

RSA（耳熟能详） DSA ECC

这里插个有趣的事情。某个重要的root私钥，被倒入到一个专门的小型设备里。此设备被放入保险箱，保险箱需要四个不同的人的密码才能打开。安全级别非常高。

而我们常说的MD5、SHA1等，并不属于加密算法。

验签层

通过对传输的信息进行验证，我们就能够判断信息是否被篡改过。有些信息，比如密码，即使是简单的MD5，也比将原文保存下来好得多。

虽然DSA、RSA等，能够对信息进行数字签名，但我们常用还是一些摘要算法，也叫做Hash算法。

摘要算法不能对数据进行逆向解密，通常通过加盐的方式进行摘要保护。常见的摘要算法有：

MD5 SHA1 Bcrypt

值得一提的是Bcrypt，目前应用比较广泛。它的特点是即使是对相同的信息进行摘要，也会生成不同的内容，隐蔽性更强。

它的加密结果类似这种，你一定见过：

$2a$10$iRdNmYoINR8QqynemTsP2OzFtM7N5pFPoBFuzAtvR6YBtov4gRt7e

使用上，有些系统喜欢使用多重的摘要算法进行计算，安全性更高一些。但一旦被猜解，就形同虚设。

多重hash：md5(md5(sha1(str))).

业务防护

但数据还是能够伪造。业务层需要对传入的参数进行验证，进行真正业务意义上的判断。比如对某些余额操作，使用MVCC+CAS进行保护等。

请求大部分应该是幂等的，不能够重入。伪造的信息应该能够通过自定义的规则被识别。

扫描工具会扫描一些类似XXE、Struts漏洞之类的，这里是很多人的天堂。这种，建议还是买服务吧。

还有最后一道，风控系统。虽然重要，但有能力搞的公司很少，包括一些P2P系统，那就让子弹多飞一会吧。

我觉得坑多多的优惠券就是业务防护的范畴。当然还有银行这种，事后跨省追捕的，属于武装业务防护。

规范

同一类业务交互，一个http请求中既带有requestbody，又有request params；另一个请求却变成了post请求。后端的处理变来变去，就复杂了很多，也不利于排查问题。

此类问题还有传输了大量用不到的字段，信息嵌套层次过深，错误码紊乱等。许多故障最后的原因让人欲哭无泪。

在通讯层上，某些规范是非常重要的，值得花心思进行设计。

开发模式

开发模式是你给自己留的后门。

经过各种加密，验签，重入防护等组件的保护，你的系统安全性可能已经很高了。高到连你自己也被防护住了。

当你需要人工构造一些请求的时候，就会知道它的威力。通过某些开关或者灰度，可以让你略过某些环节，直接开展对主因的分析，提高验证的效率。

详尽的日志是系统遇到问题时强有力的帮手，当业务流程分支多而长的时候，调用链能显著加快问题的处理速度。在设计伊始，便要考虑对这些功能的集成与配置，以便对关键环节进行调优。

End

安全很重要，售卖靠忽悠。但是不买也是要受伤害的，还是花钱。买平安。