微信号:FrontDev

介绍:分享 Web 前端相关的技术文章、工具资源、精选课程、热点资讯

XSS终结者-CSP理论与实践

2016-06-20 20:58 前端大全

(点击上方公众号,可快速关注)

作者:伯乐在线专栏作者 -  joeyguo

链接:http://web.jobbole.com/86409/

点击 → 了解如何加入专栏作者


CSP 全称为 Content Security Policy,即内容安全策略。主要以白名单的形式配置可信任的内容来源,在网页中,能够使白名单中的内容正常执行(包含 JS,CSS,Image 等等),而非白名单的内容无法正常执行,从而减少跨站脚本攻击(XSS),当然,也能够减少运营商劫持的内容注入攻击。


示例:在 HTML 的 Head 中添加如下 Meta 标签,将在符合 CSP 标准的浏览器中使非同源的 script 不被加载执行。


<meta http-equiv="Content-Security-Policy" content="script-src 'self'">


不支持 CSP 的浏览器将自动会忽略 CSP 的信息,不会有什么影响。具体兼容性可在caniuse查看


CSP 语法组成


策略类型


CSP 有两种策略类型:


  • Content-Security-Policy

  • Content-Security-Policy-Report-Only


这两种策略类型的主要区别也可以从命名上看出,第一种对不安全的资源会进行阻止执行,而第二种只会进行数据上报,不会有实际的阻止。

当定义多个策略的时候,浏览器会优先采用最先定义的。


指令集合


CSP 的指令是组成内容来源白名单的关键,上面两种策略类型含有以下众多指令,可以通过搭配得到满足网站资源来源的白名单。


指令示例及说明


指令 取值示例 说明
default-src ‘self’ cdn.example.com 定义针对所有类型(js/image/css/web font/ajax/iframe/多媒体等)资源的默认加载策略,某类型资源如果没有单独定义策略,就使用默认。
script-src ‘self’ js.example.com 定义针对JavaScript的加载策略
object-src ‘self’ 针对,, 等标签的加载策略
style-src ‘self’ css.example.com 定义针对样式的加载策略
img-src ‘self’ image.example.com 定义针对图片的加载策略
media-src ‘media.example.com’ 针对或者引入的html多媒体等标签的加载策略
frame-src ‘self’ 针对iframe的加载策略
connect-src ‘self’ 针对Ajax、WebSocket等请求的加载策略。不允许的情况下,浏览器会模拟一个状态为400的响应
font-src font.qq.com 针对Web Font的加载策略
sandbox allow-forms allow-scripts 对请求的资源启用sandbox
report-uri /some-report-uri 告诉浏览器如果请求的资源不被策略允许时,往哪个地址提交日志信息。不阻止任何内容,可以改用Content-Security-Policy-Report-Only头
base-uri ‘self’ 限制当前页面的url(CSP2)
child-src ‘self’ 限制子窗口的源(iframe、弹窗等),取代frame-src(CSP2)
form-action ‘self’ 限制表单能够提交到的源(CSP2)
frame-ancestors ‘none’ 限制了当前页面可以被哪些页面以iframe,frame,object等方式加载(CSP2)
plugin-types application/pdf 限制插件的类型(CSP2)


指令值示例及说明


指令值 示例 说明
* img-src * 允许任何内容
‘none’ img-src ‘none’ 不允许任何内容
‘self’ img-src ‘self’ 允许同源内容
data: img-src data: 允许data:协议(如base64编码的图片)
www.a.com img-src www.a.com 允许加载指定域名的资源
*.a.com img-src *.a.com 允许加载a.com任何子域的资源
https://img.com img-srchttps://img.com 允许加载img.com的https资源
https: img-src https: 允许加载https资源
‘unsafe-inline’ script-src ‘unsafe-inline’ 允许加载inline资源(style属性,onclick,inline js和inline css等等)
‘unsafe-eval’ script-src ‘unsafe-eval’ 允许加载动态js代码,例如eval()


CSP 的使用方式


HTML Meta 标签


在这种形式中,Meta 标签主要含有两部分的 key-value:


  • http-equiv

  • content


http-equiv 的 value 为 CSP 的策略类型,而 content 则是声明指令集合,即白名单。如


<meta http-equiv="Content-Security-Policy" content="script-src 'self'">


在HTML 的 head 中 添加上面的 Meta 标签,那么当浏览器支持 CSP 标准时,由于使用的是 Content-Security-Policy 实际阻止的策略,所以将会使得非同源的 script(根据指令集合来定)不会被加载及执行。


Meta 标签的 Content-Security-Policy-Report-Only 方式在当前(2016/5/19)多数移动端浏览器上表现正常,但是 不推荐 这样做,如 chrome 50 会产生如下的提示


The report-only Content Security Policy xxxxxxx was delivered via a element,which is disallowed. The policy has been ignored.


HTTP Header


通过 Meta 的方式很是简单,但当涉及到的页面较多时,使用 Meta 标签的方式需要在每个页面都各自加上。而如果通过服务端配置 HTML 返回的响应头 HTTP header 带上 CSP 的指令的话,那将能够一劳永逸,同时支持多个页面。下图为响应头



不仅如此,这种形式的 Content-Security-Policy-Report-Only 方式能够得到更好的兼容支持,也是推荐方式。


实践经验


CSP 的阻止加载及执行的方式相当强大,也因为它如此强大,所以在使用时更是要小心谨慎,毕竟,如一个不小心制定了错误的指令集合方案,那将可能导致阻止了正常文件的加载,影响业务功能,这是相当危险的。


一步步制定你的 CSP 方案


1. 通过 HTML Meta 标签进行初步方案的制定


这种方式实现成本低,只对当前的 HTML 有效,从而能够进行逐步灰度。当然也存在上面提及的兼容性问题,但如果现在是在移动端上,或者在可预期的浏览器内核上跑的话,在兼容性满足的情况下,那还是可以通过这个方式进行 Report-Only。结合自己业务的资源情况以及在 Chrome 上调试制定初步方案。


2. 使用 HTTP Header 的 Content-Security-Policy-Report-Only 方式进一步确定方案


由于上面的 Meta 标签存在一定的兼容问题,所以当我们制定了初步方案后,就可以开始使用 HTTP Header 的形式,小心驶得万年船,这里还是建议先使用 Report-Only 的方式,并指定上报的 url 来收集阻止的内容,通过上报的数据进行方案的优化,从而进一步确定具体方案。


3. HTTP Header 改用 Content-Security-Policy 策略进行实际拦截阻止


具体的 CSP 方案经过上面两轮洗礼,在分析完上报的数据,确定百无疏漏后,可将HTTP Header 改用 Content-Security-Policy 策略,从而进行实际拦截阻止。


项目实践数据


笔者在实际项目中的进行了 CSP 上报拦截,通过上报的数据可以看到日均劫持达到 20000+ 的量,这对于页面本身 PV 并非很高的情况,在线 PV 占比竟达到了 4%;另一方面,从数据上也可以看出 拦截的主要来源(如下表)


3月1日-4月4日,CSP 拦截量


日期 CSP阻止量 在线PV 占比
2016.03.31 23431 545872 4.31%
2016.04.01 24459 619979 3.95%
2016.04.02 20398 525055 3.88%
2016.04.03 19938 475985 4.19%
2016.04.04 23140 507329 4.56%


4月4日,CSP 拦截的 URL 前5名


排名 被 拦截的 URL CSP拦截量
1 http://wap.zjtoolbarc60.10086.cn:8080 5410
2 http://wap.toolbar.sd.chinamobile.com:8080 2690
3 http://119.188.105.1:8080 1498
4 http://211.137.132.89:9090 947
5 http://n.cosbot.cn 675


从上面数据也可以看出,每天被攻击的情况呈现出一种稳定持续的倾向,而且这类攻击一般不是针对某个业务的,具备了普遍性,这样的影响范围可想而知。


不过,这也侧面烘托出 CSP 的强大,简单处理就能够阻止如此多的攻击,赶紧接入吧。


参考


https://www.w3.org/TR/CSP/#changes-from-level-1

http://w3c.github.io/webappsec-csp/

http://content-security-policy.com/

https://www.w3.org/TR/2012/CR-CSP-20121115/



【今日微信公号推荐↓】

更多推荐请看值得关注的技术和设计公众号


其中推荐了包括技术设计极客 和 IT相亲相关的热门公众号。技术涵盖:Python、Web前端、Java、安卓、iOS、PHP、C/C++、.NET、Linux、数据库、运维、大数据、算法、IT职场等。点击《值得关注的技术和设计公众号》,发现精彩!


 
前端大全 更多文章 详解Javascript中的Object对象 结合个人经历总结的前端入门方法 前端不为人知的一面–前端冷知识集锦 一份优秀的前端开发工程师简历是怎么样的? 浅谈Web缓存
猜您喜欢 Growth Hacking系列 | 黑客式营销 SpeeDO —— 并行深度学习系统 API 调用次数限制实现 怎样在技术面试中刷掉牛逼的程序员 程序员如何挑选自己的专业方向