WEB安全防護相關響應頭（上）

WEB 安全攻防是個龐大的話題，有各種不同角度的探討和實踐。即使只討論防護的對象，也有諸多不同的方向，包括但不限于：WEB 服務器、數據庫、業務邏輯、敏感數據等等。除了這些我們慣常關注的方面，WEB 安全還有一個重要的元素——網站的使用者。

他們通常是完全沒有 IT 知識的普通用戶，網站方可以做點什么，以增加對這些普通用戶的保護呢？以前較被忽略的步驟是：正確設置頁面的響應頭 (Response Headers) 。這類加入安全相關響應頭的做法，往往是為了保護客戶端／使用者的安全，減少使用者落入黑客的 WEB 陷阱的可能。

這里我們介紹一些較為常用的，和安全相關的響應頭。當然，WEB 應用應該根據自己的實際情況部署和設置，并非盲目地一股腦地全部招呼上。

一、X-Frame-Options – 打破框框

從 2008 年開始，研發人員發現一種利用視覺誤導，引誘使用者行為的可能，這種做法后來被命名為點擊劫持 (Click Jacking) 。

攻擊者的通常做法是，在自己的頁面里通過框架（iframe）的形式，包含一個不屬于它本站的頁面。下面的示例代碼里包含的就是 【163 郵箱】的設置頁。而由黑客控制的父級頁面本身可以是任何內容，它通過精確調整自己頁面的內容和 iframe 的坐標及大小，再通過 CSS 的 opacity 透明度設置，把用戶內容所在的 iframe 透明度設置為全透明。

以下為示例代碼：

得到的效果如下圖：

請注意我們為了示例效果，特意設置了透明度僅僅為 {opacity:0.4;} ，保持頁面上能隱約看到 163 郵箱的內容。但如果CSS代碼設置為 {opacity:0;} ，163 郵箱的內容就會消弭于眼前，只留下這張促銷圖片。但訪問者點到相應位置時，依然會觸發對163郵箱的請求。這個就是點擊劫持的原理。

早期 WEB 開發者應對這個問題的處理，是用 JavaScript 實現的，一般是判斷當前 window 對象和 parent 對象是否一致，如果不一致，就執行“破框”跳轉。但這個方式并不可靠！因為各種原因，客戶端有可能禁止了 JavaScript 執行或代碼被繞過，這樣“破框”代碼就失效了。在人們日益認識到這種攻擊方式的危害性后，為統一解決這個問題，制定互聯網規范的機構出手了，解決方案就是：

RFC7034

「 HTTP Header Field X-Frame-Options 」

https://tools.ietf.org/html/rfc7034

即引入了一個新的 HTTP 響應頭。現在主流常用瀏覽器已全部支持這一響應頭。具有這個響應頭的資源，可以拒絕自己被非法站點的以下標簽引用：

iFrame 標簽

Frame 標簽

Object 標簽

Applet 標簽

Embed 標簽

這個頭有三種選項，對應如下：

所以顯然，上面 163 郵箱的頁面，就沒有返回這個響應頭，存在一定的劫持風險。如果加入這個響應頭，我們的模擬頁面，將無法像上圖那樣直接把 163 郵箱的內容嵌進來。

這個響應頭的 弊端 ：

某些早期瀏覽器可能不支持；

對確實需要嵌入很多第三方資源的復雜頁面不適用。

二、X-Content-Type-Options – IE你別瞎猜猜了

WEB 服務器返回的資源包括各種，如圖片、HTML 頁面、JavaScript 腳本、CSS 腳本、純文本、二進制文件等。瀏覽器對資源的解讀和渲染呈現方式，滲透攻擊時有可能被利用。比如一個允許交互的站點，往往允許上傳圖片、mp3 文件，甚至允許上傳純文本文件，但往往不允許上傳 JavaScript 腳本文件和 HTML 文件，因為后者借助 JavaScript 日益強大的功能，能做的壞事實在有點多。

如無意外，服務器端返回的每個資源的響應頭里，一般都帶有 content-type 這個響應頭：

HTTP/1.1 200 OK Content-Length: 3587 Content-Type: image/png Date: Wed, 20 Mar 2019 09:40:16 GMT Last-Modified: Tue, 19 Mar 2019 20:01:14 GMT Server: Microsoft-IIS/7.5

返回的這個 Content-Type 頭，一般是自動的，如服務器會根據 URL 后綴對應的文件類型自動選擇；如不是自動的，則可能是程序員在代碼層設定的，兩種情況均有可能。這個響應頭在較為罕見的情況下，也可能缺失，也可能和實際情況不匹配。而比較早期的瀏覽器，尤其是 IE，會出于“好心”，不但在沒有 Content-Type 頭的時候會主動檢測響應的內容，甚至在已有 Content-Type 頭的時候，也會根據返回的數據體內容，判斷里面有沒有 HTML 代碼特征，如果有，返回的內容會直接被認定為 HTML 類型，而不顧實際的 Content-Type 頭的類型設定。

如以下例子：

HTTP/1.1 200 OK Content-Length: 108 Date: Thu, 26 Jun 2008 22:06:28 GMT Content-Type: text/plain; This page renders as HTML source code (text) in IE8.

就會被早期一些的 IE 判定為 HTML 內容，最后以 HTML 方式被渲染呈現出來，盡管服務器端已經指定 Content-Type:text/plain; —— 這會導致一定的安全隱患。因為很多有交互功能的服務器，都會允許上傳某些類型的“無害”文件，如圖片和 mp3 等，如果在上傳的圖片內，巧妙地嵌入一定的 HTML 和 JavaScript 代碼，最后能被渲染為 HTML 文件，顯然會打破同源限制，產生安全隱患。

所以從 IE8 某個版本開始引入了 X-Content-Type-Options 這個新的響應頭，如果這個響應頭的值為 nosniff ，中文直譯即「別嗅探」，就是告訴瀏覽器端，不要再主動猜測文檔的類型了，以服務器端返回為準。后來 Chrome 等瀏覽器也支持這個響應頭。

HTTP/1.1 200 OK Content-Length: 108 Date: Thu, 26 Jun 2008 22:06:28 GMT Content-Type: text/plain; X-Content-Type-Options: nosniff

這個響應頭的 弊端 ：

某些早期瀏覽器不支持。

三、HTTP Strict Transport Security (HSTS) – 不加密不舒服斯基

隨著 WEB 傳遞的敏感信息越來越多，加密傳輸 HTTPS 也逐漸超越常規 HTTP，正越來越成為互聯網上各大站點的首選傳輸協議。甚至像谷歌公司，從 2018 年中推出的 Chrome 68 版開始，就對所有 HTTP 訪問提示安全警告了。以下引用自谷歌公司的聲明：

過去幾年中，我們一直主張站點采用 HTTPS，以提升其安全性。去年的時候，我們還通過將更大的 HTTP 頁面標記為‘不安全’以幫助用戶。

但通常使用者在瀏覽器里輸入域名時，都是不帶協議部分的，比如直接輸入 www.tcxa.com.cn ，由瀏覽器補齊前面缺失的協議部分，變成完整的 URL: http://www.tcxa.com.cn 。瀏覽器默認加入的協議，總是 HTTP 的！對那些同時提供 HTTP 和 HTTPS 服務，但希望訪問者優先使用 HTTPS 服務的站點來說，這種處理就不太符合他們的本意了。

為解決這個問題，標準制定機構2012 年又發布了一份：

RFC 6797

https://tools.ietf.org/html/rfc6797

這套機制就是 HTTP 嚴格傳輸安全響應頭 (HTTP Strict Transport Security，簡稱 HSTS) 。

這個響應頭里，最重要的一個參數項叫 max-age （單位為秒）。這個參數指的是，如果你上一次用 HTTPS 訪問過該站點，下次再來訪問，如果兩次訪問的間隔時間沒有超過這個 max-age 的設定，第二次訪問該站點時，瀏覽器就會直接強制以 HTTPS 協議訪問了。這背后的邏輯是，第一次訪問站點的時候，有針對性的攻擊應該還不會發生。重點是防護后續的訪問，所以后續的訪問需要被強制升級為 HTTPS 協議。這個響應頭需要在 HTTPS 流量里才有效，在 HTTP 流量里返回這個頭并沒有作用。

以下是站點 https://www.github.com 返回的部分響應頭摘錄——順便一提，前面介紹的 X-Frame-Options 和 X-Content-Type-Options 響應頭也都出現在 github 里：

HTTP/1.1 200 OK Cache-Control: max-age=0, private, must-revalidate Content-Encoding: gzip Server: GitHub.com Strict-Transport-Security: max-age=31536000; includeSubdomains; preload Expect-CT: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors" Transfer-Encoding: chunked ...... Vary: Accept-Encoding X-Content-Type-Options: nosniff X-Frame-Options: deny ......

其中 Strict-Transport-Security 響應頭里， max-age 的值很大，這個 31536000 秒，其實等于 365 天，也就是一整年的時間。意思是除非前后兩次訪問 github 的時間超過一年，否則每次訪問 github，都會被強制使用 HTTPS。 includeSubdomains 選項代表這個策略涵蓋 github 所有的子域名。

還可以手工強制 HSTS。方式是在 Chrome 瀏覽器地址欄內，輸入

chrome://net-internals/#hsts，

來到如下圖的配置界面：

在「Add HSTS domain」里，手工加入需要強制使用 HTTPS 的域名。在「Query HSTS/PKP domain」里，則可以查詢某個域名對這個響應頭的設置。

這個響應頭的 弊端 ：

某些早期瀏覽器不支持；

如果 HTTPS 站點出現問題，導致無法訪問， max-age 又設得過大，會導致使用者完全無法回退到訪問 HTTP 站點。

四、瀏覽器兼容性

這些響應頭基本上都是在客戶端腳本越來越強大的 Web 2.0 時代之后才出現的，每種瀏覽器對它們的支持也各異，情況非常復雜混亂。所以使用前也需要評估目標人群的瀏覽器使用場景。

各種瀏覽器對這些響應頭的兼容性，可以查詢以下站點：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

如我們本篇提到的第一個響應頭 X-Frame-Options 的兼容性情況如下：

可以看到瀏覽器分電腦和手機版，電腦版里列出了從哪個版本的瀏覽器開始支持這個響應頭，而且幾個不同的選項值也略有差異。

五、這些響應頭打哪兒來的？！

上面的一切看起來都很美好啦，但問題是：這些響應頭難道是憑空出現的嗎？ 要怎么得到它們呢？一般的 WEB 服務器自身都支持響應頭自定義設置。同時，各種 WEB 開發代碼也可以通過編程的方式，實現更靈活的響應頭返回和設置。WEB 開發代碼較為復雜，無法囊括，我們大致介紹一下各種 WEB 服務器對這個功能的支持。

1. APACHE

例如，可以在Apache配置文件 httpd.conf 中添加以下配置，限制只有同源頁面才可以嵌入iframe：

Headeralways append X-Frame-OptionsSAMEORIGIN

重啟 apache 使其生效。其他的響應頭也同理。關于Apache Header 指令的詳細用法：

http://httpd.apache.org/docs/current/mod/mod_headers.html#header

2. NGINX

例如，可以在 Nginx 配置文件 nginx.conf 中的「server」上下文內，添加以下配置，限制只有同源頁面才可以嵌入 iframe：

add_header X-Frame-Options"SAMEORIGIN";

重啟 Nginx 服務使其生效。其他的響應頭也類似同理。關于Nginx add_header 指令的詳細用法：

http://nginx.org/en/docs/http/ngxhttpheaders_module.html

3. IIS

在 WEB 站點對應的 web.config 中添加配置：

** ...

如果不習慣改配置文件，可以使用圖形控制臺，如下選擇網站對應的「HTTP 響應標頭」：

再根據實際需求，添加所需的響應頭即可：

（朱筱丹 | 天存信息）

Ref

M Zalewski - 《Web之困：現代Web應用安全指南》

List of HTTP header fields

ie8 security part vi beta 2 update

fetch Living Standard

HTTP Strict Transport Security

Referrer Policy 介紹

HTML HTTP web前端 運維 通用安全

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。