浏览器安全策略之内容安全策略CSP
开篇：润墨网以专业的文秘视角，为您筛选了一篇浏览器安全策略之内容安全策略CSP范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
编者按：很多人认为，互联网在传递信息的同时也传递着威胁和安全隐患。而Web网站24小时在互联网上开放某些端口、提供相关服务，同时，全球的Web站点不胜枚举、应有尽有。所以，Web网站也成为最容易被攻击者利用的目标。本期的两篇文章，一篇是关于浏览器的内容安全策略头（CSP，Content Security Policy）的技术文章，另一篇则是企业对Web安全网关的应用案例，两个侧面、两个维度，为读者提供应对普遍存在，甚至就发生在身边的Web安全威胁的思路。
2013年11月，Veracode给出的报告指出，全球前一百万个网站中仅有269个网站使用了W3C规范的内容安全策略头（csp，Content Security Policy）。ZoomEye在2014年2月给出的测试报告中，中国排名前7千的域名没有使用CSP的，国内1000的域名（含子域名）中仅发现7个使用了CSP策略，其中还有3个网站CSP出现语法使用错误。
如果说CSP是一个伟大的安全策略，为何全球范围内网站使用率如此之低？是CSP自身的设计存在问题，还是网站管理员们没有去充分了解和利用它？CSP到底是一个什么样的安全策略，是像人们普遍说的它是XSS攻击的终结者吗？
带着以上的疑问，本文将从CSP的概念、发展时间轴、语法使用、如何正确部署CSP、CSP的自有特性、如何利用CSP产生攻击报告、CSP当前使用率、Bypass CSP等众多方面，来给大家全面介绍CSP这个伟大而又被忽视的安全策略。
CSP是以可信白名单作机制，限制网站中是否可以包含某来源内容。默认配置下不允许执行内联代码（块内容、内联事件、内联样式），以及禁止执行eval（）、newFunction（）、setTimeout（[string]， ...）和setInterval（[string]， ...）。
CSP发展时间轴
毋庸置疑，CSP是一个伟大的策略，但CSP从最初设计到被W3C认可制定成通用标准，却经历了一个漫长而曲折的过程。
这要从2007年说起。当时XSS攻击已在OWASP TOP10攻击中排名第一位，CSP的最初的设想就在这一年被Mozilla项目组的Gervase Markham和Web安全界大牛Robert Hansen ‘rsnake’两人共同提出。
2011年3月，Firefox 4.0，首次把CSP当作一种正式的安全策略规范使用到浏览器中。当时火狐使用的是自己定义的X-Content-Security-Policy头。单从CSP推广上看，Firefox4.0的是划时代的，虽然此时的CSP只是Firefox自己定义的一个内部标准，但在此之后，CSP的概念在全球迅速推广。
在随后的2011年9月，谷歌在Chrome浏览器14.0版本时加入CSP，而Chrome浏览器使用的也是自己的CSP标准，它使用X-Webkit-CSP头进行对CSP的解析，这个头从字面上更能看出来Chrome浏览器使用的是Webkit内核。此时，世界主流的两大浏览器Chrome、Firefox都已经支持了CSP。
作为标准的W3C组织顺其自然于2011年11月在官网上了CSP1.0草案。W3C CSP1.0草案语法和Firefox、Chrome中截然不同。一年后，W3C的CSP1.0草案已经到了推选阶段，基本可以正式。
在2012年2月Chrome25版本时，它宣布支持W3C标准的CSP1.0。2013年6月，Firefox宣布在其23版本中全面支持W3C的CSP1.0标准。同样是在2013年6月，W3CCSP1.1标准，里面又加入了不少语法，现在大多浏览器还都不支持。IE10中开始支持CSP中的’sandbox’语法，其他语法暂不支持。
目前各个浏览器对CSP的支持情况可以在http：///#feat=contentsecuritypolicy中查看。
CSP默认特性
1. 阻止内联代码执行
CSP除了使用白名单机制外，默认配置下阻止内联代码执行是防止内容注入的最大安全保障。
这里的内联代码包括：块内容、内联事件、内联样式。
script代码，……
对于块内容是完全不能执行的。例如： getyourcookie（）
内联事件
内联样式
window.setInterval（"alert（'hi'）"， 10）；
new Function（"return foo.bar.baz"）；
如果想执行可以把字符串转换为内联函数去执行。
alert（foo && foo.bar && foo.bar.baz）；
window.setTimeout（function（） { alert（'hi'）； }， 10）；
window.setInterval（function（） { alert（'hi'）； }， 10）；
function（） { return foo && foo.bar && foo.bar.baz }；
同样CSP也提供了“unsafe-eval”去开启执行eval（）等函数，但强烈不建议使用“unsafe-eval”这个指令。
CSP例子
例子1：网站管理员想要所有的内容均来自网站自己的域，不包括子域。
Content-Security-Policy： default-src 'self‘
例子2：网站管理员想要所有的内容来自网站自己的域，还有其他子域的内容。
Content-Security-Policy： default-src
'self' *
例子3：网站管理员想要网站接受信任任意域的图像，指定域的音频视频和指定域的脚本。
Content-Security-Policy： default-src 'self'； img-src *；
media-src ；
script-src
在这条策略中，默认情况下，网站只允许加载自己域的内容，但也有例外：
img-src * 使用*通配符可以加载任意域的图片。
media-src 视频音频只允许加载这两个域的
script-src 脚本只能加载
域的
例子4 ：网站管理员确保在线银行所有内容都通过SSL加载，确保信息不会被截获。
Content-Security-Policy： default-src
https：//
例子5 ：上的真实CSP例子。Github允许加载任何域的内容，但只能加载指定域的脚本，只能加载指定域的样式并可以执行内联样式，只能通过SSL加载指定域的flash插件。
Content-Security-Policy：default-src *；
script-src 'self'
https：//
https：//
https：//
https：//
https：//；
style-src 'self' 'unsafe-inline'
https：//；
object-src https：//
在线CSP编写，可以协助和帮助网站管理员编写出适合自己站点的CSP，请参考http：///。
CSP的错误使用
CSP的语法和指令其实并不复杂，但如果没有充分了解网站业务和安全需求，错误的使用CSP则会适得其反。
（1）笔者在2013年底访问http：//www.grosshandel-hahn.de/，发现CSP策略明显使用错误。该网站使用了X-Content-Security-Policy-Report-Only。此头的意思是让浏览器只汇报日志，不阻止任何内容。但这条策略里却没有给出接收信息日志的地址。
（2）Content-Security-Policy： default-src https：； frame-src ；。这个策略方案是有问题的，此头限制https以外的所有资源，但又允许iframe通过http进行加载。现实中，这样的场景应该很难出现。
CSP分析报告
对于网站管理员来说，CSP的一个强大功能是它可以产生试图攻击你网站的分析报告。你可以用report-uri指令使浏览器发送HTTP POST请求把攻击报告以JSON格式传送到你指定的地址。接下来给大家介绍你的站点如何配置来接收攻击报告。
启用报告
默认情况下，违规报告不会发送。为了能使用违规报告，你必须使用report-uri指令，并至少提供一个接收地址。
Content-Security-Policy： default-src self； report-uri http：///collector.cgi
如果想让浏览器只汇报报告，不阻止任何内容，可以改用Content-Security-Policy-Report-Only头。
违规报告语法
该报告JSON对象包含以下数据：
blocked-uri：被阻止的违规资源
document-uri：拦截违规行为发生的页面
original-policy：Content-Security-Policy头策略的所有内容
referrer：页面的referrer
status-code：HTTP响应状态
violated-directive：违规的指令
CSP的使用率统计
CSP全球范围使用率非常低，而且增加也非常缓慢。而使用Content-Security-Policy-Report-Only进行单独接收攻击报告的网站只有24个。统计中也指出，发现大量网站使用unsafe-inline这个指令，分析其原因可能是由于开发人员很难在页面中彻底消除内联脚本，这很让人失望，所以只能要求制定的CSP策略更加严谨。
对于国内网站使用CSP的情况，笔者委托ZoomEye对此进行了统计。2014年2月发来的统计结果在非常不乐观。根据ZoomEye的统计：国内排名前7000的域名没有使用CSP，国内1000万的域名（含子域名）中发现7个使用了CSP策略，其中还有3个网站CSP语法使用错误。7个域名中3个是知乎网，值得表扬。7个域名列表如下：
www.zhi.hu
CSP语法错误
CSP语法错误
CSP语法错误
在网站安全防御方面，我们还要有很长的路要走。虽然CSP安全策略头只是网站安全整体防御中的一小部分，但合理的利用还是可以起到很好的防护作用。然而在我们分析的百万网站中，CSP的使用率极其低，从这一点来说CSP在中国应该广泛对网站管理员进行科普。
CSP Bypass
一个安全策略从诞生开始将会时不时有一个叫“Bypass”的小伙伴跟随左右。而从辩证角度来讲，多加载一种安全策略，就多了一种Bypass的维度。一旦Bypass出现，就意味着将有一种设计者没有考虑到的方法或技巧，将破坏策略的原有规则。
CSP亦是如此，在一次次被绕过然后在一次次修复过程中，来完善自己的语法和指令。
CSP总结
充分了解CSP安全策略的语法和指令，并最大程度地合理利用和部署这些策略，努力把安全策略发挥到极致，使其最终把危害降低到最低。
CSP并不能消除内容注入攻击，但可以有效地检测并缓解跨站攻击和内容注入攻击带来的危害。
CSP不是作为防御内容注入（如XSS）的第一道防线而设计，而最适合部署在纵深防御体系中。
至于为什么CSP的使用率如此之低，究其原因，CSP虽然提供了强大的安全保护，但是它也造成了如下问题：Eval及相关函数被禁用，内嵌的JavaScript代码将不会执行，只能通过白名单来加载远程脚本。这些问题阻碍了CSP的普及。如果要使用CSP技术保护自己的网站，开发者就不得不花费大量时间分离内联的JavaScript代码和做一些调整。
没有被绕过的策略不是好的策略，从辩证角度来讲，多加载一种安全策略，就多了一种Bypass的维度。在安全领域的“Bypass”是一个曼妙而鬼魅的名字。
应该把CSP安全策略视为是一把可以直插心脏的锋利的尖刀，而不是一根电线杆子杵在那。
（文章有删减，浏览本文完整版请登录中国计算机行业网.cn查询。）