网络安全（二）安全基础

安全世界观

互联网本来是安全的，自从有看研究安全的人之后，互联网就不安全了。

web安全简史

起初，研究计算机系统和网络的人，被称其为 Hacker ，他们对计算机有这深入的了解，因此往往能够发现其中的问题。Hacker 在中国按照音译，被称为黑客。在计算机安全领域，黑客是一群破坏规则、不喜欢被约束的人，因此总想着能够找到系统的漏洞，已获得一些规则之外的权利。

对现代计算机来说，在用户态的最高权限是 root ,也是黑客们最渴望能够获取的系统最高权限。root 对黑客的吸引。就像大米对老鼠的吸引。

不想拿到 root 的黑客，不是好黑客。漏洞利用代码能够帮助黑客们达成这一目标。黑客们使用的漏洞代码，被称为 exploit 。在黑客的世界里，有的黑客，精通计算机技术，能自己挖掘漏洞，并编写 exploit；而有的黑客，则只对攻击本身感兴趣，对计算机原理和各种变成技术的了解比较粗浅，因此只能懂得编译别人的代码，自己并没有动手能力，这种黑客别称为 Script Kids，即脚本小子。在现实世界里，在造成破坏的，往往并非那些挖掘并研究漏洞的黑客们，而是这些脚本小子。而在今天已经形成产业的计算机犯罪、网络犯罪中造成主要破坏的，也是这些脚本小子。

中国黑客史

中国黑客的发展分为了：启蒙时代、黄金时代、黑暗时代。

启蒙时代为20世纪90年代。此时中国的互联网处于刚刚起步阶段，一些热爱新兴技术的青年受到国外黑客技术的影响，开始研究安全漏洞。启蒙时代的黑客们大多是由个人爱好而走上了这条道路。

黄金时代以中美黑客大战为标志，在这个历史背景下，黑客这个特殊的群体一下子几乎吸引了社会的所有眼球，而此时黑客圈子所宣扬的黑客文化以及黑客技术的独特魅力也吸引了无数的青少年走上这条道路。

最后是黑暗时代，这个阶段从几年前开始一直延续到今天，也许还将继续下去。

黑客技术的发展历程

从黑客技术发展的角度来看，在早期，黑客攻击的目标以系统软件居多。一方面，是由于这个时期的web技术发展还远远不够成熟；另一方面，则是因为通过攻击系统软件，黑客们往往能够直接获取root权限。

这个时期，涌现出非常多的经典漏洞以及 exploit。比如著名的黑客组织TESO,就曾经编写过一个攻击SSH的exploit,并公然在 exploit 的banner中宣称曾经利用这个 exploit 入侵过 cia.gov(美国中央情报局)

root@plac /bin >> ./sshlinux/x86 sshdl exploit by zip/TESO (zip@james.kalifornia.com) - ripped from openssh 2.2.0 srcgreets: mary,random,big t,shlfty,scut,dvorak
ps. this sploit already owned cia.gov :/**please pick a type**Ussage: ./ssh host [options]
Options:-p prot-d baseBase address to start bruteforcing distance, by default 0X1800,
goes as high as 0X10000-t type-d    debug mode-o   Add this to delta_mintype:0: linux/X86 ssh.com 1.2.26-1.2.31 rhl
1: linux/X86 openssh 1.2.3 (maybe others)
2: linux/X86 openssh 2.2.0pl (maybe others)
3: freebsd 4.X, ssh.com 1.2.26-1.2.31 rhl

在早期互联网中，Web并非互联网的主流应用，相对来说，基于SMTP、POP3、FTP、IRC等协议的服务拥有着绝大多数的用户，因此黑客们主要的攻击目标是网络、操作系统以及软件等领域，Web安全领域的攻击与防御技术处于非常原始的阶段。

相对于那些攻击系统软件的 exploit 而言，基于web的攻击，一般只能让黑客获得一个比较低的权限，对黑客的吸引力远远不如直接攻击系统软件。

随后，防火墙技术的兴起改变了互联网安全的格局。越来越多的网络设备厂商开始在网络产品中更加重视网络安全，最终改变了互联网安全的走向。防火墙、ACL技术的兴起，使得直接暴露在互联网上的系统得到了保护。

2003年的冲击波蠕虫是一个里程碑式的事件，这个针对Windows操作系统PRC服务（运行在445端口）的蠕虫，在很短的时间内席卷了全球，造成了数百万台机器被感染，损失难以估量。在此次事件后，网络运营商们很坚决的在骨干网络上屏蔽了 135、445 等端口的连接请求。此次事件之后，整个互联网对于安全的重视达到了一个空前的高度。

运营商、防火墙对于网络的封锁，使得暴露在互联网上的非web服务越来越少，且web技术的成熟使得web应用的功能越来越强大，最终成为了互联网的主流。黑客们的目光，也就渐渐地移动到了web这块大蛋糕上。

web安全的兴起

web攻击的发展也可以分为几个阶段。在web1.0时代，人们更多的是关注服务器端动态脚本的安全问题，比如将一个可执行脚本（俗称Webshell）上传到服务器上，从而获得权限。动态脚本语言的普及，以及web技术发展初期对安全问题认知的不足导致很多 “血案” 的发生，同时也遗留下很多历史问题，比如 PHP 语言至今仍然只能靠较好的代码规范来保证没有文件漏洞，而无法从语言本身杜绝此类安全问题的发生。

SQL注入的出现是web安全史上的一个里程碑，它最早出现大概在1999年，并很快就成为web安全的头号大敌。就如同缓冲区溢出出现时一样，程序员们不得不在日以继夜地去修改程序中存在的漏洞。黑客们发现通过 SQL 注入攻击，可以获取很多重要的、敏感的数据，甚至能够通过数据库获取系统访问权限，这种效果并不比直接攻击系统软件差，web攻击一下子就流行起来。SQL注入漏洞至今仍然是web安全领域中的一个重要组成部分。

XSS（跨站脚本攻击）的出现则是web安全史上的另一个里程碑。实际上 XSS 的出现时间和 SQL 注入的差不多，但是真正引起人们重视则是大概在2003年以后。在经历了MySpace的XSS蠕虫事件后，安全界对XSS的重视提高了很多，OWASP 2007 TOP 10 威胁甚至把XSS排在榜首。

伴随web2.0的兴起，XSS、CSRF等攻击以及变得更为强大。Web攻击的思路也从服务器端转向了客户端，转向浏览器和用户。黑客们天马行空的思路，覆盖了web的每一个环节，变得更加的多样化。

黑帽子、白帽子

正如一个硬币有两面一样，“黑客” 也有好坏之分。在黑客的世界中，往往用帽子的颜色来比喻黑客的好坏。白帽子，则是指那些精通安全技术，但是工作在发黑客领域的专家们；而黑帽子，则是指利用黑客技术造成破坏，甚至进行网络犯罪的群体。

同样是研究安全，白帽子和黑帽子在工作时的心态是完全不同的。

对于黑帽子来说，只要能够找到系统的一个弱点，就可以到达入侵系统的目的；而对于白帽子来说，必须找到系统的所有弱点，不能有遗漏，才能保证系统不会出现问题。这种差异是由于工作环境与工作目标的不同所导致的。白帽子一般为企业或安全公司服务，工作的出发点就是要解决所有的安全问题，因此所看所想必然要求更加全面、宏观；黑帽子的主要目的是要入侵系统，找到对他们有价值的数据，因此黑帽子只需要以点突破，知道对他们有用的一点，以此渗透，因此思考问题的出发点必然是有选择性的、微观的。

从对待问题的角度来看，黑帽子为了完成一次入侵，需要利用各种不同漏洞的组合来达到目的，是在不断的组合问题；而白帽子在设计解决方案时，如果只看到各种问题组合后产生的效果，就会把事情变得复杂，难以细致入微的解决根本问题，所以白帽子必然是在不断地分解问题，再对分解的问题逐个予以解决。

在安全领域普遍的认为：“最大的漏洞就是人”。写的再好的程序，在有人参与的情况下，就可能会出现各种各样不可预知的情况，比如管理员的密码有可能泄露，程序员有可能关掉了安全的配置参数…

安全本质

安全是什么？什么样的情况下会产生安全问题？我们要如何看待安全问题？只有搞明白了这些最基本的问题，才能目标一切防御技术的出发点，才能明白为什么我们要这样做，要那样做。

那么一个安全问题是如何产生的呢？我们不妨先从现实世界入手。火车站、机场里，在乘客们开始正式路程之前，都有一个必要的程序：安全检查。机场的安全检查，会扫描乘客的行李箱，检查乘客身上是否带了打火机、可燃液体等危险物品。抽象的说，这种安全检查就是过滤有害的、危险的东西。

从安全的角度来看，我们将不同的重要程度的区域划分出来

通过一个安全检查（过滤、净化）的过程，可以梳理未知的人或物，使其变得可信任。被划分出来的具有不同信任级别的区域，我们称之为信任域，划分两个不同信任域之间的边界，我们称为信任边界。

数据从高等级的信任区域流向低等级的信任区域，是不需要经过安全检查的；数据从低等级的信任域流向高等级的信任域，则需要经过信任边界的安全检查。

安全的问题是信任的问题

一切的安全方案设计的基础，都是建立在信任关系上的。我们必须相信一些东西，必须有一些最基本的假设，安全方案才能得以建立；如果我们否定一切，安全方案就会如无源之水，无根之木，无法设计，也无法完成。

举例来说，假设我们有份很重要的文件好好保管起来，能想的一个方案是把文件锁在抽屉里。这里就包含几个基本的假设，首先，制作这把锁的工匠是可以信任的，制作抽屉的工匠是可以信任的，最后钥匙还需要保存在一个不会出问题的地方…

没有不出问题的系统

在解决安全问题的过程中，不可能一劳永逸，也就是说“没有银弹”。

安全是一个持续的过程

自从互联网有了安全问题以来，攻击和防御技术就在不断碰撞和对抗的过程中得到发展。从微观上来说，在某一时期可能某一方占了上风；但是从宏观上来看，某一时期的攻击防御技术，都不可能永远有效，永远下去。这是因为防御技术在发展的同时，攻击技术也在不断发展，两者是相互促进的辩证关系。以不变的防御手段对抗不断发展的攻击方式，就烦了刻舟求剑的错误。在安全的领域中，没有银弹。

安全三要素

要全面地认识一个安全问题，我们有很多种办法，但首先要理解安全问题的组成属性。前人通过无数实践，最后将安全的属性总结为为安全三要素，简称为 CIA 分别为。

机密性（Confidentiality）:机密性要求保护数据内容不能泄露，加密是实现机密性要求的常见手段。

例如在之前那的例子中，如果文件不是放在抽屉中，而是放在一个透明的盒子里，那么虽然外人无法直接取得文件，但是因为玻璃盒子是透明的，文件内容可能还是被看到，所以不符合机密性要求。

完整性（Integrity）：要求保护数据内容是完整、没有被篡改的。常见的保证一致性的技术手段是数字签名

传说中清朝康熙皇帝的遗诏，写的是“传位十四子”，当时还是四阿哥的胤禛篡改了遗诏，变成了“传位于四子”。且不说传说的真实性，在故事中，对于这份遗诏的保护显然美欧达到完整性要求。

可用性（Availability）：可用性要求保护资源是“随需而得”

假设一个停车场里有100个车位，在正常情况下，可以停100辆车。但是在某一天，有一个坏人搬了100块石头，把每个车位都占了，停车场无法再提供正常服务。在安全领域中，这种攻击叫做拒绝服务攻击，简称DOS（Denial of Service）。拒绝服务攻击破坏的是安全的可用性。

在安全领域中，最基本的要素就是这三个，后来还有人想扩充这些要素，增加了诸如 可审计、不可依赖性 等，单最最重要的还是以上三个要素。

实施安全评估

一个安全评估过程可以简单的分为4步：资产等级划分、威胁分析、风险分析、确认解决方案

一般来说，按照这个过程来实施安全评估，在结果上不会出现较大的问题。这个实施的过程是层层递进的，前后之间有因果关系。

如果是一个尚未评估的系统，那么应该从第一阶段开始实施；如果是由专职的安全团队长期维护的系统，那么有些阶段可以只实施一次，在这几个阶段中，上一个阶段将决定下一个阶段的目标，需要实施到什么程度。

资产等级划分

互联网安全核心的问题，就是数据安全的问题。

对互联网公司所拥有的资产进行等级划分，就是对数据做等级划分。有的公司最关心的就是客户数据，有的公司最关心的是员工资料信息根据各自业务的不同，侧重点也不同。做资产等级划分的过程，需要与各个业务部门的负责人一一沟通，了解公司最重要的资产是什么，他们最看重的数据是什么。

当完成资产等级划分后，对要保护的目标有了一个大概的了解，接下来就是要划分信任域和信任边界了。

通常我们用一种最简单的方式划分，就是从网络逻辑上划分。比如最重要的数据放在数据库中，那么把数据库的服务圈起来；web应用可以从数据库读写数据，并对外提供服务，那再把web服务器圈起来；最外面是不可信任的Internet。

一个简单网站信任模型

这是最简单的例子，在实际中会遇到比这复杂许多的情况。比如同样是两个应用互相支架存在数据交互业务，那么就要考虑这里的数据交互对于各自应用来说是否是可信的，是否应该在两个应用之间化一个边界，然后对流经边界的数据做安全检查。

危险风险

信任域划好之后，我们如何才能确认危险来自哪里呢？在安全领域里，我们把可能造成危害的来源称为威胁，而把可能会出现的损失称为危险。风险一定是损失和联系在一起的。

什么是威胁分析？威胁分析就是把所有的威胁都找出来，比如使用一个危险模型，帮助我们去想，在哪些方面有可能会存在威胁，这个过程能够避免遗漏，这就是威胁建模。

这是一款由微软提出的，叫做STRIDE模型。

STRIDE是6个单词的搜字幕缩写，我们在分析威胁时，可以从以下6个方面去考虑。

威胁	定义	对应的安全属性
Spoofing（伪装）	冒充他人身份	认证
Tampering（篡改）	修改数据或代码	完整性
Repudiation（抵赖）	否认做过的事情	不可抵赖性
InformationDisclosure（信息泄露）	机密信息泄露	机密性
Denial of Service（拒绝服务）	拒绝服务	可用性
Elevation of Privilege（t提升权限）	未尽授权获得许可	授权

在进行威胁分析时，要尽可能地不遗漏威胁，头脑风暴的过程可以确定攻击面

在维护系统安全时，最让安全工程师沮丧的事情就是花费很多的时间与精力实施安全方案，但是攻击者却利用了事先完全没有想到的漏洞（漏洞的定义：系统中可能被威胁利用以造成危害的地方。）完成入侵。这往往就是由于在确定攻击面时，想的不够全面而导致的。

风险分析

风险由一下因素组成：

Risk = Probability * Damage Potential

影响风险高低的因素，除了造成损失大小外，还需要考虑大发生的可能，要结合具体情况，权衡事件的可能性，才能正确地判断出风险。

如何更科学地衡量风险呢？这里要再介绍一个 DREAD 模型，它也是由微软提出的。DREAD也是几个单词的首字母缩写，它指导我们应该从哪些方面去判断一个威胁风险程度。

等级	高（3）	中（2）	低（1）
Damage Potential	获取完全验证权限；执行管理员操作；非法上传文件	泄露敏感信息	泄露其他信息
Reproducibility	攻击者可以随意再次攻击	攻击者可以重复攻击，但有时间限制	攻击者很难重复攻击过程
Exploitability	初学者在短期内能掌握攻击方法	熟练的攻击者才能完成这次攻击	漏洞条件非常苛刻
Affected users	所有用户，默认配置，关键用户	部分用户，非默认配置	极少数用户，匿名用户
Discoverability	漏洞很显眼，攻击条件很容易获得	在私有区域，部分人能看到，需要深入挖掘漏洞	发现该漏洞及其困难

在DREAD模型里，每一个因素都可以分为高、中、低三个等级。在上班中，高、中、低桑等级分别为3、2、1的分数代表其权重值，因此，我们可以具体计算某一个威胁的风险值。

高危：12~15分中危:8~11分低危：0~7分

类似 STRIDE 和 DREAD 的模型可能还有很多，不同的标准会对应不同的模型，只要是我们觉得这些模型是科学的，就可以帮助我们，就可以使用。

设计出安全方案

安全评估的产出物，就是安全解决方案。解决方案一定要有针对性，这种针对性是由资产等级划分、威胁分析、风险分析等阶段的结果给出的。

设计解决方案不难，难的是如何设计一个好的解决方案。设计一个好的解决方案，是真正考验安全工程师水平的时候。

从产品的角度来说，安全也应该是产品的一种属性。一个从未考虑过安全的产品，至少是不完整的。

比如，我们要评价一个杯子是否好用，除了它能装水，能装多少水外，还要思考这个杯子内壁的材料是否溶解在水里，是否有毒，在高温时会不会熔化，在低温时是否易碎，这些问题都直接影响用户使用杯子的安全性。

对于互联网来说，安全是要为产品的发展与成长保驾护航的。我们不能使用“粗暴”的安全方案去阻碍产品的正常发展，所以应该形成这样一种观点：没有不安全的业务，只有不安全的实现方式。产品需求，尤其是商业需求，是用户真正想要的东西，是业务的意义所在，在设计安全方案时应该尽可能地不要改变商业需求的初衷。

作为安全工程师，要想的就是如何通过简单而有效的方案，解决遇到的安全问题。安全方案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。

好的安全方案对用户应该是透明的，尽可能地不要改变用户的使用习惯。

好的安全产品或模块出来要兼顾用户体验外，还要易于持续改进。一个好的安全模块同时也应该是一个优秀的程序，从设计上也需要做到高聚合、低耦合、易于扩展。

最终，一个优秀的安全方案应该具备以下特点：

能够有效解决问题；

用户体验好；

高性能；

低耦合；

易于扩展与升级；

白帽子兵法

Secure By Default 原则

在设计安全方案时，最基本也最重要的原则就是 “Secure By Default”。在做任何安全设计时，都要牢牢记住这个原则。一个方案设计得是否足够安全，与有没有应用这个原则有很大的关系。实际上，“Secure By Default” 原则，也可以归纳为白名单、黑名单的思想。如果更多地使用白名单，那么系统就会变得更安全。

白名单、黑名单

所谓的白名单和黑名单，白名单就是除了白名单外的所有请求都拒绝。而黑名单则是禁止黑名单的请求连接。

例如：
白名单可以用在上传文件时，除了 .JPG、.JPEG文件以外都不允许上传。
黑名单可以用在上传文件时，只有 .JPEG文件不允许上传。

一般来说白名单比较好用，但是也得注意避免出现类似通配符 * 的问题。

最小权限

Secure By Default 的另一层含义就是 “最小权限”。最小权限原则也是安全设计的基本原则之一。最小权限原则要求系统只授予主题必要的权限，而不要过度授权，这样能有效地减少系统、网络、应用、数据库出错的机会。

比如在 Linux 系统中，一种良好的操作习惯是使用普通账户登录，在执行需要root权限的操作时，再通过 sudo 命令完成。这样能最大化地降低一些误操作导致的风险；同时普通账户被盗用后，与root账户被盗用所导致的后果是完全不同的。

纵深防御原则

与 Secure By Default 一样，Defense in Depth（纵深防御）也是设计安全方案时的重要指导思想。

纵深防御包含两层含义：首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要配合，构成一个整体；其次，要在正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。

多层过滤的体系，就是一种纵深防御，是有立体层次感的安全方案。

纵深防御并不是同一个安全方案要做两遍或者多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。我们常常听到 “木桶理论” 这个词，设计安全方案时最怕出现短板，木桶的一块块板子，就是各种具有不同的安全方案，这些板子要紧密地结合在一起，才能组成一个不漏水的木桶。

在常见的入侵案例中，大多数利用web应用的漏洞，攻击和先获得一个低权限的webshell,然后通过低权限的webshell上传更多的文件，并尝试执行更高权限的系统命令，尝试在服务器上提升权限为root；接下来攻击者再进一步尝试渗透内网，比如数据库服务器所在的网段。

在这类入侵中，如果攻击过程中的任何一个环节设置有效的防御措施，都有可能导致入侵过程功亏一篑。但是世上没有万能灵药，也没有哪种解决方案能够解决所有问题，因此非常有必要将风险分散到系统的各个层面。就入侵的防御来说，我们需要考虑的可能有web应用安全、OS系统安全、数据库安全、网络环境安全等。在这些不同层面设计的安全方案，将组成这个防御体系，这也就是纵深防御的思想。

纵深防御的第二层含义，是要在正确的地方做正确的事情。如何理解呢？它要求我们深入理解威胁的本质，从而租出正确的应对措施。

在 XSS 防御技术的发展过程中，曾经出现过几种不同的解决思路，直到最近几年 XSS 的防御思路才逐渐成熟和同一。

在一开始的方案中，主要是过滤一些特殊字符，比如：

《笑傲江湖》会变成笑傲江湖

尖括号被过滤掉了。

但是这种粗暴的做法常常会改变用户原本想表达的意思，比如：

1<2 可能会变成 1 2

造成这种 “乌龙” 的结果就是因为没有 “在正确的地方做正确的事情”。对于 XSS 防御，对系统取得的用户输入进行过滤其实是不太合适的，因为 XSS 真正产生危害的场景是在用户的浏览器上，或者说服务器端输出的 HTML 页面，被注入恶意代码。只有在拼装 HTML 时输出，系统才能获得 HTML 上下文的语义，才能判断出是否存在误杀等情况。所以 “在正确的地方做正确的事情”，也是纵深防御的一种含义——必须把防御方案放到最合适的地方去解决。

对一个复杂的系统来说，纵深防御是构建安全体系的必要选择。

数据与代码分离原则

另一个重要的安全原则是数据与代码的分离原则。这一原则广泛适用于各种由于 “注入” 而引发安全问题的场景。

实际上，缓存区溢出，也可以认为是程序员违背这一原则的后果——程序在栈或者堆中，将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安全问题的发生。

在web安全中，由于 “注入” 引起的问题比比皆是，如 XSS、SQL Injection、CRLF Injection、X-Path Injection等。此类问题均可以根据 “数据与代码分离原则” 设计出真正安全的问题解决方案，因为这个原则抓住了漏洞形成的本质原因。

以 XSS 为例，它产生的原因是 HTML Injection 或 JavaScript Injection,如果一个页面的代码如下：

<html>
<head>test</head>
<body>
$var
</body>
</html>

其中 $var 是用户能够控制的变量，那么对于这段代码来说：

<html>
<head></head>
<body></body>
</html>

就是程序的代码直线段。

而

$var

就是程序的代码执行段。

如果把用户数据片段 $var 当成代码段来解释、执行，就会引发安全问题。

比如，当 $var 的值是：

<script src=http://evile></script>

时，用户数据被注入到代码片段中。接待这段脚本并执行的过程，是由浏览器来完成的——浏览器将用户数据里的 <script> 标签当做代码来解释——这显然不是程序开发者的本意。

根据数据与代码分离原则，在这里应该对用户数据片段 $var 进行安全处理，可以使用过滤、编码等手段，把可能造成代码混淆的用户数据清理掉，具体到这个案件中，就是针对<、>等符号处理。

有人就要问了:我这里就是要执行一个 <script> 标签，要弹出一段文字，比如：“你好！”，那该怎么办？

在这种情况下，数据与代码的情况就发生了变化，根据数据与代码分离原则，我们就应该重写代码。

<html>
<head>test</head>
<body>
<script>
alert("$var1")
</script>
</body>
</html>

这种情况下，<script> 标签页变成了代码片段的一部分，用户数据只有 $var1 能够控制，从而杜绝了安全问题的发生。

不可预测性原则

前面介绍的几条原则

Secure By Default ：是时刻要牢记的总则；

纵深防御：是更全面、更正确地看待问题；

数据与代码分离：是从漏洞成因上看问题；

接下来要将的是 不可预测性 原则

是从克服攻击方法的角度看问题。

微软的 Windows 系统用户多年来深受缓冲区溢出之苦，因此微软在 Windows 的新版本中增加了许多对抗缓冲区溢出等内存攻击的功能。微软无法要求运行在系统中的软件漏洞，因此它采取的做法是漏洞的攻击方法失效。

比如，使用 DEP 来保证栈堆不可执行，使用 ASLR 让进程的栈基址随机变化，从而使攻击程序无法准确地猜测到内存地址，大大提高了攻击的门槛。经过实践检验，证明微软的这个思路确实是有效的——即时无法修复 code ,但是如果能够使得攻击的方法无效，那么也可以算是成功的防御。

微软使用的 ASLR 技术，在较新版本的 Linux 内核中也支持。在 ASLR 的控制下，一个程序每次启动时，其进程的栈基址都不相同，具有一定的随机性，对于攻击者来说，这就是 “不可预测性”。

不可预测性（Unpreedictable）,能够有效地对抗基于篡改、伪造的攻击。

例如，一个内容管理系统中的文章序号，是按照数字升序排列的，比如 id=100，id=101，id=102…

这样的顺序，使得攻击者能够很方便地遍历出系统中的所有文章编号：找到一个整数，依次递增即可。如果攻击者想要批量删除这些文章，写个简单的脚本：

for(i=0;i<1000;i++){Delete(url+"?id="+i);
}

就可以很简单地达到目的。但是如果该内容管理系统使用了 “不可预测性” 原则，将id的值变得不可预测，攻击者再想批量删除文章，只能通过爬虫将所有页面全部抓下来，再一一进行分析，从而提高了攻击的门槛。

不可预测性原则，可以巧妙地用在一些敏感数据上。比如在 CSRF 的防御技术中，通常使用一个 token 来进行有效的防御。这个 token 能够成功防御 CSRF,就是因为攻击者再实施 CSRF 攻击的过程中，是无法提前预知这个token值的，因此要求 token 足够的复杂时，不能被攻击这猜测到。

不可预测性的实现往往需要用到加密算法、随机数算法、哈希算法，好好使用这条原则，在设计安全方案时往往会事半功倍。

安全是一门朴素的学问，也是一种平衡的艺术。 无论是传统安全，还是互联网安全，其内在的原理是一样的。

以上内容出自道哥的书《白帽子讲web安全》