Web安全——DOM-XSS详解

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Web安全——DOM-XSS详解
点赞后看,养成习惯
喜欢的话 可以点个关注哟
你们的点赞支持对博主们来说很重要哦 !!!

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

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

02 我们可以用XSS做什么?

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

image.png


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

1、检测的困难性

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

2、对抗策略易泄露性

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

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

image.png






## 02 我们可以用XSS做什么?

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

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

拿具体业务场景举例:

1、邮箱业务
image.png



通过邮箱业务下的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)攻击点举例:

image.png



1、Low等级

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

<?php # No protections, anything goes ?>


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


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

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


输入URL中,攻击成功
image.png




2、Medium等级

查看服务端源代码

<?php

// Is there any input?
if ( array_key_exists( "default", {
   
   mathJaxContainer[0]}_GET[ 'default' ]) ) {
   
   
{
   
   mathJaxContainer[1]}_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伪协议。
攻击效果如下:image.png



3、High等级

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

<?php

// Is there any input?
if ( array_key_exists( "default", {
   
   mathJaxContainer[2]}_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>


攻击成功,测试效果如下:

image.png



4、Impossible等级

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

image.png


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

image.png


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

image.png

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



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

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

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

目录
相关文章
|
18天前
|
SQL 负载均衡 安全
安全至上:Web应用防火墙技术深度剖析与实战
【10月更文挑战第29天】在数字化时代,Web应用防火墙(WAF)成为保护Web应用免受攻击的关键技术。本文深入解析WAF的工作原理和核心组件,如Envoy和Coraza,并提供实战指南,涵盖动态加载规则、集成威胁情报、高可用性配置等内容,帮助开发者和安全专家构建更安全的Web环境。
36 1
|
20天前
|
安全 前端开发 Java
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域,本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS,介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF,提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略,开发者可以构建更安全的Web应用。
58 4
|
19天前
|
安全 Go PHP
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS,介绍了输入验证与净化、内容安全策略(CSP)和HTTP头部安全配置;针对CSRF,提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法,帮助开发者有效保护网站和用户数据安全。
47 2
|
22天前
|
存储 安全 Go
Web安全基础:防范XSS与CSRF攻击的方法
【10月更文挑战第25天】Web安全是互联网应用开发中的重要环节。本文通过具体案例分析了跨站脚本攻击(XSS)和跨站请求伪造(CSRF)的原理及防范方法,包括服务器端数据过滤、使用Content Security Policy (CSP)、添加CSRF令牌等措施,帮助开发者构建更安全的Web应用。
52 3
|
24天前
|
SQL 安全 Go
PHP在Web开发中的安全实践与防范措施###
【10月更文挑战第22天】 本文深入探讨了PHP在Web开发中面临的主要安全挑战,包括SQL注入、XSS攻击、CSRF攻击及文件包含漏洞等,并详细阐述了针对这些风险的有效防范策略。通过具体案例分析,揭示了安全编码的重要性,以及如何结合PHP特性与最佳实践来加固Web应用的安全性。全文旨在为开发者提供实用的安全指南,帮助构建更加安全可靠的PHP Web应用。 ###
33 1
|
27天前
|
Kubernetes 安全 应用服务中间件
动态威胁场景下赋能企业安全,F5推出BIG-IP Next Web应用防火墙
动态威胁场景下赋能企业安全,F5推出BIG-IP Next Web应用防火墙
47 3
|
1月前
|
缓存 安全 JavaScript
掌握JAMstack:构建更快、更安全的Web应用
JAMstack 是一种现代 Web 开发架构,结合 JavaScript、APIs 和 Markup,创建更快、更安全的 Web 应用。其核心优势包括高性能、安全性、可扩展性和易维护性。JAMstack 通过预构建静态页面和 API 实现高效渲染,利用静态站点生成器如 Gatsby 和 Next.js,并借助 CDN 和缓存策略提升全球访问速度。尽管面临复杂交互、SEO 和数据更新等挑战,但通过 Serverless Functions、预渲染和实时 API 更新等方案,这些挑战正逐步得到解决。
|
1月前
|
监控 安全 Apache
构建安全的URL重定向策略:确保从Web到App平滑过渡的最佳实践
【10月更文挑战第2天】URL重定向是Web开发中常见的操作,它允许服务器根据请求的URL将用户重定向到另一个URL。然而,如果重定向过程没有得到妥善处理,可能会导致安全漏洞,如开放重定向攻击。因此,确保重定向过程的安全性至关重要。
73 0
|
1月前
|
云安全 SQL 安全
数字时代下的Web应用程序安全:漏洞扫描服务的功能与优势
在当今这个数字化时代,Web应用程序不仅是企业与用户之间互动的桥梁,更是企业展示服务、传递价值的核心平台。然而,随着技术的不断进步,Web应用程序的复杂性也在不断增加,这为恶意攻击者提供了可乘之机。安全漏洞的频发,如SQL注入、跨站脚本攻击(XSS)、跨站请求伪造(CSRF)等,严重威胁着企业的数据安全、服务稳定性乃至经济利益。在这样的背景下,漏洞扫描服务作为一道重要的安全防线,显得尤为重要。本文将深入探讨漏洞扫描服务在面对Web应用程序安全问题时,所具备的功能优势。
|
Web App开发 JavaScript 数据建模
从零开始学 Web 之 DOM(三)innerText与innerHTML、自定义属性
大家好,这里是「 Daotin的梦呓 」从零开始学 Web 系列教程。此文首发于「 Daotin的梦呓 」公众号,欢迎大家订阅关注。在这里我会从 Web 前端零基础开始,一步步学习 Web 相关的知识点,期间也会分享一些好玩的项目。
1335 0
下一篇
无影云桌面