跨域脚本攻击 XSS 是最多见、危害最大的网页安全漏洞。javascript
为了防止它们,要采起不少编程措施,很是麻烦。不少人提出,能不能根本上解决问题,浏览器自动禁止外部注入恶意脚本?这就是"网页安全政策"(Content Security Policy,缩写 CSP)的来历。本文详细介绍如何使用 CSP 防止 XSS 攻击。
html
CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源能够加载和执行,等同于提供白名单。它的实现和执行所有由浏览器完成,开发者只需提供配置。CSP 大大加强了网页的安全性。攻击者即便发现了漏洞,也无法注入脚本,除非还控制了一台列入了白名单的可信主机。html5
两种方法能够启用 CSP。一种是经过 HTTP 头信息的Content-Security-Policy的字段。java
Content-Security-Policy: script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:
另外一种是经过网页的<meta>标签。编程
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
上面代码中,CSP 作了以下配置。json
脚本:只信任当前域名api
<object>标签:不信任任何URL,即不加载任何资源跨域
样式表:只信任cdn.example.org和third-party.org浏览器
框架(frame):必须使用HTTPS协议加载安全
其余资源:没有限制
启用后,不符合 CSP 的外部资源就会被阻止加载。
Chrome 的报错信息。
Firefox 的报错信息。
CSP 提供了不少限制选项,涉及安全的各个方面。
如下选项限制各种资源的加载。
script-src:外部脚本
style-src:样式表
img-src:图像
media-src:媒体文件(音频和视频)
font-src:字体文件
object-src:插件(好比 Flash)
child-src:框架
frame-ancestors:嵌入的外部资源(好比<frame>、<iframe>、<embed>和<applet>)
connect-src:HTTP 链接(经过 XHR、WebSockets、EventSource等)
worker-src:worker脚本
manifest-src:manifest 文件
default-src用来设置上面各个选项的默认值。
Content-Security-Policy: default-src 'self'
上面代码限制全部的外部资源,都只能从当前域名加载。若是同时设置某个单项限制(好比font-src)和default-src,前者会覆盖后者,即字体文件会采用font-src的值,其余资源依然采用default-src的值。
有时,网页会跟其余 URL 发生联系,这时也能够加以限制。
frame-ancestors:限制嵌入框架的网页
base-uri:限制 <base#href>
form-action:限制 <form#action>
其余一些安全相关的功能,也放在了 CSP 里面。
block-all-mixed-content:HTTPS 网页不得加载 HTTP 资源(浏览器已经默认开启)
upgrade-insecure-requests:自动将网页上全部加载外部资源的 HTTP 连接换成 HTTPS 协议
plugin-types:限制可使用的插件格式
sandbox:浏览器行为的限制,好比不能有弹出窗口等。
有时,咱们不只但愿防止 XSS,还但愿记录此类行为。report-uri就用来告诉浏览器,应该把注入行为报告给哪一个网址。
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
上面代码指定,将注入行为报告给/my_amazing_csp_report_parser这个 URL。
浏览器会使用POST方法,发送一个JSON对象,下面是一个例子。
{ "csp-report": { "document-uri": "http://example.org/page.html", "referrer": "http://evil.example.com/", "blocked-uri": "http://evil.example.com/evil.js", "violated-directive": "script-src 'self' https://apis.google.com", "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser" } }
除了Content-Security-Policy,还有一个Content-Security-Policy-Report-Only字段,表示不执行限制选项,只是记录违反限制的行为。它必须与report-uri选项配合使用。
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
每一个限制选项能够设置如下几种值,这些值就构成了白名单。
主机名:example.org,https://example.com:443
路径名:example.org/resources/js/
通配符:*.example.org,*://*.example.com:*(表示任意协议、任意子域名、任意端口)
协议名:https:、data:
关键字'self':当前域名,须要加引号
关键字'none':禁止加载任何外部资源,须要加引号
多个值也能够并列,用空格分隔。
Content-Security-Policy: script-src 'self' https://apis.google.com
若是同一个限制选项使用屡次,只有第一次会生效。
# 错误的写法 script-src https://host1.com; script-src https://host2.com # 正确的写法 script-src https://host1.com https://host2.com
若是不设置某个限制选项,就是默认容许任何值。
除了常规值,script-src还能够设置一些特殊值。注意,下面这些值都必须放在单引号里面。
'unsafe-inline':容许执行页面内嵌的<script>标签和事件监听函数
unsafe-eval:容许将字符串看成代码执行,好比使用eval、setTimeout、setInterval和Function等函数。
nonce值:每次HTTP回应给出一个受权token,页面内嵌脚本必须有这个token,才会执行
hash值:列出容许执行的脚本代码的Hash值,页面内嵌脚本的哈希值只有吻合的状况下,才能执行。
nonce值的例子以下,服务器发送网页的时候,告诉浏览器一个随机生成的token。
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
页面内嵌脚本,必须有这个token才能执行。
<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa> // some code </script>
hash值的例子以下,服务器给出一个容许执行的代码的hash值。
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
下面的代码就会容许执行,由于hash值相符。
<script>alert('Hello, world.');</script>
注意,计算hash值的时候,<script>标签不算在内。
除了script-src选项,nonce值和hash值还能够用在style-src选项,控制页面内嵌的样式表。
(1)script-src和object-src是必设的,除非设置了default-src。
由于攻击者只要能注入脚本,其余限制均可以规避。而object-src必设是由于 Flash 里面能够执行外部脚本。
(2)script-src不能使用unsafe-inline关键字(除非伴随一个nonce值),也不能容许设置data:URL。
下面是两个恶意攻击的例子。
<img src="x" onerror="evil()"> <script src="data:text/javascript,evil()"></script>
(3)必须特别注意 JSONP 的回调函数。
<script src="/path/jsonp?callback=alert(document.domain)//"> </script>
上面的代码中,虽然加载的脚原本自当前域名,可是经过改写回调函数,攻击者依然能够执行恶意代码。
CSP Is Dead, Long Live CSP! , by Lukas Weichselbaum
An Introduction to Content Security Policy , by Mike West
做者:阮一峰@蚂蚁金服,更多安全类文章,请访问 阿里聚安全博客。