有关DOM XSS的一点思考

最新推荐文章于 2024-07-30 09:07:19 发布

9ian1i

最新推荐文章于 2024-07-30 09:07:19 发布

阅读量1.4k

点赞数

分类专栏： XSS 文章标签： xss

本文链接：https://blog.csdn.net/yanghuan313/article/details/52373150

版权

XSS 专栏收录该内容

3 篇文章 1 订阅

订阅专栏

前段时间发现了某站的一个DOM XSS漏洞，发到补天说无法复现，我开始琢磨其中的问题。

我们首先大致还原一下场景：

例子一：

<!DOCTYPE html>
<html>
<head>
    <title>xss test</title>
</head>
<body>
    <div id="xss">
    </div>
</body>
<script type="text/javascript">
    var a = document.location.href;
    document.getElementById("xss").innerHTML="<a href="+a+">test</a>";
</script>
</html>

然后，我们用chrome在本地打开这个网页，并在地址后面加上#"><img src=@ onerror=alert(1)>,刷新页面，弹窗了。

为什么？因为chrome对#之后的部分不进行任何的urlencode处理，但是火狐就会进行编码，所以以上弹窗在chrome及大多数浏览器下都能实现。

但是我们换个输出方式呢：

例子二：

<!DOCTYPE html>
<html>
<head>
    <title>xss test</title>
</head>
<body>
</body>
<script type="text/javascript">
    var a = document.location.href;
    document.write("<a href="+a+">test</a>");
</script>
</html>

结果还会弹窗吗？答案是不会，chrome虽然没有对其进行urlencode编码，但是却这个脚本却会被Chrome XSS Filter拦截，按F12可以看到错误报告。只是输出的语句不同，为什么却有这个区别呢？document.write这个语句是一般的文本输出，我猜想Chrome对innerHTML这个语句的限制不会有这么严格，顾名思义，人家这个语句的名字就可以看出来是为了输出HTML标签的，浏览器或许为了保证正常的DOM解析而没有对它进行太过严格的过滤，这只是我的一个猜想。

我们继续研究第一个例子，这次我们在地址后面加上 #"><script>alert(1)</script>,再次刷新，会弹窗吗？答案是不会。

我们按F12查看源代码，发现<script></script>已经被视为标签了，但脚本内容却没有执行，很显然被XSS Filter拦截了，看来谷歌的这个东西对DOM XSS还是有一点作用的，明显的标签的确逃不过。

总结一下，第一个例子中的漏洞应该是确实存在的，但只是不能用<script> 标签触发，我不明白补天为什么会说无法复现，或许chrome版本问题吧。