HTML5安全:内容安全策略(CSP)简介
前言:HTML5出现后,网络安全更加受到广泛的关注。Web对于网络安全有哪些改进?我们如何来面对越来越危险的网络欺诈和攻击?下面的文章谈到了W3C对于这个问题的最新解决方案。未来有机会的话,我会针对XSS、P3P、同源策略、CORS(跨域资源共享)和CSP进行关于HTML5内容安全的现场分享。
------------------------华丽的分界线
注意:本文所讨论的API还未最终确定,请在自己的项目中谨慎使用。
万维网的安全策略植根于同源策略。例如http://blog.csdn.net/hfahe的代码只能访问http://blog.csdn.net的数据,而没有访问http://www.baidu.com的权限。每个来源都与网络的其它部分分隔开,为开发人员构建了一个安全的沙箱。理论上这是完美的,但是现在攻击者已经找到了聪明的方式来破坏这个系统。
这就是XSS跨站脚本攻击,通过虚假内容和诱骗点击来绕过同源策略。这是一个很大的问题,如果攻击者成功注入代码,有相当多的用户数据会被泄漏。
现在我们介绍一个全新的、有效的安全防御策略来减轻这种风险,这就是内容安全策略(ContentSecurity Policy,CSP)。
来源白名单
XSS攻击的核心是利用了浏览器无法区分脚本是被第三方注入的,还是真的是你应用程序的一部分。例如Google +1按钮会从https://apis.google.com/js/plusone.js加载并执行代码,但是我们不能指望从浏览器上的图片就能判断出代码是真的来自apis.google.com,还是来自apis.evil.example.com。浏览器下载并执行任意代码的页面请求,而不论其来源。
CSP定义了Content-Security-PolicyHTTP头来允许你创建一个可信来源的白名单,使得浏览器只执行和渲染来自这些来源的资源,而不是盲目信任服务器提供的所有内容。即使攻击者可以找到漏洞来注入脚本,但是因为来源不包含在白名单里,因此将不会被执行。
以上面Google +1按钮为例,因为我们相信apis.google.com提供有效的代码,以及我们自己,所以可以定义一个策略,允许浏览器只会执行下面两个来源之一的脚本。
Content-Security-Policy:script-src 'self' https://apis.google.com
是不是很简单?script-src可以为指定页面控制脚本相关权限。这样浏览器只会下载和执行来自http://apis.google.com和本页自身的脚本。
一旦我们定义了这个策略,浏览器会在检测到注入代码时抛出一个错误(请注意是什么浏览器)。
内容安全策略适用于所有常用资源
虽然脚本资源是最明显的安全隐患,但是CSP还提供了一套丰富的指令集,允许页面控制加载各种类型的资源,例如如下的类型:
content-src:限制连接的类型(例如XHR、WebSockets和EventSource)font-src:控制网络字体的来源。例如可以通过font-src https://themes.googleusercontent.com来使用Google的网络字体。frame-src:列出了可以嵌入的frame的来源。例如frame-src https://youtube.com只允许嵌入YouTube的视频。。img-src:定义了可加载图像的来源。media-src:限制视频和音频的来源。object-src:限制Flash和其他插件的来源。style-src:类似于Script-src,只是作用于css文件。默认情况下,所有的设置都是打开的,不做任何限制。你可以以分号分隔多个指令,但是类似于script-src https://host1.com;script-src https://host2.com的形式,第二个指令将会被忽略。正确的写法是script-src https://host1.com https://host2.com。
例如,你有一个应用需要从内容分发网络(CDN,例如https://cdn.example.net)加载所有的资源,并且知道不需要任何frame和插件的内容,你的策略可能会像下面这样:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
尽管default-src指定了https,脚本和样式不会自动继承。每个指令将会完全覆盖默认资源类型。
未来
W3C的Web应用安全工作组正在制定内容安全策略规范的细节,1.0版本将要进入最后修订阶段,它和本文描述的内容已经非常接近。而public-webappsec@邮件组正在讨论1.1版本,浏览器厂商也在努力巩固和改进CSP的实现。
CSP 1.1在画板上有一些有趣的地方,值得单独列出来:
通过meta标签添加策略:CSP的首选设置方式是HTTP头,它非常有用,但是通过标记或者脚本设置会更加直接,不过目前还未最终确定。WebKit已经实现了通过meta元素进行权限设置的特性,所以你现在可以在Chrome下尝试如下的设置:在文档头添加<metahttp-equiv="X-WebKit-CSP" content="[POLICY GOES HERE]">。
你甚至可以在运行时通过脚本来添加策略。
DOM API:如果CSP的下一个迭代添加了这个特性,你可以通过Javascript来查询页面当前的安全策略,并根据不同的情况进行调整。例如在eval()是否可用的情况下,你的代码实现可能会有些许不同。这对JS框架的作者来说非常有用;并且API规范目前还非常不确定,你可以在规范草案的脚本接口章节找到最新的迭代版本。
新的指令:许多新指令正在讨论中,包括script-nonce:只有明确指定的脚本元素才能使用内联脚本;plugin-types:这将限制插件的类型;form-action:允许form只能提交到特定的来源。
如果你对这些未来特性的讨论感兴趣,可以阅读邮件列表的归档或者加入邮件列表。
本文译自:http://www.html5rocks.com/en/tutorials/security/content-security-policy/
转载请注明:来自蒋宇捷的博客