-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XSS终结者-CSP理论与实践 #5
Comments
哈哈,万能的zjtoolbar |
@ksky521 6到不行 :) |
服务端配置 HTML 返回的响应头 HTTP header |
@chenpengjun 这个响应头的设置方式跟其他响应头是一样呀。跟技术栈关系不大,可以先检查下meta标签的规则是否正确,如果有监控系统的话,可以从数据进行分析。 |
html添加meta标签,nginx配置了http Content-Security-Policy,经过测试发现没有用,后来改为https就解决了。具体的错误信息http://119.188.105.1:8080。加载失败导致网页打不开显示空白页。还是有点疑惑,为什么我这边按照你的思路配置还是不行,是哪里出了问题吗 |
@chenpengjun 具体需要看看是否返回头信息正常,与被劫持插入的文件是否有关系。https是从另外的角度在解决劫持的问题 |
亲。。请教个问题,前端本地写了meta, 如何实践呢。有没有可以看的demo,或者成型的网页,我看了写资料,就发现twitter上有CSP应用,国内有么。目前有这么个项目需求,实在是不知道怎么继续了- -。而且report-uri 好像只有后台可以配,感觉只有前端单方面不能做。。 |
@DongZhouJone 加了meta后,加载一些非白名单的资源,就可以看到报错,并且可以看到上报请求,report-uri 是指明一个上报地址,这是由后台服务提供,收集信息。 |
sir, 重新看了初始文档,原来report-uri 在meta中会被忽略,那就是实践的话只能同过后台配置内容安全的请求头了吧,那上报只能后台测试? |
经过尝试,我发现使用http-header的形式也存在兼容问题(支持ie10+),基于我们的业务是兼容到ie6的,请问是不是用csp来避免xss的方式就不适用了呢 |
请问在您实践中有没有出现正式部署 CSP 后,上报数量逐渐变少的情况? |
@nilptr 不做处理时,上报量没有变少趋势。不过上报量并不是每天一致,时多时少。 |
原文地址
CSP 全称为 Content Security Policy,即内容安全策略。主要以白名单的形式配置可信任的内容来源,在网页中,能够使白名单中的内容正常执行(包含 JS,CSS,Image 等等),而非白名单的内容无法正常执行,从而减少跨站脚本攻击(XSS),当然,也能够减少运营商劫持的内容注入攻击。
示例:在 HTML 的 Head 中添加如下 Meta 标签,将在符合 CSP 标准的浏览器中使非同源的 script 不被加载执行。
不支持 CSP 的浏览器将自动会忽略 CSP 的信息,不会有什么影响。具体兼容性可在caniuse查看
CSP 语法组成
策略类型
CSP 有两种策略类型:
这两种策略类型的主要区别也可以从命名上看出,第一种对不安全的资源会进行阻止执行,而第二种只会进行数据上报,不会有实际的阻止。
当定义多个策略的时候,浏览器会优先采用最先定义的。
指令集合
CSP 的指令是组成内容来源白名单的关键,上面两种策略类型含有以下众多指令,可以通过搭配得到满足网站资源来源的白名单。
指令示例及说明
指令值示例及说明
CSP 的使用方式
HTML Meta 标签
在这种形式中,Meta 标签主要含有两部分的 key-value:
http-equiv 的 value 为 CSP 的策略类型,而 content 则是声明指令集合,即白名单。如
在HTML 的 head 中 添加上面的 Meta 标签,那么当浏览器支持 CSP 标准时,由于使用的是 Content-Security-Policy 实际阻止的策略,所以将会使得非同源的 script(根据指令集合来定)不会被加载及执行。
Meta 标签的 Content-Security-Policy-Report-Only 方式在当前(2016/5/19)多数移动端浏览器上表现正常,但是 不推荐 这样做,如 chrome 50 会产生如下的提示
HTTP Header
通过 Meta 的方式很是简单,但当涉及到的页面较多时,使用 Meta 标签的方式需要在每个页面都各自加上。而如果通过服务端配置 HTML 返回的响应头 HTTP header 带上 CSP 的指令的话,那将能够一劳永逸,同时支持多个页面。下图为响应头
不仅如此,这种形式的 Content-Security-Policy-Report-Only 方式能够得到更好的兼容支持,也是推荐方式。
实践经验
CSP 的阻止加载及执行的方式相当强大,也因为它如此强大,所以在使用时更是要小心谨慎,毕竟,如一个不小心制定了错误的指令集合方案,那将可能导致阻止了正常文件的加载,影响业务功能,这是相当危险的。
一步步制定你的 CSP 方案
1. 通过 HTML Meta 标签进行初步方案的制定(meta标签已不支持report-uri 2019.7)
这种方式实现成本低,只对当前的 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 拦截量
4月4日,CSP 拦截的 URL 前5名
从上面数据也可以看出,每天被攻击的情况呈现出一种稳定持续的倾向,而且这类攻击一般不是针对某个业务的,具备了普遍性,这样的影响范围可想而知。
不过,这也侧面烘托出 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/
查看更多文章 >>
https://github.com/joeyguo/blog
The text was updated successfully, but these errors were encountered: