架构设计中的6种常见安全误区

1、架构设计中的6种常见安全误区自然世界中，先天冇缺陷的生物总是容易被细菌病毒入侵，而健壮的生物更能抵抗细菌病毒 的攻击，计算机系统也是一样，若有先天的架构设计安全缺陷，那么在面临网络攻击的时 候，就更容易被入侵或者破坏，甚至因为设计架构的原因，有些漏洞完全没有办法修复！本 文将讲述架构设计屮需要避免出现的安全误区，以帮助我们研发人员设计出更安全健壮的 软件架构。本文的举例既有硬件架构，也有软件架构，还有基础架构等等不同的架构，但其 中原理适用于所冇的架构设计。下文将从兼容性设计误区，降低成本设计误区，数据和代 码不分离的设计误区，封闭设计的误区，黑名单设计的误区，没有将安全列为设计冃标z 的误区

2、，总共6个 方而来探讨设计安全误区的问题。误区一：兼容性设计兼容性越好的架构越能适应未来变化的需要，所以架构设计者会非常关注架构的兼容性设计, 但是冇些兼容性设计会带來严重的安全漏洞，这些安全漏洞甚至无法以简单的漏洞补丁方式 修复。以苹果的usbc接口设计为案例。usb-c这个接口不仅用来实现供电、还用于支持鼠标， 键盘等设备的数据传输,起到了简化设计结构，方便用户的目的。谷歌新款chromebook pixel 也内置了 usb-c接口，预示着业界对于macbook的usb-c接口设计基本上是-致认可的。 不过，安全专家却认为这是一个很糟糕的设计。在2014年的黑帽技术大会上，安全专家演 示

3、了一次针对usb-c接口的攻击，只耍将特制的u盘插入使用usb-c接口的苹果计算机， 攻击者无需在做任何操作，就可以将后门或是病毒自动植入苹果计算机，使计算机可以被 攻击者远程控制或是通过病毒曰动破坏计算机内的文件，非常可怕。更悲剧的还在后面，苹 果一直都没有办法修复该漏洞，为什么呢？这得从这个漏洞的利用方式说起，上文说到攻 击需要特制的u盘，安全专家改变了 u盘的硬件和软件结构和内容，当u盘插入usb-c接 口的苹果计算机时，电脑会识别u盘为一个键盘，再利用u盘中的芯片和存储的攻击代码， 就可以伪装成键盘向主机发送控制命令，从而完全控制主机，无论使用者是否开启口动播 放，都可以成功。所以漏洞

4、的关键在于u盘和键盘等设备可以共用同一类接口为计算机交 互，在计算机系统上没有办法区分伪装成键盘的u盘和真实的键盘，这样若不改变usb-c 接口可以兼容u盘，键盘等各种锁件的设计，他们就不能修复该漏洞，而若要修复该漏洞 就必须推翻原来的设计，让usb接口不再兼容键盘，鼠标等输入硬件，输入类硬件仍然使 用原來的ps/2接口或其它不同的接口。苹果的usb-c接口设计产生了 一个必须推翻白己才能修复的漏洞，所以说这是一个糟糕的 设计。对于软硬件的兼容性设计，第一，一定要注意兼容的对象是否为同一类，不同类的对 彖最好不要强容，苹果这个设计就没冇将控制指令的输入设备（键盘）与数据输入设备（u 盘）这两类

5、对彖区分对待，导致了这个越权漏洞的产生；第二，兼容性设计者需要确保鉴权 机制能够识别不同的对象输入，对不同的对象输入走不同的处理，避免出现控制指令输入 设备可以伪装数据输入设备，代码可以伪装成数据输入的漏洞，借用一句经典的话一一“圈 子不同，不要强容”。误区二：降低成本设计架构设计者也会非常关注架构的成本，能以最少的成本实现系统是体现设计者水平的重要标 志，所以架构设计者的设计总有降低软硬件成本的倾向，这种倾向木没有错，但如果在错误 的地方降了成本，给系统带來极大的安全风险，就得不偿失了。例如下面这个因为降成木设计导致服务器无法防范cc攻击的场景。很多设计者会将每台 服务器的负载率设定得非常高

6、，高达50%-70%,希望减少服务器的部署以降低成本，但是 在正常业务场景下就有这么高的负载，被cc攻击的时候会很容易被瘫痪，安全专家也没有 办法在服务器上实施安全策略以防御攻击。cc（challenge collapsar）是一种http层的ddos 攻击，它通过发送大量http层的请求，以达到讣被攻击的目标网站瘫痪的口的。challenge collapsar的中文意思是挑战黑洞，大家可能会觉得它的名字有点怪，这里涉及攻击命名者与 一个防火墙产品的纠葛，黑洞是一款知名的防火墙产品，意思很明显了，命名者想说黑洞 防火墙也防不住他的这种攻击。目前国内领先的儿家ddos清洗设备安全厂商可以基于特

7、征 防御一些普通的cc攻击，但是对于一些没有数据段特征，并目.有大量代理ip的cc攻击仍 然没有办法。这个时候防御的重点战场就必须转移到服务器上來了，通过业务服务器上更多 业务场景的数据，以及更容易编程实现复杂的安全策略优势來检测攻击请求，举个例子， 比如我们通常业务场景下，来自河南省的访问量很少，而攻击的时候该省的访问量上升10 倍，我们可以对该省的访问屋丢掉80%,从而防御攻击，并r最大限度的降低对业务的影 响。所以设计时保证一定的服务器冗余，能够降低攻击开始阶段系统就被攻击到瘫痪的概率，也 为ddos安全专家的安全防御策略提供计算资源。如果有条件的话，最好是把业务部署在云 上，这样被攻击

8、的时候可以动态增加服务器数量，既能节省成本也能保障攻击的时候能够有 效的防护。误区三：数据和代码不分离的设计数据和代码不分离意味曹数据可以被当成代码执行，而数据是可以山用户（攻击者）自己 定义的，也就是说用户（攻击者）可以口定义在系统上执行的代码，那么攻击者可以构造 木马代码，作为数据输入给系统，系统执行这些木马代码后，系统就会被攻击者控制，这样 的设计将给系统带来极大的风险。我们的系统开发过程中其实冇不少这样的案例，下面我 们先看看一个设计导致的上传攻击漏洞的案例。例如一个导致上传攻击漏洞的设计案例，先简单描述一下上传攻击的原理，大部分应用系 统都有上传图片或文件的功能，攻击者利用这些功能上

9、传一个网页木马，如果存放上传文件 的目录有执行脚木的权限，那么攻击者就可以肓接得 到一个webshell,进而控制web服务 器。这个漏洞有两个必要条件，一是可以上传木马，二是存放上传文件的目录具备执行脚本 的权限。上传是业务的功能需要，即便有做各种安全过滤，限制木马上传，但也有各种绕 过过滤的攻击方法，比较难以限制。所以漏洞的关键就在上传的冃录是否具备执行脚本的权 限上，很多设计者会基于降低成本的考虑，将存储上传文件的位證与web应川程序放在同 一服务器，甚至同一目录下，这样上传的目录也和web应用程序一样具备执行脚本的权限, 从而导致系统产生了一个高危上传漏洞。而如果将存储上传文件的位置设

10、计在另一台只具备存储功能的文件服务器或数据库上，与 web应用服务器分开，这样即使木马被上传进來，也因为文件服务器不能执行脚本而没有 办法实施攻击。误区四：封闭设计架 构师设计通常会遵循对扩展开放，对修改封闭的设计原则。对于修改封闭，就是说外部 可以调用系统的接口使用系统的功能，但是看不到系统内部实现的代码，也不能对内部实 现的代码进行修改。这常常给设计者一种错觉，认为外部使用者不知道系统内部是怎么实现 的，不知道存在的安全缺陷，从而放心大胆的在内部辭下许多安全隐患，最常见的就是使 用私有加密算法。设计者常会直观的认为私冇算法拥冇算法的秘密性，所以安全性要比公开常用加密算法更高 些。但其实私有

11、算法的秘密性也是很难保障的首先，中国有句古语“天下没有不透风 的墙”，指不定什么时候你的算法就会通过队友泄露出去，如果你觉得这个说法太虚了， 举个实际的例子，开发人员都喜欢用github,指不定哪个猪队友（有可能是£|己）就会把 你的算法全部上传到github,黑客会放过这么好的机会吗？当然不会，乌云上这些漏洞案 例比比皆是。其次，如果算法没冇泄霧，黑客就不知道你的算法了吗？当然不是，黑客可以 通过很多数学推导的方式，把加密的算法推导出來，例如加密算法的公式通帘如下所示： y=f （x）其中f是加密算法，y是密文，x是明文但只要有足够多的x, y就可以推导出f,比如下面一组【x, y

12、的数据：x=0 0.9375 1.8750 2.8125 3.7500 4.6875 5.6250 6.5625 7.50008.4375 9.3750 10.3125 11.2500 12.1875 13.1250 14.0625 15.0000;y=0.000000e+000 8.789063e-003 3.515625e-002 7.910156e-0021.406250e-001 2.197266e-001 3.164063e-001 4.306641e-001 5.625000e-0017.119141e-001 8.789063e-001 1.063477e+0001.265625

13、e+000 1.485352e+000 1.722656e+000 1.977539e+000 2.250000e+000;通过matlab的最小二乘法就可以计算出f的公式如下：ex/ = /1 + j1 -（k + l）c 讦加密算法是这样，其它的设计也是这样，黑客总是可以通过各种方法收集到攻击目标的大量 信息，要知道攻击的第一步就是情报收集。所以，使用私有加密算法并不能保证加密算法 的私密性，对安全性提升也微乎其微。再加上私有算法的数学复杂性难以达到和公开常用算 法的一样水平（比如rsa算法利用的就是“将两个大索数相乘i分容易，但是想要对其乘 积进行因式分解却极其困难”的数学原理），在算法

14、的实现上也不如公开常用算法一样久 经考验，因此即便封装了的私有加密算法也是不能使用的，加密应该用公开常用的加密算法, 用密钥秘密性而不是算法的秘密性来保障安全。所以，通过此类通过封闭设计隐藏软件的实现，从而隐藏一些安全隐患是非常不可取的！官 方机构对此类行为也有过明确的意见，反对采用执行或者实现的秘密性來保障产品的安全, 美国国家标准少技术研究所（nist）明文表示：“系统的安全性不应该依赖于执行或其部件 的秘密性。软件的设计应该假设是开放的用户和黑客都知道软件是怎么样实现的，而 且即便知道软件的实现也不会危害产品的安全，通过密钥或者鉴权因子就能保障产品数据 的安全。误区五：黑名单防御通常设计

15、者都会知道需耍防御sql注入和xss攻击等安全问题，但是在选择防御的方案吋常 常走入一些误区，他们通常会选择用过滤的方法去防御sql注入和xss攻击等攻击，这种 类似黑名单的防御方式简单方便，修改量小，而且他们认为这样黑客己经攻不进來了。他们 低估了黑客们的智慧和毅力，事实证明凡是采用过滤方式防御sql注入和xss的产晶，无一 不被绕成狗的。乌云上这种被绕过的案例比比皆是，1=1前还没有看到冇一个不被绕过的硬件防火墙，云 waf或主机端的防护产品，即便最新宣称“永别了 sql注入”的sqlchop也很快在乌云被 爆出存在绕过的漏洞，笔者也赞同sqlchop的用数据分析检测sql注入的思路把防护

16、水 平提高了一个等级，但即便这样也依然逃脱不了被绕过的命运。这些如此专业的安全厂商设 计的产品都难逃被绕过的命运，那我们自己的研发人员自己在服务器上开发和部暑的sql 注入和xss攻击过滤功能，是不是会被绕得更惨呢？答案是肯定的。所以对sql注入漏洞 应该用参数化查询的方式來解决，xss漏洞应该用対输出进行编码的方式來解决，过滤的方 法只能作为临时方案川来辅助做深度防御，而绝不能单独作为防御攻击的安全解决方案。误区六：没有将安全列为设计目标之一相比以上谋区，大部分设计最大的误区就是没冇将安全列为设计的冃标这才是产生 以上所有设计安全问题的根源。产牛这样谋区的主要原因有两个，第一，架构师或设计者

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