CSP全称Content Security Policy
,可以直接翻译为内容安全策略,说白了,就是为了页面内容安全而制定的一系列防护策略. 通过CSP
所约束的的规责指定可信的内容来源(这里的内容可以指脚本、图片、iframe、fton、style
等等可能的远程的资源)。通过CSP协定,让WEB处于一个安全的运行环境中。
有什么用?
我们知道前端有个很著名的”同源策略”,简而言之,就是说一个页面的资源只能从与之同源的服务器获取,而不允许跨域获取.这样可以避免页面被注入恶意代码,影响安全.但是这个策略是个双刃剑,挡住恶意代码的同时也限制了前端的灵活性,那有没有一种方法既可以让我们可以跨域获取资源,又能防止恶意代码呢?
答案是当然有了,这就是csp
,通过csp
我们可以制定一系列的策略,从而只允许我们页面向我们允许的域名发起跨域请求,而不符合我们策略的恶意攻击则被挡在门外.从而实现
需要说明的一点是,目前主流的浏览器都已支持csp
.所以我们可以放心大胆的用了.
指令就是csp中用来定义策略的基本单位,我们可以使用单个或者多个指令来组合作用,功能防护我们的网站.
以下是常用的指令说明:
指令名 | demo | 说明 |
---|---|---|
default-src | ‘self’ cdn.example.com | 默认策略,可以应用于js文件/图片/css/ajax请求等所有访问 |
script-src | ‘self’ js.example.com | 定义js文件的过滤策略 |
style-src | ‘self’ css.example.com | 定义css文件的过滤策略 |
img-src | ‘self’ img.example.com | 定义图片文件的过滤策略 |
connect-src | ‘self’ | 定义请求连接文件的过滤策略 |
font-src | font.example.com | 定义字体文件的过滤策略 |
object-src | ‘self’ | 定义页面插件的过滤策略,如 <object>, <embed> 或者<applet> 等元素 |
media-src | media.example.com | 定义媒体的过滤策略,如 HTML6的 <audio>, <video> 等元素 |
frame-src | ‘self’ | 定义加载子frmae的策略 |
sandbox | allow-forms allow-scripts | 沙盒模式,会阻止页面弹窗/js执行等,你可以通过添加allow-forms allow-same-origin allow-scripts allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, and allow-top-navigation 策略来放开相应的操作 |
report-uri | /some-report-uri |
所有以-src
结尾的指令都可以用一下的值来定义过滤规则,多个规则之间可以用空格来隔开
值 | demo | 说明 |
---|---|---|
* | img-src * | 允许任意地址的url,但是不包括 blob: filesystem: schemes. |
‘none’ | object-src ‘none’ | 所有地址的咨询都不允许加载 |
‘self’ | script-src ‘self’ | 同源策略,即允许同域名同端口下,同协议下的请求 |
data: | img-src ‘self’ data: | 允许通过data来请求咨询 (比如用Base64 编码过的图片). |
domain.example.com | img-src domain.example.com | 允许特性的域名请求资源 |
*.example.com | img-src *.example.com | 允许从 example.com下的任意子域名加载资源 |
https://cdn.com | img-src https://cdn.com | 仅仅允许通过https协议来从指定域名下加载资源 |
https: | img-src https: | 只允许通过https协议加载资源 |
‘unsafe-inline’ | script-src ‘unsafe-inline’ | 允许行内代码执行 |
‘unsafe-eval’ | script-src ‘unsafe-eval’ | 允许不安全的动态代码执行,比如 JavaScript的 eval()方法 |
例子:
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline' my.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' my.com">
内容安全策略(CSP),其核心思想十分简单:网站通过发送一个 CSP 头部,来告诉浏览器什么是被授权执行的与什么是需要被禁止的。其被誉为专门为解决XSS攻击而生的神器。
内容安全策略 (CSP
) 是一个额外的安全层,用于检测并削弱某些特定类型的攻击,包括跨站脚本 (XSS
) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件,这些攻击都是主要的手段。
CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供配置。
CSP 大大增强了网页的安全性。攻击者即使发现了漏洞,也没法注入脚本,除非还控制了一台列入了白名单的可信主机。
限制资源获取
报告资源获取越权
default-src
限制全局
制定限制类型
资源类型有:connect-src、mainfest-src、img-src、font-src、media-src、style-src、frame-src、script-src…
CSP 的主要目标是减少和报告 XSS 攻击 ,XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行,因为浏览器信任其内容来源,即使有的时候这些脚本并非来自于它本该来的地方。
CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件,忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。
作为一种终极防护形式,始终不允许执行脚本的站点可以选择全面禁止脚本执行。
除限制可以加载内容的域,服务器还可指明哪种协议允许使用;比如 (从理想化的安全角度来说),服务器可指定所有内容必须通过HTTPS加载。一个完整的数据安全传输策略不仅强制使用HTTPS进行数据传输,也为所有的cookie
标记安全标识 cookies with the secure flag
,并且提供自动的重定向使得HTTP页面导向HTTPS版本。网站也可以使用 Strict-Transport-Security HTTP
头部确保连接它的浏览器只使用加密通道。
CSP分类:
(1)Content-Security-Policy
配置好并启用后,不符合 CSP 的外部资源就会被阻止加载。
(2)Content-Security-Policy-Report-Only
表示不执行限制选项,只是记录违反限制的行为。它必须与report-uri
选项配合使用。
CSP的使用:
(1)在HTTP Header
上使用(首选)
"Content-Security-Policy:" 策略
"Content-Security-Policy-Report-Only:" 策略
(2)在HTML上使用
<meta http-equiv="content-security-policy" content="策略">
<meta http-equiv="content-security-policy-report-only" content="策略">
Meta 标签与 HTTP 头只是行式不同而作用是一致的,如果 HTTP 头与 Meta 定义同时存在,则优先采用 HTTP 中的定义。
如果用户浏览器已经为当前文档执行了一个 CSP
的策略,则会跳过 Meta
的定义。如果 META
标签缺少 content
属性也同样会跳过。
CSP使用实例:
1.一个网站管理者想要所有内容均来自站点的同一个源 (不包括其子域名)
Content-Security-Policy: default-src 'self'
2.一个网站管理者允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
Content-Security-Policy: default-src 'self' *.trusted.com
3.一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得),所有脚本必须从特定主机服务器获取可信的代码.
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
在这里,各种内容默认仅允许从文档所在的源获取, 但存在如下例外:
media1.com
和 media2.com
加载(不允许从这些站点的子域名)。userscripts.example.com
。4.一个线上银行网站的管理者想要确保网站的所有内容都要通过SSL方式获取,以避免攻击者窃听用户发出的请求。
Content-Security-Policy: default-src https://onlinebanking.jumbobank.com
该服务器仅允许通过HTTPS方式并仅从onlinebanking.jumbobank.com
域名来访问文档。
5.一个在线邮箱的管理者想要允许在邮件里包含HTML,同样图片允许从任何地方加载,但不允许JavaScript或者其他潜在的危险内容(从任意位置加载)。
Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *
注意这个示例并未指定script-src
。在此CSP示例中,站点通过 default-src
指令的对其进行配置,这也同样意味着脚本文件仅允许从原始服务器获取。
report-only
)模式为降低部署成本,CSP可以部署为报告(report-only
)模式。在此模式下,CSP策略不是强制性的,但是任何违规行为将会报告给一个指定的URI地址。此外,一个报告模式的头部可以用来测试一个修订后的未来将应用的策略而不用实际部署它。
你可以用Content-Security-Policy-Report-Only HTTP
头部来指定你的策略,像这样:
Content-Security-Policy-Report-Only: policy
如果Content-Security-Policy-Report-Only
头部和 Content-Security-Policy
同时出现在一个响应中,两个策略均有效。在Content-Security-Policy
头部中指定的策略有强制性 ,而Content-Security-Policy-Report-Only
中的策略仅产生报告而不具有强制性。
支持CSP的浏览器将始终对于每个企图违反你所建立的策略都发送违规报告,如果策略里包含一个有效的report-uri
指令。
默认情况下,违规报告并不会发送。为启用发送违规报告,你需要指定 report-uri
策略指令,并提供至少一个URI地址去递交报告:
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
然后你需要设置你的服务器能够接收报告,使其能够以你认为恰当的方式存储并处理这些报告。