架构设计常见安全误区

参考：http://www.csdn.net/article/2015-08-13/2825453

误区一：兼容性设计

苹果的USB-C接口设计产生了一个必须推翻自己才能修复的漏洞， 所以说这是一个糟糕的设计。对于软硬件的兼容性设计，第一，一定要注意兼容的对象是否为同一类，不同类的对象最好不要强容，苹果这个设计就没有将控制指令的输入设备（键盘）与数据输入设备（U盘）这两类对象区分对待，导致了这个越权漏洞的产生；第二，兼容性设计者需要确保鉴权机制能够识别不同的对象输入，对不同的对象输入走不同的处理，避免出现控制指令输入设备可以伪装数据输入设备，代码可以伪装成数据输入的漏洞，借用一句经典的话——“圈子不同，不要强容”。

误区二：降低成本设计

所以设计时保证一定的服务器冗余，能够降低攻击开始阶段系统就被攻击到瘫痪的概率，也为DDos安全专家的安全防御策略提供计算资源。如果有条件的话，最好是把业务部署在云上，这样被攻击的时候可以动态增加服务器数量，既能节省成本也能保障攻击的时候能够有效的防护。

误区三：数据和代码不分离的设计

例如一个导致上传攻击漏洞的设计案例，先简单描述一下上传攻击的原理，大部分应用系统都有上传图片或文件的功能，攻击者利用这些功能上传一个网页木马，如果存放上传文件的目录有执行脚本的权限，那么攻击者就可以直接得到一个WebShell，进而控制Web服务器。这个漏洞有两个必要条件，一是可以上传木马，二是存放上传文件的目录具备执行脚本的权限。上传是业务的功能需要，即便有做各种安全过滤，限制木马上传，但也有各种绕过过滤的攻击方法，比较难以限制。所以漏洞的关键就在上传的目录是否具备执行脚本的权限上，很多设计者会基于降低成本的考虑，将存储上传文件的位置与Web应用程序放在同一服务器，甚至同一目录下，这样上传的目录也和Web应用程序一样具备执行脚本的权限，从而导致系统产生了一个高危上传漏洞。而如果将存储上传文件的位置设计在另一台只具备存储功能的文件服务器或数据库上，与Web应用服务器分开，这样即使木马被上传进来，也因为文件服务器不能执行脚本而没有办法实施攻击。

误区四：封闭设计

设计者常会直观的认为私有算法拥有算法的秘密性，所以安全性要比公开常用加密算法更高些。但其实私有算法的秘密性也是很难保障的。

误区五：黑名单防御

通常设计者都会知道需要防御sql注入和XSS攻击等安全问题，但是在选择防御的方案时常常走入一些误区， 他们通常会选择用过滤的方法去防御sql注入和XSS攻击等攻击，这种类似黑名单的防御方式简单方便，修改量小，而且他们认为这样黑客已经攻不进来了。他们低估了黑客们的智慧和毅力，事实证明凡是采用过滤方式防御sql注入和xss的产品，无一不被绕成狗的。所以对SQL注入漏洞应该用参数化查询的方式来解决，XSS漏洞应该用对输出进行编码的方式来解决，过滤的方法只能作为临时方案用来辅助做深度防御，而绝不能单独作为防御攻击的安全解决方案。

误区六：没有将安全列为设计目标之一

相比以上误区，大部分设计最大的误区就是没有将安全列为设计的目标之一，这才是产生以上所有设计安全问题的根源。产生这样误区的主要原因有两个，第一，架构师或设计者真心不觉得有人有能力和有耐心去攻击他们的产品。我在与架构师的沟通中，听到最多的一句话就是“不可能！”，不管是最优秀互联网企业的架构师，还是最优秀传统企业的架构师都是这样。架构师或设计者们通常以自己的知识去判断是否能被攻击，但是大部分的架构师和设计者都不具备一定深度的安全知识，所以常常作出错误的判断。黑客是最具极客精神的群体，为挖掘一个漏洞连续调试12小时，持续攻坚一个星期都不是什么稀奇的事情，所以在这样一个群体面前，绝不能以己度人，听从靠谱安全架构师的意见会更安全。第二，存在安全漏洞并不一定立即发生安全事故。安全问题大多数情况下都只是风险，它转化为安全事故一般有一段时间，而且很多情况下即便发生了安全事故，一些安全力量薄弱的公司甚至不能检测和感知到，所以表面的一片“和谐”给了我们的设计者一种错觉，不需要做安全的设计，产品给我的需求都做不完，哪有时间”浪费”人力的做安全设计和开发！

所以各种遗留下来的安全隐患积累到一定程度，或者被某个导火索事件引起安全事故的大爆发，导致企业的经营遭受重创！不管是架构师等研发人员，还是安全人员都不应该让企业走到这一步绝境，而应该在产品设计之初就避免出现严重的设计安全问题，为保障产品的安全水平打下基础。