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、邮箱业务
在这里插入图片描述


通过邮箱业务下的XSS漏洞,黑客能够偷取到邮箱用户的cookie。借助这个令牌,攻击者就可以自由出入用户的邮箱,收发用户的私密邮件。往广了讲,攻击者可以劫持用户继续扩散恶意邮件,偷取更多邮箱用户的令牌,进而控制更多的邮箱。往深了讲,攻击者可以获取用户邮箱中的敏感信息,进而重置邮箱用户在其他网站注册的账号密码。 比如QQ、微博、网盘、金融账户等等。



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首先闭合了标签 和 标签利用 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漏洞了。





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

本文完,感谢你的阅读!!!

最后,如果本文对你有所帮助,希望可以点个赞支持一下。你们的鼓励将会是博主原创的动力。
在这里插入图片描述

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页