标签： CSP

为了减缓跨站脚本攻击，网站开发者应该包含控制脚本和插件资源的指令。他们可以这样做：

• 包含script-src和object-src指令或
• 一个default-src指令

开发者不应在策略中包含’unsafe-inline’或data:指令。他们都会允许通过文档中直接包含的代码进行XSS攻击。因此最好彻底避免使用这两个指令。

child-src
child-src指令管理嵌套浏览上下文（iframe、frame）和Worker执行上下文。
示例：
Content-Security-Policy: child-src https://example.com/
下面的代码会引发网络错误，因为url不匹配给出的url模式：

<iframe src="https://not-example.com"></iframe>
var blockedWorker = new Worker("data:application/javascript,...");

connect-src
connect-src指令限制从脚本接口加载的url。
通过脚本接口加载资源的方式指：fetch、XHR、eventSource、Beacon、a标签的ping、WebSocket。
示例：
Content-Security-Policy: connect-src https://example.com/
下面代码会引发网络错误：

<a ping="https://not-example.com">...
  var xhr = new XMLHttpRequest();
  xhr.open('GET', 'https://not-example.com/');
  xhr.send();

  var ws = new WebSocket("https://not-example.com/");

  var es = new EventSource("https://not-example.com/");

  navigator.sendBeacon("https://not-example.com/", { ... });

default-src
default-src指令是在其他指令没有定义时的默认指令。
示例：

Content-Security-Policy: default-src 'self'
相当于下面的指令：
Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src 'self';
                         style-src 'self';
                         worker-src 'self'
以下指令：
Content-Security-Policy: default-src 'self'; script-src https://example.com
等价于：
Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src https://example.com;
                         style-src 'self';
                         worker-src 'self'

font-src
font-src指令限制字体文件资源加载的URL。
示例：
Content-Security-Policy: font-src https://example.com/
下面的代码会触发网络错误：

@font-face {
    font-family: "Example Font";
    src: url("https://not-example.com/font");
  }
  body {
    font-family: "Example Font";
  }

frame-src
frame-src指令限制嵌套浏览上下文加载的URL。
示例：
Content-Security-Policy: frame-src https://example.com/
下面的代码会触发网络错误：

<iframe src="https://not-example.com/"></iframe>

img-src
img-src指令限制了图片资源加载的URL。
示例：
Content-Security-Policy: img-src https://example.com/
下面代码会触发网络错误：

<img src="https://not-example.com/img" />

manifest-src
manifest-src指令限制应用的manifests文件资源加载的URL。
示例：
Content-Security-Policy: manifest-src https://example.com/
下面代码会触发网络错误：

<link rel="manifest" href="https://not-example.com/manifest">

media-src
media-src指令限制了音频、视频、相关文本追踪的URL。
示例：
Content-Security-Policy: media-src https://example.com/
下面代码会触发网络错误：

<audio src="https://not-example.com/audio"></audio>
<video src="https://not-example.com/video">
    <track kind="subtitles" src="https://not-example.com/subtitles">
</video>

object-src
object-src指令限制插件内容加载的URL。
示例：
Content-Security-Policy: object-src https://example.com/
下面代码会触发网络错误：

<embed src="https://not-example.com/flash"></embed>
<object data="https://not-example.com/flash"></object>
<applet archive="https://not-example.com/flash"></applet>

如果插件的内容没有通过相关的URL（如object元素没有data属性，但是根据指定的类型加载了默认的插件），除非object-src的值是’none’必须阻止，否则都会允许。

script-src
script-src指令限制脚本执行的位置。这不仅包含直接通过script元素引用的URL还包括内联脚本块和XSLT样式表触发的脚本执行。

style-src
style-src指令限制样式应用的位置。包括link标签、@import、HTTP头加载的样式。

worker-src
worker-src指令限制Worker、SharedWorker或ServiceWorker加载的URL。
示例：
Content-Security-Policy: worker-src https://example.com/
下面代码会引发网络错误：

var blockedWorker = new Worker("data:application/javascript,...");
  blockedWorker = new SharedWorker("https://not-example.com/");
  navigator.serviceWorker.register('https://not-example.com/sw.js');

base-uri
base-uri指令限制base元素中的URL。

plugin-types
plugin-types指令限制可被加载的插件类型。
示例：
Content-Security-Policy: plugin-types application/pdf
下面代码会引发网络错误：

<!-- No 'type' declaration(没有声明type) -->
<object data="https://example.com/flash"></object>

<!-- Non-matching 'type' declaration(声明的type和允许的type不一致) -->
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>

<!-- Non-matching resource(虽然声明的type一致，但其实返回的资源还是个flash类型，也会报错) -->
<object data="https://example.com/flash" type="application/pdf"></object>

下面的策略：
Content-Security-Policy: plugin-types application/x-shockwave-flash
会成功加载如下资源：

<!-- Matching 'type' declaration and resource -->
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>

sandbox
sandbox指令指定一个客户端需要应用于资源的HTML沙箱策略，就如同包含于带sandbox属性的iframe标签中。

disown-opener
disown-opener指令确保资源与其opener断绝关系。

form-action
form-action指令限制form表单提交的URL。

frame-ancestors
frame-ancestors指令限制可以被通过frame、iframe、object、embed、applet元素嵌入的资源的URL。

report-uri
report-uri指令用于报告非法请求，已过时，应使用report-to指令代替。

report-to
report-to指令用于发送非法的请求信息。

一、介绍
为了减缓XSS攻击，一个web应用可以声明它只可以从指定的可信源加载脚本。这个声明允许客户端检测并阻止恶意的脚本被黑客注入到应用中。
CSP并不应作为防御内容注入漏洞的第一道防线，而是用于深度防护，它是为了减少由内容注入攻击造成的伤害。防御内容注入的第一道防线，应该由服务器来验证输入，以及对输出进行编码。
通常会对现有的web应用实现CSP策略，为了获得最大的利益，作者需要移除所有内联脚本和内联样式，例如将他们移动到外部脚本中。因为浏览器不能判断内联脚本是否是由攻击者注入的。
web应用程序通过Content-Security-Policy HTTP头来使用CSP策略。这些策略只适用于当前的资源。如果要为整个站点提供一个策略，服务器需要对每个资源进行声明。
应用示例：
开发者想要保护他们的应用免受跨站脚本攻击。他们只希望加载并执行可信的CDN上的脚本，并且他们希望确保在网页环境中不能执行插件，下面的政策可以实现：
Content-Security-Policy: script-src https://cdn.example.com/scripts/; object-src 'none'

二、第二版相对第一版本的变化
1.现在如果资源加载是重定向的结果，源表达式的路径组件会被忽略。
2.现在受保护的资源可以加载Workers由child-src而不是script-src控制。
3.Workers现在有自己的策略，从加载它们的保护资源中分离。
4.base-url控制受保护的资源可以从指定的文档基础URL加载。
5.child-url代替了frame-src，控制受保护的资源能够嵌入框架并加载Workers。（第三版又有变化）
6.form-action控制受保护的资源的表单提交。
7.frame-ancestors控制受保护资源能否嵌入其他文档。它意图取代X-Frame-Options HTTP请求头。
8.plugin-types控制受保护资源能否加载指定类型的插件。
9.特殊的内联脚本和样式可以通过随机数和哈希加入白名单。
10.CSP请求头现在跟随相关请求头发送。
11.SecurityPolicyViolationEvent事件会在违反策略时触发。
12.新增了一些违反策略的报告（通过report-uri提交以及通过SecurityPolicyViolationEvent事件）。它包括effectiveDirective、statusCode、sourceFile、lineNumber以及columnNumber。
13.现在在sandbox指令中的标志会影响Worker的实例。

三、第三版相对于第二版的变化
1.在CSP第二版中被废弃的frame-src指令，又生效了，worker-src指令添加了进来。如果两者都未出现则遵从child-src指令（如果仍没有则为default-src指令）。
2.URL匹配规则目前把不安全的模式和端口视为它们的安全变种。也就是说http://example.com:80将会同时匹配http://example.com:80和https://example.com:443
‘self’现在匹配https和wss，即使页面是http
3.从内联脚本和内联样式生成的违反报告现在报告“inline”作为阻止资源。阻止eval()的执行会报告“eval”。
4.增加了manifest-src指令。
5.report-uri指令废弃，使用新的report-to指令代替。
6.disown-opener指令确保资源不会被其他浏览器上下文控制。

四、策略的传达
服务器通过HTTP响应头向客户端传达策略。
1.Content-Security-Policy头域
Content-Security-Policy头域是传达策略的较好的机制，它的语法如下：
"Content-Security-Policy":策略字符串
例如，一个响应可能会包含以下头域：
Content-Security-Policy: script-src 'self'
服务器禁止发送多于1个叫做Content-Security-Policy的HTTP头域。
服务器可以针对不同的类型的资源发送不同的值。
在收到服务器响应至少一个Content-Security-Policy头域时，客户端必须执行其中的所有策略。

2.Content-Security-Policy-Report-Only头域
Content-Security-Policy-Report-Only头域只是监控策略而不执行，语法如下：
"Content-Security-Policy-Report-Only":策略字符串
例如，服务器操作员可能希望开发它们的安全策略迭代。操作者可以部署一个report-only策略以检测它们的表现：

Content-Security-Policy-Report-Only: script-src 'self';
                                     report-to csp-reporting-endpoint

在他们的网站中，违反策略的客户端会发送违反报告到report-to中指定的URL上，但是仍然允许违反策略的资源加载。一旦确认策略配置的正确，他们就可以使用Content-Security-Policy头域强制执行。
服务器禁止发送多于1个叫做Content-Security-Policy-Report-Only的HTTP头域。
服务器可以针对不同的类型的资源发送不同的值。
在收到服务器响应至少一个Content-Security-Policy-Report-Only头域时，客户端必须监控其中的所有策略。
Content-Security-Policy-Report-Only头在meta元素中不支持。

3.HTML meta元素
服务器可以通过一个或多个meta元素支持策略。例如：

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

4.CSP HTTP请求头
CSP头域声明了一个特殊的请求，它是一个策略的主题，它的值定义为下面的ABNF语法：
"CSP:" csp-header-value
csp-header-value = *WSP “active” *WSP
如果用户代理在监控或执行一个包含指令值为源列表的策略，那么用户代理必须与不匹配受保护的资源的来源请求一同发送一个叫做CSP的头域，它的值必须是active。
用户代理可以选择发送这个头，仅当请求的资源类型是活动的策略。也就是说，给定的策略img-src example.com，用户代理会同图片请求一同发送CSP:active头，可以在其他类型的资源中不添加这个头。

5.执行多个策略
上文说道，当有多条策略出现时，每一条必须根据相关类型被执行或报告：

Content-Security-Policy: default-src 'self' http://example.com http://example.net;
                         connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                         script-src http://example.com/

连接到example.com是否允许？回答是不允许。执行多个策略指的是通过所有的策略。即使第二条策略会允许连接，但第一条策略包含connect-src ‘none’，所以它会阻止连接。向策略列表添加额外的策略只会更进一步的限制保护资源的能力。
进一步证明，考虑在这个页面的一个脚本。第一个策略会通过default-src指令锁定脚本资源到自身、http://example.com和http://example.net来源。第二条，只会允许脚本来源于http://example.com/。脚本只会在两个策略同时符合时加载，这个例子中来源只有是http://example.com/时符合。

五、策略语法
CSP使用分号“;”分割多个策略。每个策略由下面的语法构成：
WSP表示空白字符，VCHAR表示可打印字符

policy-token    = [ directive-token *( ";" [ directive-token ] ) ]
directive-token = *WSP [ directive-name [ WSP directive-value ] ]
directive-name  = 1*( ALPHA / DIGIT / "-" )
directive-value = *( WSP /  )

解析策略步骤：
1.让directives集合为空的集合
2.遍历每一个非空的token，返回以分号为分隔符对policy进行严格的拆分：
I.跳过空白字符
II.收集非空格的其他字符序列，它们是指令名称
III.如果在token中仍然有字符保留，跳过开头的一个字符（一定是一个空格）
IV.token剩下的字符（如果由）就是指令的值
V.如果指令集合已经包含一个大小写不敏感的匹配指令名，忽略这个指令，继续下一个token
VI.添加指令到指令集合中，名为指令名，值为指令值
3.返回指令集合

具体指令的用法会在后面的文章中说明。