得到的效果如下圖：

請注意我們為了示例效果，特意設置了透明度僅僅為 {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) 。