那些需要自己开发的安全需求(服务端)

1,769 阅读5分钟

最近在实施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

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