得到的效果如下图：

请注意我们为了示例效果，特意设置了透明度仅仅为 {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 文件，显然会打破同源限制，产生安全隐患。