首先要简单的介绍一下一个东西,叫CSP(Content SEcurity Policy)

现在XSS那么火,相信基友们也都听说过。简单的来说CSP主要是以防止注入型的攻击而开发的,比如说:XSS

虽然江湖传闻CSP是XSS的终结者,但广大基友们的姿势还是很多的。CRLF就是其中的一种姿势了。

作为一种具有可更改HTTP Response header的攻击方式,在这里就可以带给我们绕过CSP的一种可能性。

在这里穿插一点小内容:CRLF和CSP

比如说我们用CRLF的方式插入了一个Content-Security-Policy。这时就存在了两个相同的Content-Security-Policy。而对于这个相同的内容的处理,每个浏览器都是不一样的。有些浏览器会选择位置靠前的,而部分浏览器也会选择位置靠后的。让我们来做一个有趣的实验:

一个简单的CSP规则大概可以使这个样子:

Content-Security-Policy: default-src 'self'

现在假设存在两个页面:

------------------------------------

页面1: :3000/csp

内容为:

:3333/xss.js

------------------------------------

页面二: :3333/xss.js

内容为:

alert('XSS’)

------------------------------------

我们先把情况分为两大类:

第一种情况:http response header会比CSP header快一些

在这里我们在根据浏览器的取舍原则,把情况分成两类:

(1)出现重复的header内容以靠前的为准。

在这个情况下我们可以直接这样的GET请求:

GET :3000/csp?Content-Security-Policy: allow *

而这时的HTTP response可能会是这样:

-------------------------------------------

HTTP/1.1 200 OK

connection:close

X-Content-Security-Policy: allow *

X-Runtime:3

X-Content-Security-Policy: default-src 'self'

Content-Type:text/html

Content-Length:81

--------------------------------------------

pwned!成功地绕过CSP!

(2)出现重复的header内容以靠后的为准。

我们只需要把下面的X-Content-Security-Policy一直往回推推到页面当中就可以了:

我们的请求可以这样的:

GET :3000/csp?lang=jp

<html>

通过下面的内容你可以看出我们可怜的CSP已经被挤到了html页面当中:

---------------------------------------------------------------

HTTP/1.1 200 OK

connection:close

Date:15.01.2013

lang:jap

<html>

Etag:"a25cda3f45v54v45h45g45v34v34v34v334v34v3"

X-content-Security_plicy:default-src 'self'

Content-Type:text/html

Content-Length:81

----------------------------------------------------------------

pwned!成功绕过!

第二种情况:http response header会比CSP header慢一些

(1)出现重复的header内容以靠前的为准。

(2)出现重复的header内容以靠后的为准