WEB安全防護相關響應頭(下)
前篇“WEB安全防護相關響應頭(上)”中,我們分享了 X-Frame-Options、X-Content-Type-Options、HTTP Strict Transport Security (HSTS) 等安全響應頭的內容。下文中,我們則側重介紹一些和跨站安全相關的響應頭——

一、Referrer-Policy – 不要問我從哪里來
“互聯網”這個詞,顧名思義,“互聯”才有意義。我們看到的一個常規頁面,往往是先加載父級頁面,父級頁面再加載其他的子資源(如圖片、JS 文件和各種多媒體文件等);主頁面上通常還有各種鏈接,點擊會跳轉到其他內容;另外,通過
▲圖1 一些做得好的
在 HTTP 協議里,如果【A資源】發起了對【B資源】的互聯請求,表明該請求來自【A資源】的信息會體現在【B資源】的「referer」請求頭里。【B資源】就能明確知道發起方是【A資源】。只要是引用關系或者互聯關系的請求,瀏覽器都會自動附加這個「referer」請求頭,以標明發起端是誰。
這個請求頭的本意,是讓網站管理者更容易得知 HTTP 訪問的來源。但人們逐漸認識到這個請求頭有可能暴露使用者的隱私。譬如【A資源】當前的 URL 里,如果包含了比較敏感的用戶名、權限和會話等信息;只要捕獲【B資源】的「referer」請求頭,就有可能獲得用戶在【A資源】里的敏感信息。
出于對保護隱私的考慮,Firefox 和 Chrome 等瀏覽器引入了一套更精確控制瀏覽器如何發送「referer」請求頭的機制,名叫「Referrer-Policy」。支持這套機制的瀏覽器,會根據具體情況決定是否發送「referer」請求頭。但值得注意的是:微軟系列的瀏覽器IE和Edge都不支持這個機制。
使用以下幾種方式,可以加載和設定不同的「Referrer-Policy」策略:
方法一:
從 WEB 服務器端,整體地返回 Referrer-Policy 響應頭:
#Nginx配置: add_header Referrer-Policy "no-referrer" always; #Apache配置: Header always set Referrer-Policy "same-origin"
方法二:
對整個頁面添加一個名為"referrer"的新 meta 值,類似:
方法三:
給頁面內某個標簽,如下例中的 鏈接標簽和 圖片加載標簽,增加一個 referrerpolicy 屬性:
可以看出,以上三種方式的生效范圍各有差異,分別對應整站起效、特定頁面起效及設置特定標簽起效,可以根據具體情況使用。
這個策略可以配置為以下值,含義分別為:
no-referrer
任何情況下,瀏覽器都不發送 HTTP referer 請求頭;
no-referrer-when-downgrade
如果瀏覽器從 HTTPS 類型的 URL 跳轉到 HTTP 類型的 URL,瀏覽器就不需要發送 referer 請求頭;
same-origin
只有發起端和目標端是同源時,瀏覽器才發送 referer 請求頭。域名和協議完全相同,兩個站點才是同源站點;
origin
瀏覽器會發送 referer 請求頭,但 referer 請求頭里只有發起方的域名信息,沒有完整的 URL 路徑。如發起端 URL 為 https://example.com/page.html,實際發送的 referer 請求頭里只有 https://example.com/;
strict-origin
和 origin 含義相似,且只有同等安全級別的協議才發送 referer 請求頭,如從 HTTPS→HTTPS 會發送,而從 HTTPS→HTTP 則不發送;
origin-when-cross-origin
對同源的其他資源,發送包含完整 URL 的 referer 請求頭;如果是非同源的資源,則 referer 請求頭里只有域名信息,沒有完整 URL;
strict-origin-when-cross-origin
和上一條類似,但協議的安全等級降低時就不發送 referer 請求頭了;
unsafe-url
無論是否同源,都發送完整 URL 的 referer 請求頭。
舉例:在我們的測試頁面 http://www.sandbox.com/index.html 里,包含外站圖片 http://img.tcxa.com.cn/logo.png 。默認在沒有其他設置的情況下,發往該圖片的請求如下圖,其中的 Referer 請求頭里清晰地包含了父級頁面的地址:http://www.sandbox.com/index.html
▲圖2 正常狀態下圖片訪問帶referer請求頭
如果 www.sandbox.com 服務器的 Nginx 配置內,加入 add_headerReferrer-Policy"same-origin"always; ,設定只有同源站點才發送 Referer 請求頭。這時候,訪問 http://www.sandbox.com/index.html 獲得的響應頭里,就增加了一行 Referrer-Policy:same-origin 的響應頭,如下:
▲圖3 父資源的Referrer-Policy設置為same-origin同源
這時候,由于和發起端 www.sandbox.com 的域名并不同源,如下圖所示,可以看出,發往 http://img.tcxa.com.cn/logo.png 圖片的請求此時已不再出現 Referer 請求頭了:
▲圖4 子資源的請求里不再包含Referer請求頭
二、X-XSS-Protection – 跨站邊界保護
XSS 的全稱是 Cross Site Scripting,中文叫“跨站腳本攻擊”。其中“腳本”一詞,主要指 javaScript 腳本。javaScript 腳本在多年的進化中,使用越來越靈活,功能越來越強大,這也導致人們原本不太在意的瀏覽器客戶端安全,變得越來越重要了。
現在的 JavaScript 腳本,不但可以訪問和操控頁面上的 DOM 元素,還可以和服務器端進行交互,故而它帶來的安全隱患也不容忽視。為了“緩解”這一問題,瀏覽器廠商們做了一定的努力,其中一種機制就是 X-XSS-Protection 響應頭。支持這一響應頭的瀏覽器,在檢測到跨站腳本攻擊 (XSS)時,可以主動停止加載頁面。
這個響應頭有以下四種值:
X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report=
這四個值的含義分別為:
0 :禁用對頁面的 XSS 過濾功能;
1 :啟用對頁面的 XSS 過濾功能,這也是瀏覽器默認的處理(不需要做任何配置,就是這個選項)。如果發現有 XSS 風險的代碼,瀏覽器就自動清理頁面,去除這部分有危害的代碼;
1;mode=block :啟用對頁面的 XSS 過濾功能,但在發現 XSS 風險時,會直接屏蔽整個頁面的展示,而不是只去除有風險部分;
1;report=
我們用 DVWA 的跨站演示頁面,來分別展示一下,響應頭設置為上述幾個不同值時,對應的不同效果。
以下三次測試,都是提交了完全一樣的請求:
http://dvwa站點IP/vulnerabilities/xss_r/?name=
測試一
設置 X-XSS-Protection:0。
在 X-XSS-Protection:0 時,瀏覽器直接執行了有問題的網頁端代碼,所以,提交的內容里的 JavaScript 代碼能成功執行,在瀏覽器里看到了彈窗效果,彈窗內容為瀏覽器訪問當前網站的 Cookie 值,參見圖5。這種設置僅適用于安全滲透測試練手,以及希望準確評估網站安全風險代碼時使用。
▲圖5 JavaScript代碼執行成功,看到彈窗
測試二
設置 X-XSS-Protection:1。
這是默認設置。也就是說,如果服務器端完全沒有返回過 X-XSS-Protection 響應頭,瀏覽器就認為服務器端返回的是 X-XSS-Protection:1 。這時候,瀏覽器會根據自己的內部過濾原則,直接無視它認為有問題的那部分代碼,自動跳過這部分代碼(這部分內容根本不會發給服務器端),最終我們看到的是“清理”后的效果:
▲圖6 JavaScript代碼沒有執行成功,沒有彈窗
測試三
設置 X-XSS-Protection:1;mode=block。
這是最嚴厲的設置。這時候,瀏覽器會根據自己的內部過濾原則,發現有問題代碼,直接就拒絕顯示該頁面,這次提交也不會被發往服務器端,效果如圖:
▲圖7 整個頁面都無法顯示了
以上三種設置,可以根據具體的需求做選擇。
如果需要在服務器端設置這個響應頭,可以在合適的范圍內,加入以下指令:
#Nginx配置: add_header X-XSS-Protection "1; mode=block" always; #Apache配置: Header always set X-XSS-Protection "1; mode=block"
那么,是不是我們只要給服務器設置好這個響應頭,就能徹底解決跨站腳本攻擊的問題呢?答案有點令人喪氣:并不一定!這個機制的定位僅僅是“緩解”跨站腳本攻擊,它不是一顆銀子彈,無法就此高枕無憂了。一方面,跨站腳本攻擊有非常多的變型手法和實現,業界公認沒法完全通過黑名單規則來徹底過濾跨站——要徹底防護跨站腳本攻擊,就幾乎需要抵觸互聯網的“互聯”本質。所以,X-XSS-Protection 的機制,也只是對跨站腳本攻擊的部分防護。
要對客戶端進行更細粒度更有效的安全防護,目前更建議使用的機制是 CSP (Content Security Policy)。這個又需要一篇獨立的文檔來介紹了,敬請期待。
(朱筱丹 | 天存信息)
Ref
‘Referrer Policy’ - Editor’s Draft, 20 April 2017
‘Referrer-Policy’ - developer.mozilla
‘X-XSS-Protection’ - developer.mozilla
The Misunderstood X-XSS-Protection
HTML HTTP web前端 運維 通用安全
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。