Web安全——DOM-XSS详解

点赞后看，养成习惯
喜欢的话 可以点个关注哟
你们的点赞支持对博主们来说很重要哦 ！！！

本文将针对以下问题逐条进行解答：

01 为什么解决DOM XSS漏洞迫在眉睫？

02 我们可以用XSS做什么？

03 具体场景是如何利用的？

01 为什么解决DOM XSS漏洞迫在眉睫？

1、检测的困难性

与普通XSS不同，DOM XSS是在浏览器的解析中改变页面DOM树，且恶意代码并不在返回页面源码中回显。这使我们无法通过特征匹配来检测DOM XSS，给自动化检测带来了挑战。

2、对抗策略易泄露性

而且，由于js是一门客户端脚本语言，其逻辑代码可以被任意用户查看到，所以不少DOM XSS对抗策略会再次被攻击者绕过。

打个比方来说，DOM XSS就像是广场上随处可见的口香糖，贼恶心人。如果要根治，那就需要在开发过程中，有针对性地留意容易造成DOM XSS的JavaScript代码，对传入的数据做严格的过滤，将其限制在可控范围内，才能从根本上解决DOM XSS。

02 我们可以用XSS做什么？

一般来说，XSS给人最经常的印象就是无穷无尽的弹窗，除了烦人外，没有什么关系。

但实际上，如果通过XSS获取到用户的cookie，尤其是管理员的cookie，那么你就可以借此登录管理员后台，新建管理员、上传webshell文件、getshell跨站调用、创建一个模板等等。

拿具体业务场景举例：

1、邮箱业务

2、客户端产品"特权域"业务

先举个特权域的例子，发送验证码功能之所以能调用浏览器插件，自动向手机推送一条消息。是因为，客户端开发工程师设下了结界，只有某某功能才能调用"结界"内的API接口。

之所有有特权域，是为了考虑安全，你不可能让所有web域都有调用这些具有“特权”的接口。

但是如果在这种特权域下，出现了XSS漏洞，那么攻击者可以通过引入外部恶意JS，让自己具备调用特权API的权限。至此，开发者设下的结界被攻破，甚至可以导致客户端产品的远程代码执行。



这里重点关注一下我今天学习到的两种DOM XSS的常见利用场景：

01、在前端实现页面跳转

我们知道，业务实现页面跳转的实现方式，通常有三种：

1.1 在后端设置302跳转Hearder或通过函数接受参数实现跳转。

1.2 使用Meta标签实现跳转

1.3 通过JavaScript实现跳转，常用的方法有：location.href/location.replace()/location.assign()

一提到页面跳转，或许第一时间想到的是限制不严导致任意URL跳转。但如果我们了解到"伪协议"的话，我们就会发现，这个页面跳转与DOM XSS牵上了线。这个伪协议包括但不限于：“javascript:”、“vbscript:”、“data:”、“tencent:”、“mobileqqapi:”等，其中“javascript:”、“vbscript:”、“data:”在浏览器下可以执行脚本：。

不给经过了今年的DOM XSS攻击洗礼，前端开发工程师也就聪明了起来，直接从各种来源获取目标URL，不怎么使用以上三种JavaScript实现跳转。

但是呢，毕竟JavaScript是没有遮羞布的，攻击者可以直接查看防御策略。所以，陆陆续续，攻击者就学会了针对性地进行攻击。比如说indexOf绕过、正则表达式缺陷。



02、从URL中的取参数值写入页面或动态执行

比如说可以通过location.hash，即设置为锚部分从#之后的部分，既能让JS读取到该参数，又不让该参数传入到服务器，从而避免waf检测。location.search也类似，它可以把部分参数放在?之后的部分。

03 具体场景是如何利用的？

这里，我以DVWA的XSS（DOM）攻击点举例：

1、Low等级

查看服务端代码，发现什么都没有

<?php # No protections, anything goes ?> 

鼠标右键查看网页前端源代码，发现indexOf检索到default字符串后，可进行document.write的拼接操作。

接下来尝试构造XSS攻击语句

http://127.0.0.1/dvwa-master/vulnerabilities/xss_d/?default=English<script>alert(/xss/);</script>

输入URL中，攻击成功

2、Medium等级

查看服务端源代码

<?php

// Is there any input?
if ( array_key_exists( "default", $_GET ) && !is_null ($_GET[ 'default' ]) ) {
$default = $_GET['default'];
# Do not allow script tags
if (stripos ($default, "<script") !== false) {
header ("location: ?default=English");
exit;
}
}

?>

观察源代码可知，Medium 级别过滤了 <script>，于是构造攻击语句

1、</option></select><img src=1 onerror=alert(/xss/)>
这个payload首先闭合了<option>标签 和 <select>标签利用 img标签的onerror事件javascript，img标签支持onerror 事件，在加载图像的过程中如果发生了错误，就会触发onerror事件。

2、?default=</option></select><a href="javascript:alert('xss')">test</a>
这个payload采用JavaScript伪协议。
攻击效果如下：

3、High等级

查看服务端源代码，发现default的值只能为 French、English、German、Spanish

<?php

// Is there any input?
if ( array_key_exists( "default", $_GET ) && !is_null ($_GET[ 'default' ]) ) {

# White list the allowable languages
switch ($_GET['default']) {
case "French":
case "English":
case "German":
case "Spanish":
# ok
break;
default:
header ("location: ?default=English");
exit;
}
}

?>

那这时候，我们就想既然被传入服务端的数据被做了限制，那我们就尝试在前端做手脚。我们可以尝试利用注释符构造，构造攻击语句。因为在URL栏中#之后的字符不会提交到服务器，就实现绕过白名单。

构造攻击语句

http://www.dvwa.com/vulnerabilities/xss_d/?default=English #<script>alert(/xss/)</script>

攻击成功，测试效果如下：

4、Impossible等级

查看服务端代码，发现服务端提示以下信息

接着，看看网页源代码，我们发现lang不再通过decodeURL()函数获取lang值

测试输入 <script>alert('xss')</script>，返回页面如下：

到这里，结合源代码我们可以明白，这里对我们输入的参数并没有进行URL解码，但是我们输入的任何参数都是经过URL编码，然后直接赋值给option标签。所以，就不存在XSS漏洞了。

以上文章，作为自己的学习笔记，仅供参考

本文完，感谢你的阅读！！！

最后，如果本文对你有所帮助，希望可以点个赞支持一下。你们的鼓励将会是博主原创的动力。