文章目录
前言
点击劫持
恶意转账
刷点击量
防护手段
HTTP响应头
实际防护效果
漏洞的检测
HTTP标题
X-XSS-Protection
前言
在一些漏扫设备中经常会扫出一个低风险问题——“点击劫持：X-Frame-Options 未配置”，如下为绿盟科技 RSAS 扫描器的漏扫报告：
APPScan 也会扫出该漏洞：
本文将对该漏洞的危害、利用方式和防护手段进行介绍。
点击劫持
Clickjacking（点击劫持）是由互联网安全专家罗伯特·汉森和耶利米·格劳斯曼在2008年提出的。它是一种视觉欺骗手段，在 Web 端就是 iframe 嵌套一个透明不可见的页面，让用户在不知情的情况下，点击攻击者想要欺骗用户点击的位置。
点击劫持大概有两种利用方式，一是攻击者使用一个透明的 iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的 iframe 页面，从而达到攻击者的某种目的，比如： 刷点击量，骗取关注等；二是攻击者使用一张图片覆盖在网页，遮挡网页原有位置的含义。本文主要讲第一种方式。
恶意转账
假设你访问一个 Web 站点并看到如下的页面：
免费的午餐谁都喜欢，当你满怀期待的点击按钮“WIN”的时候，恭喜你，你已经被点击劫持了。你实际点击的链接如下：
这是登录网上银行之后的一个转账链接，转移你的全部资产给 Kim Dotcom 先生。但是你根本你没有看到这个页面，像做梦一样。这只是一个简单的示例，实现上在网上银行转账不会这么简单，但是却告诉我们一个道理，访问网页和看魔术表演一样，看到的不一定都是真的。
点击劫持的表象一般是用户点击了页面的A元素，但是实际上接收点击事件的却是另外一个元素。现在改变下页面内个元素的透明度，再来看下刚才的页面。
我们可以看到，在 ipad 页面是上部还有个层，实际上是一个 iframe，现在的透明度为 50%，实际的页面中它的透明度为 0%，虽然被隐藏不可见，但是随时都可以被激活。在 Firefox的 3D 视图下，观察这个页面更明显。
被隐藏的 iframe 在 IPAD 页面的上部，同时转款的链接正好在 “WIN” 的上方，因为设置了透明度，用户只能看到 “WIN”，但实际点击的是转款。攻击者的页面内容可能是这样的：
1
2
3
4
5
6
代码就是这么简单，下面我们观察一下点击 “WIN” 时实际上点击“转款”链接时的 http 请求信息。
从图中标记的地方，可以看到请求的实际地址和身份验证的 cookie 信息。当然这样的攻击能成功，在于用户已经登录的网上银行。这样的攻击行为和跨站请求伪造很类似。
刷点击量
假如我在 B 站发布了很多视频，想让更多的人关注它或者点击它，于是我们准备了一个 HTML 页面：
<!DOCTYPE html>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
流量器打开页面如下：
当你满心欢喜地点击按钮“美女微信”，却发现页面内跳转到如下视频：
调整下网页的 opacity 的值（在 CSS 中 opacity 代表透明度数，选值0-100，0是完全透明，100是不透明）：
可以看到真实的 frame 是覆盖在图片之上的：
同理，可以利用点击劫持，骗取用户关注你的账户、转发你的视频等。
防护手段
X-Frame-Options HTTP 响应头，可以指示浏览器是否应该加载一个iframe中的页面。网站可以通过设置 X-Frame-Options 阻止站点内的页面被其他页面嵌入从而防止点击劫持。
HTTP响应头
X-Frame-Options 共有三个值：
DENY：表示任何页面都不能被嵌入到 iframe 或者 frame 中；
SAMEORIGIN：表示页面只能被本站页面嵌入到 iframe 或者 frame中；
ALLOW-FROM uri：页面自能被指定的 Uri 嵌入到 iframe 或 frame 中。
换一句话说，如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载；另一方面，如果设置为 SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。常见的服务器配置如下：
比如如果我们使用 phpstudy 搭建的环境，我们可以 其他选项菜单—> php扩展及设置—>Apache模块，勾选 headers_module 模块，然后在Apache的配置文件 httpd.conf 中的空白行加入 Header always append X-Frame-Options SAMEORIGIN 即可！
加之前：
加之后：
实际防护效果
接下来我们来实践一下，看下 X-Frame-Options 是否会起作用。
一个非常简单的页面，里面用 iframe 标签嵌入了一张页面：
<!DOCTYPE html>
1
2
3
4
5
6
7
8
9
10
11
看下 index.html 的结构，也是很简单的一个页面:
<!DOCTYPE html>
被引入
1
2
3
4
5
6
7
8
9
服务端根据请求的url，返回相应的页面:
const express = require('express')
const path = require('path')
const app = express();
const fs = require('fs')
app.get('/index.html', (req, res)=> {
console.log('link')
// 读取页面
const htmlPath = path.join(__dirname, './client/index.html')
fs.readFile(htmlPath, (error, content)=> {
if(!error) {
res.set({
'content-type': 'text/html'
})
// 返回页面
res.send(content)
}
})
});
app.listen(3000, ()=> console.log('server listening in port 3000'))
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
我们在看下效果（发现页面被成功嵌入）:
接下来给相应添加 X-Frame-Options 首部：
app.get('/index.html', (req, res)=> {
console.log('link')
const htmlPath = path.join(__dirname, './client/index.html')
fs.readFile(htmlPath, (error, content)=> {
if(!error) {
res.set({
'content-type': 'text/html',
'X-Frame-Options': 'DENY'
})
res.send(content)
}
})
})
1
2
3
4
5
6
7
8
9
10
11
12
13
看下效果：
页面无法嵌入，控制台报错，说首部的 X-Frame-Options 为 deny，可以看到有防点击劫持的效果。
漏洞的检测
检测系统是否存在点击劫持漏洞很简单，如果发现其响应包不包含 X-Frame-Options：deny 字段，则可以本地构造一个 HTML文 件，使用 iframe 包含此页面：
1
2
3
4
5
6
7
8
B 站是没设置该响应头的，可能存在点击劫持：
如下，可成功加载页面：
下面演示一个设置了X-Frame-Options：deny 响应头的站点：
此时使用 iframe 进行页面加载将失败：
HTTP标题
在 HTTP 协议中还有很多相关的请求头或响应头可用于网站的安全配置，具体可以参考 腾讯云开发者手册：
这里再介绍下 X-XSS-Protection响应头。
X-XSS-Protection
来理解一下什么是 X-XSS-Protection，从字面意思上看，就是浏览器内置的一种 XSS 防范措施。这个模块只能检测反射型的 XSS，下文的 XSS 专指反射型的 XSS。
没错，这是 HTTP 的一个响应头字段，要开启很简单，在服务器的响应报文里加上这个字段即可。浏览器接收到这个字段则会启用对应的 XSS 防范模块。IE、Chrome 和 Safari 都内置了这个模块，但 edge 和火狐没有内置这个模块。在 IE 上它叫 XSS Filter，在 Chrome 上它叫 XSS Auditor。
开启这个功能后，当浏览器检测到跨站脚本攻击（XSS）时，浏览器将对页面做清理或直接阻止整个页面的加载。我觉得在目前这种保护措施还是挺有必要的，虽然现代的浏览器支持强大的 CSP（内容安全策略）来禁用不安全的 JavaScript 脚本，但可能由于 CSP 配置起来较为繁琐或是修改原有的配置成本较高，目前来看还是有很大一部分网站没有用上 CSP，并且对于一些不支持 CSP 的旧版浏览器，X-XSS-Protection 可以为他们提供保护。
X-XSS-Protection 的句法如下：
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=
1
2
3
4
各个写法的含义如下：
0： 禁止XSS过滤；
1： 启用 XSS 过滤（通常在浏览器中默认）：如果检测到跨站点脚本攻击，浏览器将清理页面（删除不安全的部分）；
mode = block：启动 XSS 过滤，如果检测到攻击，浏览器将阻止页面的呈现，而不是过滤页面中的 XSS 内容；
report = ：（仅限 Chromium）启用 XSS 筛选。如果检测到跨站点脚本攻击，浏览器将清理页面并报告违规行为，这使用 CSP report-uri 指令的功能发送报告。
PHP 设置 X-XSS-Protection 响应头的方法;
header("X-XSS-Protection: 1");
1
1、X-XSS-Protection : 0 ，表示禁用 XSS 过滤这个功能
2、X-XSS-Protection : 1 ，表示启用 XSS 过滤
一般浏览器中都是默认开启。如果检测到跨站脚本攻击，浏览器将清除在页面上检测到的不安全的部分：
3、X-XSS-Protection : 1；mode=block 表示启用XSS过滤器
如果检测到攻击，浏览器不会像上面的选项一样将不安全的部分删除，而是直接阻止整个页面的加载：
4、X-XSS-Protection : 1；report= 表示启用 XSS 过滤
如果检测到跨站脚本攻击，浏览器会清除在页面上检测到的不安全的部分，并使用 report-uri 的功能 POST 一个 XSS 警报。这个功能只有在 Chrome 中有效果，在 IE 中无效。
然后我自己刚刚突发奇想，把选项写成X-XSS-Protection:1;mode=block;report=的格式，发现也是可以的。
可以同时阻止页面的加载，也可以发送一个 XSS 警报。注意这里顺序不能错，因为 IE 不支持 report XSS 警报，所以如果 mode=block 写在最后面的话，在 IE 中就无法阻止整个页面加载，而是只清除了不安全的代码。
所以，最优的选项是？
看到这里你一定觉得X-XSS-Protection:1;mode=block;report=是最优的选项。没错，我也是这么认为的。但是！凡事不是绝对的。在有些情况下，默认开启（X-XSS-Protection:1）的浏览器的 XSS filter/auditor 反而会使我们的页面变得不安全。原因很简单：
XSS filter/auditor 的过滤能力有限。这个模块的原理就是一堆的过滤规则，那就会有被绕过的可能。
清除能力有限。这个模块会清除不安全的 XSS 代码，这点是毋庸置疑的。但是如果攻击者精心构造了一段代码，在被清除了部分代码后剩下的代码仍然可以构造成恶意代码。打个简单的比方，我在一段文字中的过滤 ‘script’ 字符串，但是假设我构造了一段 “sscriptcript” 字符串，如果没有循环过滤，那么在过滤后仍然有 “script” 存在，没过滤干净会导致严重的安全问题。还有可能将无害的标签变成有害的标签。IE 8 中的 XSS 过滤器缺陷就曾经导致了一个 UXSS。
那这么说直接阻止页面加载（X-XSS-Protection:1;mode=block）不就安全了？并不是。这个选项在检测到 XSS 后会直接阻止页面的加载。但有人研究出会导致信息泄露，像这个例子：
https://bugs.chromium.org/p/chromium/issues/detail?id=396544
1
所以，对网站管理者来说，当你认为你的网页对 XSS 的防御能力已经很优秀了，那你就不需要开启 X-XSS-Protection 这个选项了，把它的值设置为 0 即可。否则，X-XSS-Protection:1;mode=block;report=是你最优的选择。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/weixin_39190897/article/details/113897741
