得到的效果如下圖：

請注意我們?yōu)榱耸纠Ч匾庠O(shè)置了透明度僅僅為 {opacity:0.4;} ，保持頁面上能隱約看到 163 郵箱的內(nèi)容。但如果CSS代碼設(shè)置為 {opacity:0;} ，163 郵箱的內(nèi)容就會消弭于眼前，只留下這張促銷圖片。但訪問者點(diǎn)到相應(yīng)位置時，依然會觸發(fā)對163郵箱的請求。這個就是點(diǎn)擊劫持的原理。

早期 WEB 開發(fā)者應(yīng)對這個問題的處理，是用 JavaScript 實(shí)現(xiàn)的，一般是判斷當(dāng)前 window 對象和 parent 對象是否一致，如果不一致，就執(zhí)行“破框”跳轉(zhuǎn)。但這個方式并不可靠！因?yàn)楦鞣N原因，客戶端有可能禁止了 JavaScript 執(zhí)行或代碼被繞過，這樣“破框”代碼就失效了。在人們?nèi)找嬲J(rèn)識到這種攻擊方式的危害性后，為統(tǒng)一解決這個問題，制定互聯(lián)網(wǎng)規(guī)范的機(jī)構(gòu)出手了，解決方案就是：

RFC7034

「 HTTP Header Field X-Frame-Options 」

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

即引入了一個新的 HTTP 響應(yīng)頭。現(xiàn)在主流常用瀏覽器已全部支持這一響應(yīng)頭。具有這個響應(yīng)頭的資源，可以拒絕自己被非法站點(diǎn)的以下標(biāo)簽引用：

iFrame 標(biāo)簽

Frame 標(biāo)簽

Object 標(biāo)簽

Applet 標(biāo)簽

Embed 標(biāo)簽

這個頭有三種選項(xiàng)，對應(yīng)如下：

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

這個響應(yīng)頭的 弊端 ：

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

對確實(shí)需要嵌入很多第三方資源的復(fù)雜頁面不適用。

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

WEB 服務(wù)器返回的資源包括各種，如圖片、HTML 頁面、JavaScript 腳本、CSS 腳本、純文本、二進(jìn)制文件等。瀏覽器對資源的解讀和渲染呈現(xiàn)方式，滲透攻擊時有可能被利用。比如一個允許交互的站點(diǎn)，往往允許上傳圖片、mp3 文件，甚至允許上傳純文本文件，但往往不允許上傳 JavaScript 腳本文件和 HTML 文件，因?yàn)楹笳呓柚?JavaScript 日益強(qiáng)大的功能，能做的壞事實(shí)在有點(diǎn)多。

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

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

如以下例子：

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 內(nèi)容，最后以 HTML 方式被渲染呈現(xiàn)出來，盡管服務(wù)器端已經(jīng)指定 Content-Type:text/plain; —— 這會導(dǎo)致一定的安全隱患。因?yàn)楹芏嘤薪换スδ艿姆?wù)器，都會允許上傳某些類型的“無害”文件，如圖片和 mp3 等，如果在上傳的圖片內(nèi)，巧妙地嵌入一定的 HTML 和 JavaScript 代碼，最后能被渲染為 HTML 文件，顯然會打破同源限制，產(chǎn)生安全隱患。

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

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

這個響應(yīng)頭的 弊端 ：

某些早期瀏覽器不支持。

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

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

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

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

為解決這個問題，標(biāo)準(zhǔn)制定機(jī)構(gòu)2012 年又發(fā)布了一份：

RFC 6797

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

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