1.背景
1.1.同源策略
網(wǎng)站的安全模式源于“同源策略”，web瀏覽器允許第一個web頁面中的腳本訪問頁面中的數(shù)據(jù)，但前提是兩個web頁面具有相同的源。此策略防止一個頁面的惡意腳本通過該頁面的文檔訪問另一個網(wǎng)頁上的敏感數(shù)據(jù)。
規(guī)則：協(xié)議、主機、和端口號
安全風(fēng)險例子：
1,假設(shè)你正在訪問銀行網(wǎng)站但未注銷
2,這時候你跳轉(zhuǎn)到另外一個站點
3,該站點注入一些惡意代碼(比如：進行交易操作等)
1.2.網(wǎng)頁安全漏洞----跨網(wǎng)站腳本XSS
在某些情況下，同源策略的限制性如果太強，其實是不太友好的，比如說大型網(wǎng)站的子域之間的數(shù)據(jù)傳遞，開發(fā)過程中的一些調(diào)試等；但是人類是比較聰明的，利用一些技術(shù)、從而放寬策略
但是，跨網(wǎng)站腳本 (XSS)攻擊可通過欺騙網(wǎng)站提供惡意代碼和計劃好的內(nèi)容來繞過同源政策：通過尋找將惡意腳本注入網(wǎng)頁，攻擊者可以獲得對敏感頁面內(nèi)容，會話cookie以及瀏覽器代表用戶維護的各種其他信息的提升訪問權(quán)限。
1,盜號
2,強制發(fā)送郵件...
2.CSP內(nèi)容安全策略
為了緩解很大一部分潛在的跨腳本問題，瀏覽器的擴展程序系統(tǒng)引入了內(nèi)容安全策略（CSP）的一般概念；簡單來說這一技術(shù)就是：
開發(fā)者明確告訴客戶端（制定比較嚴格的策略和規(guī)則），哪些外部資源是可以加載和執(zhí)行的 ，即使攻擊者發(fā)現(xiàn)漏洞，但是它是沒辦法注入腳本的
開發(fā)人員可以使用這種工具以各種方式鎖定其應(yīng)用程序，降低內(nèi)容注入漏洞（如跨站點腳本）的風(fēng)險，并降低其應(yīng)用程序執(zhí)行的權(quán)限
3.怎么啟用CSP？
可以通過兩種方式：
1,一種是通過 HTTP 頭信息的Content-Security-Policy的字段
2,通過網(wǎng)頁的<meta>標簽
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
我們在頁面引入一個cdn，但是meta的content只設(shè)置為script-src 'self'
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<meta http-equiv="Content-Security-Policy" content="script-src 'self'"/>
<title>Document</title>
<script src="https://cdn.bootcss.com/jquery/3.3.1/jquery.min.js"></script>
</head>
那么，我們將會看到如下結(jié)果
4 常見配置
該策略允許加載同源的圖片、腳本、AJAX和CSS資源，并阻止加載其他任何資源，對于大多數(shù)網(wǎng)站是一個不錯的配置。
default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’;
CSP的意義
防XSS等攻擊的利器。CSP 的實質(zhì)就是白名單制度，開發(fā)者明確告訴客戶端，哪些外部資源可以加載和執(zhí)行，等同于提供白名單。它的實現(xiàn)和執(zhí)行全部由瀏覽器完成，開發(fā)者只需提供配置。CSP 大大增強了網(wǎng)頁的安全性。攻擊者即使發(fā)現(xiàn)了漏洞，也沒法注入腳本，除非還控制了一臺列入了白名單的可信主機。
CSP的分類
（1）Content-Security-Policy
配置好并啟用后，不符合 CSP 的外部資源就會被阻止加載。
（2）Content-Security-Policy-Report-Only
表示不執(zhí)行限制選項，只是記錄違反限制的行為。它必須與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 定義同時存在，則優(yōu)先采用 HTTP 中的定義。
如果用戶瀏覽器已經(jīng)為當(dāng)前文檔執(zhí)行了一個 CSP 的策略，則會跳過 Meta 的定義。如果 META 標簽缺少 content 屬性也同樣會跳過。
策略應(yīng)該怎么寫
（1）舉個例子
// 限制所有的外部資源，都只能從當(dāng)前域名加載
Content-Security-Policy: default-src 'self'
// default-src 是 CSP 指令，多個指令之間用英文分號分割；多個指令值用英文空格分割
Content-Security-Policy: default-src https://host1.com https://host2.com; frame-src 'none'; object-src 'none'
// 錯誤寫法，第二個指令將會被忽略
Content-Security-Policy: script-src https://host1.com; script-src https://host2.com
// 正確寫法如下
Content-Security-Policy: script-src https://host1.com https://host2.com
// 通過report-uri指令指示瀏覽器發(fā)送JSON格式的攔截報告到某個地址
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
// 報告看起來會像下面這樣
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
}
}
（2）常用的CSP指令
（3）其他的CSP指令
（4）CSP指令值
支持問題
（1）CSP1兼容性
瀏覽器可以很好地支持 CSP 1，全球高達94.66%，中國達到79.55%（截至2018年4月12日）。
（2）CSP2兼容性
CSP 2還很新，支持相對少點，全球達81.11%，中國達到60.04%（截至2018年4月12日）。
