DVWA系列5:XSS 跨站脚本攻击之 存储型

DVWA系列5:XSS 跨站脚本攻击之 存储型

前言

上一篇文章介绍了 XSS 中的 DOM 型 和 反射型,这两者都是不与目标网站的后台服务器交互的。而存储型是使用各种方法将攻击内容保存到了目标网站的后台服务器,任何看到的用户都会被攻击。往往发生于输入框,留言板等地方。

1. 攻击实操

(1)目标网站环境

这是一个留言板功能, 用户留的言会被保存并展示

为了简化 payload 的长度,本文章依然使用 alert 作展示。

(2)Low 难度实操

有了之前的经验,直接上 payload ,将其填入 Message 框中:

<script>alert(123)</script>

提交后另起一个浏览器,模仿其他用户访问(为了模拟同样的服务器环境,难度也应调整为 Low)。会发现,每次访问都会 alert 123。

(3)Medium 难度实操

观察一下代码:

发现对 Message 字段进行了 strip_tags 处理(百度一下,即为 “去除所有的 html 标签”),我们的 script 标签自然就不得行了。但是对于 Name 只是简单去除了 script 标签,这个我们说,简直简直了。此时我们构造一个 异形 script 的 payload:

<scr<script>ipt>alert(123)</script>

放置到 name 标签中,但是发现字段长度限制放不上去。作为客户端,我们可以不讲武德,按 F12,使用 浏览器的开发者工具去除限制:

即使有的时候无法解除限制,也可以使用 BurpSuite 篡改请求达到同样的效果。

依然达到了效果:

此时不禁想到了一句话:任何“侥幸”都将被绳之以法,2333333333。

(4)High 难度

再次查看下源码,发现 Name 字段对 script 标签进行了完整的过滤:

那我们使用 img 标签不久可以了:

<img src="1" onerror="alert(123)">

2. 填个坑?

之前在介绍 CSRF 攻击时,挖了个坑:说可以使用 XSS,让用户访问网站时进行同站的敏感操作,达到跨站所达不到的目的。现在不就派上用场了——如果我们将修改密码的请求链接填入表单并存下来,是不是就可以神不知鬼不觉的修改管理员密码了XD?

(1)直接来吧(在 Medium 难度下实验)

<img src="/vulnerabilities/csrf/?password_new=12345678&password_conf=12345678&Change=Change" />

此处需要注意的是,因为是同站,所以无需指定协议与 IP 地址了。

再次去登录页面,发现原先的密码 password 登不上去了。

(2)High 难度实验?

此时在看这篇文章的 吴彦祖/刘亦菲 要问了:难道在 High 难度不可以吗? 在 High 难度下遇到了这几个问题:

A. 数据库字段长度限制

经过实验发现,如果长度超过了 100,超出部分的内容会被舍弃。因此我们的 payload 如果太长便失去了意义。而 在 High 难度下,CSRF 的目标页面会每次生成一个 token。在 100 长度的限制下,难以写成获取 token 的 payload。

B. High 难度的防御仍然有一定限制

High 的难度完整的过滤了 script 标签,准确的说是 过滤 <、s、c、r、i、p、t 这几个字符,且忽略其大小写。payload 中满足正则表达式的部分会直接被清除。而在 payload 中,我们已经集齐了 <、s、c、r、i、p 这几个,就差一个 t 就可以召唤神龙了(bushi),再想想参数名叫什么 —— token,啊啊啊。

3. 总结

这两次把 DVWA 中的 XSS 的攻击路径都实践了一遍。应对这种攻击思路也比较明确,就是不要信任前端过啦的任何输入!!!,入参都必须经过过滤!!! 接下来打算研究下 文件上传 漏洞了。

其实想想多于那些高手来说,这些限制也总有绕过的办法,这些实践对于一些流行攻击的手段来说可能只是九牛一毛。还望各位阅读的大佬不吝赐教!

参考

DVWA之XSS (完整版)

posted @ 2023-03-08 13:11  battor  阅读(342)  评论(0编辑  收藏  举报