Question

导致现在这种Web前端混乱局面的原因有很多，W3C在进化着，各家的浏览器也在进化着，整体是一个好趋势，现在的混乱主要是因为初期的设计忽略了大量安全的因素，几乎都是以“如何将WWW友好地呈现在大家面前”为第一要务。

现代浏览器都开始意识到安全问题了，于是都很愿意去遵守他们共同推进的W3C标准，可以肯定的是，我们会发现越来越多网站的前端混乱局面会有很好的改善。

下面让我们来看看浏览器在前端安全上都做了哪些努力。

10.1.1　HTTP响应的X-头部

HTTP响应的扩展头部字段都以X-打头，用于区分标准的头部字段。与前端安全有关系的头部字段有如下几个：

· X-Frame-Options

· X-XSS-Protection

· X-Content-Security-Policy

前两个大家应该都很熟悉了，第一个与防御ClickJacking有关，第二个与防御反射型XSS有关，第三个会在后面介绍。

1. X-Frame-Options

X-Frame-Options的值有以下两个：

· DENY（禁止被加载进任何frame）。

· SAMEORIGIN（仅允许被加载进同域内的frame）。

这个标准已经被现代浏览器兼容得非常好了。为什么浏览器不强制设置DENY或SAMEORI-GIN，这样就不需要Web厂商去配置这样的响应头了？这是由于还有大量的网站通过iframe方式加载第三方域的页面，以满足网站自身特色的业务需求，浏览器的每一次进化第一任务一定是兼容。

2. X-XSS-Protection

X-XSS-Protection的值有以下三个：

· 0（表示禁用这个策略）。

· 1（默认，对危险脚本做一些标志或修改，以阻止在浏览器上熏染执行，Chrome和IE这方面的行为是有差异的）。

· 1; mode=block（强制不熏染，在Chrome下直接跳转到空白页，在IE下返回一个#符号）。

在最新的Chrome与IE浏览器中都得到了很好的支持。不过这个策略仅针对反射型XSS，有向部分DOM XSS防御改进的趋势。另外，这个策略是对付不了存储型XSS的。这个策略的这些缺陷是不可避免的，能识别出反射型XSS是因为提交请求的URL中带有可疑的XSS代码片段，当浏览器通过大量正则匹配到时，就会触发对应的防御机制，在响应时，如果发现这段可疑的XSS代码片段进入DOM中，相关的防御机制就会开始生效。

而对于存储型XSS，不可能出现这样的过程，浏览器无法区分从后端存储输出到浏览器前端的JavaScript代码是合法的还是非法的。

上面这两个策略已经在Google、Twitter等大网站都使用了，这是一种趋势，不过我们更看好X-Content-Security-Policy（即CSP策略），它必将成为主流。

10.1.2　迟到的CSP策略

前面我们提到Web前端混乱局面，比如IE下的CSS的expression可以写JavaScript，再如，HTML的标签<script>、标签on事件、标签style属性、标签src/href/action等属性都可以内嵌JavaScript执行。为什么没有很好地分离？HTML仅做HTML的事，JavaScript/CSS都通过加载独立文件的方式被执行。如果这样分离，我们不用担心HTML中直接出现JavaScript的风险，而且JavaScript/CSS独立文件所在的域可以配置为白名单，这样就能有效地防止加载攻击者域上的相关资源文件。这就大大提高了XSS攻击的难度，这就是CSP策略的最大设计初衷。

CSP策略使得Web前端更有序，从而更安全，这是一个好趋势，W3C已经在大力推进这样的策略（http://www.w3.org/TR/CSP/）。Firefox与Chrome已经开始支持，IE 10也会开始支持，以下描述的是一种按标准实现理想的状态，经过我们测试，有些标准并没有严格实现，导致不该出现的风险还可能出现。

注：目前，Chrome支持CSP策略的头部是X-WebKit-CSP，而不是标准的X-Content- Security-Policy，但是具体策略都一样，以下统一使用X-Content-Security-Policy进行描述。

CSP策略由一些指令构成，每个指令以分号（;）分隔，语法格式如下：

X-Content-Security-Policy: [指令1] [指令值1] [指令值2]; [指令2] [指令值1] ...

目前X-Content-Security-Policy包含的指令及描述如表10-1所示。

表10-1　X-Content-Security-Policy指令

除了以上常规指令外，还有一个特殊指令re-port-uri，用于将违法CSP策略的告警信息传输给report-uri指定的地址中，这样可以有效地评估目标页面的CSP策略动态，比如攻击者尝试的XSS攻击。

针对以上指令，下面举几个应用CSP的场景。

场景一：不允许任何外部的资源加载，且允许内嵌脚本执行。

响应头如下：

X-Content-Security-Policy: default-src 'unsafe-inline' 'self'

在这样的场景中，当进行XSS攻击时，就无法注入远程的js文件。

场景二：仅允许白名单的外部资源加载，不允许内嵌脚本执行。

响应头如下：

X-Content-Security-Policy: default-src *.foo.com

在这样的场景中，当进行XSS攻击时，要想成功，只能注入<script>对象，并加载攻击者可控的*.foo.com白名单下任意脚本文件，比如，一些JSON callback文件（如果可以注入任意JavaScript的话）。

这个场景还可以对外部资源进行细分，比如图片、Flash、样式、脚本等文件，这样的场景保证了HTML仅做HTML的事，脚本逻辑等都放在了独立的资源文件中，是一种非常漂亮的分离策略，这样的策略除了自身很优美之外，还大大提高了前端安全性。

当CSP策略开始普遍流行的时候，跨站师们就开始头疼了，XSS攻击会因为前端的有序化而逐渐失去光彩，只是这需要时间。很多网站要做好CSP策略的兼容，也是需要时间与精力去改变的，但这绝对会是一个趋势。