基于localStorage的本地存储XSS

版权声明:本文为博主原创文章,未经博主允许请尽情转载。 https://blog.csdn.net/yanghuan313/article/details/55260232

0x00 什么是localStorage

HTML5 提供了两种新的本地存储方案,sessionStorage和localStorage,统称WebStorage。
顾名思义:
sessionStorage 是针对session的数据存储,关闭窗口后删除。
localStorage 是一个本地的没有时间限制的数据存储

它们同样遵循SOP。

0x01 什么是基于localStorage的XSS

现在越来越多的前端人员把性能优化的目标指向了本地存储,利用localStorage来进行本地资源缓存,因为其大小上限为5MB,可以装相当多的东西,甚至在FireFox中你还可以修改这个上限。

那么一些关于用户个性化的设置信息完全可以存储在localStorage中,打开页面的时候JS负责从本地存储中取出数据。但所有的用户输入都是不可信的,包括本地数据,如果其中存在恶意代码,那么将会“无形中”被攻击,因为地址栏看不见payload,服务器也不知道发生了什么,只有浏览器上,悄悄地运行了恶意代码。

其实这和普通的存储型XSS差不多,但更难防御,因为恶意代码服务器无法监控,浏览器的XSS Filter也无法监控,这一切对用户都是透明的。

举个例子:

<!DOCTYPE html>
<html>
<head>
    <title>localStorage XSS</title>
</head>
<body>
<div id="test"></div>
<script type="text/javascript">
    document.getElementById("test").innerHTML = localStorage.myInfo;
</script>
</body>
</html>

很简单获取本地存储然后重绘DOM,但如果myInfo的信息被恶意控制(很简单的加个hook.js的链接),这就相当于你的浏览器被人种植了木马,除非你清理浏览器缓存,否则这个木马一直都在,只要你打开这个页面就会执行。

0x02 为什么说鸡肋

前面一切都很美好,但最重要的,是你要有方法控制写入localStorage, 你要有能力控制JS代码进行操作,但这种本地存储大多数都需要用户参与进行一些操作。比如,点一下加入购物车啊,换个主题啊,本地运行个H5小游戏攒个分数啊。但用户怎么会打开开发者工具中的控制台然后输入一堆精心构造的代码!

反射型和DOM型只需要点一下就触发,存储型更方便,相比之下,难道你要搂着用户说:“少年,我这里有一段可以让你中木马的代码,你想体验一下吗?”这不是鸡肋是什么,这相当于你要亲手操作一样,用别人电脑然后种个XSS。。。。

但凡事有例外,说不定有开发者会像下面这么干:

<!DOCTYPE html>
<html>
<head>
    <title>localStorage XSS</title>
</head>
<body>
<div id="test"></div>
<script type="text/javascript">
    localStorage.keyword = window.location.hash;
    document.getElementById("test").innerHTML = localStorage.keyword;
</script>
</body>
</html>

你只需要输入http://example.com/test#<img src=@ onerror=alert(1)> 就能完成攻击。。。。

想想这比self-XSS好像还要坑,但利用场景真的就这么不堪吗?

如果页面同域下存在一个普通的XSS(反射DOM存储都可以),那么就能完成攻击代码的本地持久存储化。

0x03 现实中的例子

这里写图片描述

这里写图片描述

这个网页就是需要你手动搜索才能触发,然后搜索的地方会保留你的搜索记录,存在本地的localStorage,但在输出的时候完全没做检查。可惜存储搜索记录的JS事件是和搜索按钮绑定的,不然在url中添加keyword参数就能直接触发了,可惜可惜。

0x04 总结

看起来很鸡肋,但如果能配合其他的漏洞(XSS,SOME等操纵JS),那么就可以完成在浏览器持久化存储,在配合上BeEF等XSS框架,简直爽歪歪。

猜你喜欢

转载自blog.csdn.net/yanghuan313/article/details/55260232