渗透测试 | Dvwa XSS超详细通关题解

XSS

介绍

基本原理

XSS中文名为跨站脚本攻击，意思是通过将恶意脚本注入到正常的网站中，并以某种方式发送给用户，用户一旦进入这个页面，恶意脚本则会将用户的重要信息如Cookie收集。

分类

• 反射型XSS：一般为单点攻击，攻击者首先构造XSS代码通过表单提交至服务器，服务器响应后，前端执行代码并输出到网页，攻击者再将包含XSS代码的URL发送给用户，用户点击后触发，用户的敏感信息被攻击者收集。
• 存储型XSS：攻击者提交一段XSS代码后，被服务器接收并存储，每一个用户再次访问该页面时，XSS代码都会被响应并执行。例如论坛中的留言回复等板块，攻击者在输入框将XSS代码提交，服务器会将该代码存储到数据库中，因此，每一个浏览该页面的用户都会遭受XSS。
• DOM型XSS：与前两者不同，DOM型XSS不会与后台服务器发生交互，而是通过修改DOM节点在客户端执行代码。反射型XSS的payload会呈现在服务器返回的响应中，而DOM型不会。

可能出现的位置

• 回显搜索字符串的搜索栏
• 回显用户数据的输入框
• 返回用户提交数据的报错信息
• 包含用户提交数据的隐藏域
• 任意可能展示用户所提交数据的页面
  • 留言板
  • 回复框
• HTTP头

影响

• 窃取cookies、session等敏感信息
• 创造错误请求
• 重定向至恶意网站
• 伪造合法用户创造请求
• 在客户端系统执行恶意脚本
• 插入恶意内容如广告、非法页面

常用Payload

script标签：引入外部的JavaScript代码，将代码插入标记脚本中

svg标签：用于绘制svg图形，onload事件在图像或页面加载完后立即发生

img标签：给出一个不存在的img地址，使用onerror报错事件

body标签：

style标签

参考：https://www.cnblogs.com/csnd/p/11807592.html

DVWA

反射型XSS

前提：在HTML标签中有一个

让浏览器弹出一个告警框

点击提交：

这就是一个简单的XSS漏洞 ，上面我们提交的代码就叫payload，我们还可尝试其他payload：

这个payload使用到了img标签，给img的src属性赋了一个不存在的值，那么便会触发onerror事件告警，在告警内容中写入不同代码，就可以让浏览器出现异常弹窗。
当我们利用 XSS将一些特定的代码片段插入网页时，便可获取到用户的敏感信息，如cookie，下面在输入框提交如下内容：

浏览器将会弹窗出用户的cookie，同时我们可以发现，目前所在网页的URL已经改变，如果将该链接以某种方式发送给不同用户，每个用户点击后都会出现弹窗显示出自己的cookie。
回到最初输入XSS代码时，如果我们修改payload，让浏览器将cookie值读取并发送至我们自己的服务器中并存储在数据库里，那么只要将包含XSS的链接发给任意多的用户，只要有用户打开该链接，其cookie就会被收集到我们的数据库中。

medium

接下来将安全等级调至medium，回到反射型XSS查看源代码：

可以看到代码中有一行用到了str_replace函数，将

依然成功！这里有一个有趣的点，源代码只把

验证一下也是可以成功的，我们上面使用img标签的payload自然也是可以成功，因为它完全没有被过滤！

high

再来看high等级的源码：

可以看到这里使用了preg_replace函数，这是一个使用正则表达式进行字符串替换的函数，此处正则的意思为匹配所有顺序出现的字符串并且末尾的i表示忽略大小写，这样一来，我们之前标签嵌套的方法就不再适用了。但此处仍然只过滤了

本来也想尝试在name里注入，结果发现name存在长度限制：

打开开发者工具修改长度限制为1000就可以在name中也执行攻击了。

再次在Message中提交payload：

第二次提交时发现，会首先弹出第一次的对话框，点击OK再次弹出的才是我们此次payload的内容，这是因为提交一次，页面会刷新一次将留言版更新，那么我们之前所提交的“留言”也会重新显示，也就会再次弹窗了。

medium

查看源码发现对input使用了htmlspecialchars函数处理，对name的输入内容进行了

或者更换为img标签

high

先看源码：

类似的使用img标签绕过

impossible

源码：

对name和message都进行了严格的过滤。

DOM XSS

DOM XSS是指通过修改DOM节点进行 XSS攻击，我们输入的 XSS代码只会对前端产生影响而不会与后端发生交互，有点抽象，可以在实战中加深理解。

low

用开发者工具查看源码：

发现里面有一个default的参数，可以自定义页面打开的默认语言，那么这就容易称为一个 XSS攻击的入口，可在URL后拼接语句尝试：

medium

依然是先来看源码：

stripos() 函数查找字符串在另一字符串中第一次出现的位置（不区分大小写）。
注释：stripos() 函数是不区分大小写的。
注释：该函数是二进制安全的。

header() 函数向客户端发送原始的 HTTP 报头。

这段代码的意思是，在default的值中查找字符串，如果查找到，就使用之前的HTTP报头，那么我们在URL中拼接的代码就不会起作用了。

high

源码：

可以看到源码中设置了白名单，并且在白名单之外的都使用上一次的http头部。

这里绕过白名单需要用到#（hash），可以参考https://www.cnblogs.com/lishanlei/p/10707824.html这篇文章，解释得很详细。

我们直接利用#将原来的payload放在URL里，这样它只会在前端触发，而不经过后端，因此也不会受到后端白名单的限制。

impossible

在impossible中，我们发现提交的 payload被编码后出现在了选择框里：

F12查看源码：

对比一下low等级的源码：

可以发现在写入时，impossible的机制是不对写入值进行解码，那么我们拼接的Payload经过浏览器编码后就直接输入到网页里了：

XSS攻击自然也就失效了。