白帽子讲Web安全

第一篇：世界观安全

第一章：我的安全世界观

一个网站的数据库，在没有任何保护的情况下，数据库服务端口是允许任何人随意连接的；在有了防火墙的保护后，通过ACL可以控制只允许信任来源的访问。这些措施在很大程度上保证了系统软件处于信任边界之内，从而杜绝了绝大部分的攻击来源。

1.1.3Web安全的兴起

常见攻击：SQL注入，XSS（跨站脚本攻击）

“破坏往往比建设容易”，但凡事都不是绝对的。一般来说，白帽子选择的方法，是克服某种攻击方法，而并非抵御单次的攻击。比如设计一个解决方案，在特定环境下能够抵御所有已知的和未知的SQL Injection问题。假设这个方案的实施周期是3个月，那么执行3个月之后，所有的SQL Injection问题都得到了解决，也就意味着黑客再也无法利用SQL Injection这一可能存在的弱点入侵网站了。如果做到了这一点，那么白帽子们就在SQL Injection的局部对抗中化被动为主动了。

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

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

安全问题的本质是信任的问题。

一切的安全方案设计的基础，都是建立在信任关系上的。我们必须相信一些东西，必须要有一些最基本的假设，安全方案才能得以建立。

1.5安全的三要素

安全的三要素是安全的基本组成元素，分别为机密性（Confidentiality），完整性（Integrity），可用性（Availability）。

机密性要求数据内容不能泄露，加密是实现机密性要求的常见手段。如果不将文件存在抽屉里，而是放在透明的盒子里，那么虽然无法得到这个文件，但是文件的内容将会被泄露。

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

可用性要求保护资源是“随需而得”。

举例来说，假如有100个车位，有一天一个坏人搬了100块大石头将车位全占了，那么停车场无法再提供正常服务。在安全领域中叫做拒绝服务攻击，简称DoS（Denial of Service）。拒绝服务攻击破坏的是安全的可用性。

1.6如何实施安全评估

一个安全评估的过程，可以简单地分为4个阶段：1.资产等级划分，2.威胁分析，3.风险分析，4.确认解决方案。

1.6.1资产等级划分

资产等级划分是所有工作的基础，这项工作能够帮助我们明确目标是什么，要保护什么。

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

1.6.2威胁分析

在安全领域，我们把可能造成危害的来源成为威胁（Threat），而把可能会出现的额损失称为风险（Risk）。

威胁分析：
1.头脑风暴
2.STRIDE模型

1.6.2风险分析

风险是由以下因素组成：
Risk=Probability * Damage Potential

衡量风险：
1.DREAD模型

1.7白帽子兵法

1.7.1Secure By Default原则

白名单，黑名单：

实际上，Secure By Default原则，也可以归纳为白名单，黑名单的思想。如果更多地使用白名单，那么系统就会变得更安全。

最小权限原则：

最小原则要求系统只授予主体必要的权限，而不要过度授权，这样能有效地减少系统，网络，应用，数据库出错的机会。

纵深防御原则：

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

1.7.3数据与代码分离原则

这一原则适用于各种由于“注入”而引发安全问题的场景。

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

1.7.4不可预测性原则

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

不可预测性，能有效地对抗基于篡改，伪造的攻击。

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

1.8小结

第二篇：客户端脚本安全

第二章：浏览器安全

一些主要浏览器的安全功能：

2.1同源策略

这一策略极其重要，如果没有同源策略，可能a.com的一段JS脚本，在b.com未曾加载此脚本时，也可以随意修改b.com的页面（在浏览器显示中）。为了不发生混乱，浏览器提出“Origin”（源）的概念。来自不同Origin的对象无法相互干扰。

从上表可以看出，影响”源”的因素有：

1.host（域名或IP地址）
2.子域名
3.端口
4.协议

需要注意的是，对于当前页面来说，页面内存放JS文件的域并不重要，重要的是加载JS的页面所在的域是什么。举例说明：
a.com通过代码<script src=http://b.com/b.js ></script>加载了b.com上的b.js。因为b.js是运行在a.com上的，所以b.js的域就是a.com。

在浏览器中,<script>,<img>,<iframe>,<link>等标签都可以跨域加载资源，而不受同源策略的限制。这些带”src”属性的标签每次加载时，实际上是由浏览器发起了一次GET请求。不同于XMLHttpRequest的是，通过src属性加载的资源，浏览器限制了JS的权限，使其不能读，写返回的内容。

对于XMLHttpRequest，它收到同源策略的约束，不能跨域访问资源，在AJAX应用的开发中尤其需要注意到这一点。

2.2浏览器沙箱

2.3恶意网站拦截

2.4高速发展的浏览器安全

第三章：跨站脚本攻击（XSS）

3.1XSS简介

跨站脚本攻击，英文全称为Cross Site Script，在安全领域叫做”XSS”。XSS攻击，通常指黑客通过”HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。

XSS根据效果的不同可以分为如下几类。

一：反射型XSS

反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说，黑客往往需要诱使用户“点击”一个恶意链接，才能攻击成功。反射型XSS也叫做“非持久型XSS”（Non-persistent XSS）。

二：存储型XSS

存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。也叫做“持久型XSS”(Persistent XSS)。

三：DOM Based XSS

通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

3.2XSS攻击进阶

可以利用XSS payload来窃取Cookie。但”Cookie劫持”并非所有的时候都会有效，有的网站可能会在Set-Cookie时给关键的Cookie**植入HttpOnly标识；有的网站会把Cookie与客户端IP绑定**。

3.3XSS的防御

1.四两拨千斤：HttpOnly

浏览器将禁止页面的JS访问带有HttpOnly属性的Cookie。只能防止XSS后的Cookie劫持攻击。

一个Cookie的使用过程如下:

STEP1.浏览器向服务器发起请求，这个时候没有Cookie
STEP2.服务器返回时发送Set-Cookie头，向客户端浏览器写入Cookie
STEP3.在该Cookie到期前，浏览器访问该域下的所有页面，都将发送该Cookie

在java EE中，给Cookie设置HttpOnly代码如下：

response.setHeader("Set