使用Referer Meta標籤控制referer

轉載：來自FreeBuf黑客與極客（FreeBuf.COM）

本文描述了一個關於 http 協議中 referer 的 metadata 參數的提議，使用這個 metadata 參數，html 文檔能夠控制 http 請求中的 referer ，好比是否發送 referer、只發送 hostname 仍是發送完整的 referer 等。雖然有一些方法能夠控制 referer ，好比 flash，以及一些 js 的 tricks，可是本文中描述的是另一番景象。

使用場景

在某些狀況下，出於一些緣由，網站想要控制頁面發送給 server 的 referer 信息的狀況下，可使用這一 referer metadata 參數。

隱私

社交網站通常都會有用戶我的頁面，這些頁面中用戶都有可能添加一些外網的連接，而社交網站有可能不但願在用戶點擊了這些連接的時候，泄露用戶頁面的 URL ，由於這些 URL 中可能包含一些敏感信息。固然，有些社交網站可能只想在 referer 中提供一個 hostname，而不是完整的 URL 信息。

安全

有些使用了 https 的網站，可能在 URL 中使用一個參數(sid 等)來做爲用戶身份憑證，而又須要引入其餘 https 網站的資源，這種狀況下，網站確定不但願泄露用戶的身份憑證信息。

Object-Capability Discipline

有些網站遵循Object-Capability Discipline，而 referer 恰好與這一策略相悖，因此，網站可以控制 refeer 將對 Object-Capability Discipline 頗有利。

技術細節

referer 的 metedata 參數能夠設置爲如下幾種類型的值：

• never
• always
• origin
• default

若是在文檔中插入 meta 標籤，而且 name 屬性的值爲 referer，瀏覽器客戶端將按照以下步驟處理這個標籤：

• 1.若是 meta 標籤中沒有 content 屬性，則終止下面全部操做
• 2.將 content 的值複製給 referrer-policy ，並轉換爲小寫
• 3.檢查 content 的值是否爲上面 list 中的一個，若是不是，則將值置爲 default

上述步驟以後，瀏覽器後續發起 http 請求的時候，會按照 content 的值，作出以下反應(下面 referer-policy 的值即 meta 標籤中 content 的值)：

• 1.若是 referer-policy 的值爲never：刪除 http head 中的 referer；
• 2.若是 referer-policy 的值爲default：若是當前頁面使用的是 https 協議，而正要加載的資源使用的是普通的 http 協議，則將 http header 中的 referer 置爲空；
• 3.若是 referer-policy 的值爲 origin：只發送 origin 部分；
• 4.若是 referer-policy 的值爲 always：不改變http header 中的 referer 的值，注意：這種狀況下，若是當前頁面使用了 https 協議，而要加載的資源使用的是 http 協議，加載資源的請求頭中也會攜帶 referer。 例子

若是頁面中包含了以下 meta 標籤，全部從當前頁面中發起的請求將不會攜帶 referer：

<meta name="referrer" content="never">

若是頁面中包含了以下 meta 標籤，則從當前頁面中發起的 http請求將只攜帶 origin 部分（注：根據原文中的語境，我理解這裏的 origin 是包含了 schema 和 hostname 的部分 url，不包含 path 等後面的其餘 url 部分），而不是完整的 URL ：

<meta name="referrer" content="origin">

注意：在使用本文中所述的 meta 標籤的時候，瀏覽器原有的 referer 策略將被打破，好比從 http 協議的頁面跳轉到 https 的頁面的時候，若是設置了適當的值，也會攜帶 referer。

其餘問題

這與 rel=noreferer 有什麼關係呢？可能 rel=noreferer 會覆蓋掉本文中的 meta 標籤所設置的值。也就是功能覆蓋。 origin 信息不是一個完整的 url，因此瀏覽器客戶端估計會在 origin 後面加一個 / 來做爲 path 部分。 若是 origin 是惟一的，會發生什麼狀況呢？估計 referer 會被忽略。

譯者注

這篇文章最初寫於2012年，目前在原始頁面已是廢棄狀態，而且已經提供了w3c 的referer-policy 頁面，可是，譯者注意到，目前不少網站在防護 CSRF 的時候，都採用校驗 referer 的方法，有時候容許 referer 爲空，而且某些 BAT 廠商的重要業務在防護 JSON 劫持的時候，也採用校驗 referer 的方法並容許 referer 爲空，也許你會以爲本文中描述的只是一種提議，可是，FireFox 在21日的一篇文章中已經聲明，從 Firefox 36 Beta 開始，將會支持 referer-policy，這無疑會讓一些廠商的業務面臨威脅。

[參考來源wiki.whatwg.org，轉載請註明來自FreeBuf黑客與極客（FreeBuf.COM）]