CSP——Content Security Policy

大佬光辉照耀我-学习链接

百度百科：CSP指的是内容安全策略，为了缓解很大一部分潜在的跨站脚本问题，浏览器的扩展程序系统引入了内容安全策略(CSP)的一般概念。这将引入一些相当严格的策略，会使扩展程序在默认情况下更加安全，开发者可以创建并强制应用一些规则，管理网站允许加载的内容。

Content Security Policy 最早在firefox 23中实现，当时使用的是 X-Content-Security-Policy，它使用了前置词的内容安全性策略，并以W3C CSP1.0规范作为标准。

按照我的理解，CSP就是高级白名单机制，并且限制了网站的很多访问行为。

CSP编写网站：https://www.cspisawesome.com/

CSP语法以及范例

header("Content-Security-Policy:

default-src 'none';

connect-src 'self';

frame-src 'self';

script-src xxxx/js/

'sha256-KcMxZjpVxhUhzZiwuZ82bc0vAhYbUJsxyCXODP5ulto='

'sha256-u++5+hMvnsKeoBWohJxxO3U9yHQHZU+2damUA6wnikQ=' ;

font-src xxxx/fonts/ fonts.gstatic.com;

style-src xxxx/css/ fonts.googleapis.com;

img-src 'self'

");

有那么一丢丢长....里面包括了各种各样的写法：

1、none和self，none代表什么都不匹配，self代表匹配同源的来源

2、https://xxx/js/匹配目录下所有文件，https://xxx/js/file.js匹配特殊文件

3、第三种是类似于https:，会匹配所有包含这个特殊的格式的来源。

4、也有可能是example.com这样的，会匹配所有这个host的来源，或者会有*.example.com,会匹配这个host的所有子域。

5、第五种是类似于nonce-qwertyu12345会匹配一个特殊的节点。

6、当然还有加密过的类似于sha256-abcd…同样会匹配页面中一个特殊的节点(每次修改这个值都会改变)。

感觉下面这个是一个比较详细的字段说明

serialized-source-list = ( source-expression *( RWS source-expression ) ) / "'none'"

source-expression = scheme-source / host-source / keyword-source

/ nonce-source / hash-source

; Schemes:

scheme-source = scheme ":"

; scheme is defined in section 3.1 of RFC 3986.

; Hosts: "example.com" / "*.example.com" / "https://*.example.com:12/path/to/file.js"

host-source = [ scheme-part "://" ] host-part [ port-part ] [ path-part ]

scheme-part = scheme

host-part = "*" / [ "*." ] 1*host-char *( "." 1*host-char )

host-char = ALPHA / DIGIT / "-"

port-part = ":" ( 1*DIGIT / "*" )

path-part = path

; path is defined in section 3.3 of RFC 3986.

; Keywords:

keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"

; Nonces: 'nonce-[nonce goes here]'

nonce-source = "'nonce-" base64-value "'"

base64-value = 1*( ALPHA / DIGIT / "+" / "/" / "-" / "_" )*2( "=" )

; Digests: 'sha256-[digest goes here]'

hash-source = "'" hash-algorithm "-" base64-value "'"

hash-algorithm = "sha256" / "sha384" / "sha512"

CSP属性

大佬的文章讲的很好很好，这里不转载赘述啦，总之就是不同属性的对应不同属性请求作用规则。

图片简单说明

不同的配置参数

Bypass CSP

xxxx-src *

这个规则里的*符号表示，允许除了内联函数以外所有的url式的请求，这基本上就随意开火了。

xxxx-src self

一般来说，self代表只接受符合同源策略的url，这样一来，大部分的xss和crsf都会失效，有个标签比较例外，虽然已经被加入的现在的csp草案中，但是的确还没有施行(这里的现在大概是16年，现在可不好说)。

这种请求在firefox上会被拦截(除非同源)，其余的现在不好说

此外，也可以在当前域上传，如果有上传，直接加载就行了，完全么有限制。

攻击范例

不知道有多少人了解过cctf2016，其中有一道web题目IDS-Chicken

题目环境就符合我说的情况，CSP滴水不漏，几乎没办法用任何方式构造xss，但是内网存在上传点，上传文件会被重写为文件，link包含形成xss漏洞。

script-src 'unsafe-inline'

如果加上这个参数，就不会阻止内联脚本，但这被认为是不安全的。

对于这个属性有个特殊的配置叫unsafe-eval，他会允许下面几个函数

eval()

Function()

setTimeout() with an initial argument which is not callable.

setInterval() with an initial argument which is not callable.

我们先尝试构造payload

payload

可以明显的看到被拦了

拦截信息

但是我们尝试构造内联脚本

内联脚本

能看到成功执行

结果

由于同源策略，这个请求不能发往别的域下，但是实战环境中利用方式很多，就比如这个聊天版，可以通过发给别的用户的方式get cookie

var xmlhttp=new XMLHttpRequest();

xmlhttp.open("POST","submit.php",true);

xmlhttp.setRequestHeader(_Ctent-type_,_applicati/x-www-form-urlencoded_);

xmlhttp.send(_to=lorexxar&&message=_+document.cookie);

;

302 Bypass CSP

来源：https://lorexxar.cn/2016/10/31/csp-then2/

首先要意识到如果我们构造一个重定向，就可以bypass CSP的域限制

测试页面(test.php)：

header("Content-Security-Policy: script-src http://127.0.0.1/ http://xss.cc/the_only_allow_dir/");

?>

csp header test

整个站都在/test/下，/test/js/下包含正常的js.

条件一：必须有可以重定向的页面

假设第一个域下的某个位置有个可以定义重定向的页面，比如

这里测试的时候写在了根目录下，不过是要是域内允许的任何为之都可以，这样的功能一般多出现在登陆页面

条件二：我们需要一个被允许的域

比如 http://127.0.0.1/ 里一般会有js目录被允许，然后可能存在upload域可以上传一个js。这里我们允许了http://xss.cc/the_only_allow_dir/这个域，然后在http://xss.cc/myjs/a.js里面写入js内容，比如 alert(2333)这种。

然后访问测试页面(test.php)，就会重定向过去。

其它Bypass方式

CSP困境以及升级