多个iFrame Busters中的XSS漏洞解析

对于那些熟悉现代广告技术的人来说,iFrame Busters是托管在发布商网站上的HTML文件,允许广告创意扩展到其标准边界之外。这些可展开的广告素材通常很容易在网站上识别,就是我们深恶痛绝的广告块。

虫虫看考有关文献发现很多Busters中存在这样或者那样的XXS漏洞,本文就跟大家一起来截些广告Busters的实现以及XSS漏洞解析。

多个iFrame Busters中的XSS漏洞解析

互联网广告行业比较分散,各广告供应商之间的流程可能差别很大。虽然对广告网络投放的完整说明超出了本文的范围,但是基本流程都是通过iFrame和iFrame Busters来实现可扩展广告素材展现。

例如,在发布商页面上提供的简单(非扩展)广告素材源码如下所示:

多个iFrame Busters中的XSS漏洞解析

请注意,iFrame的src属性指向嵌入所需广告素材的广告客户的域。这里没什么特别的。这正是任何其他外部指向iFrame的功能。此外,请注意iFrame的大小限制为300*250,标准广告位的大小。广告不能将显示扩展该框架的限制大小之外,由于同源策略(SOP)设置不能在其母页面中做DOM操纵。

为了解决这个问题并允许特定广告供应商绕过同源策略限制,通常会提供供应商iFrame Busters(特殊的HTML文件)以托管在网站的网站发布域的主机上。

一个简单典型的iFrame Buster(buster.html)可能如下所示:

多个iFrame Busters中的XSS漏洞解析

这样上面的iFrame Buster页面就可以得以嵌入网站正常页面(index.html)如下:

多个iFrame Busters中的XSS漏洞解析

我们可以从上面的源码中看到,在第3步(Step 3)中嵌入初始广告的iFrame会重定向到buster.html文件所在的站点域。然后,buster文件可以访问重定向URL中提供的参数来引用针对特定广告展示的行为。

如上所述,由于iFrame Busters位于特定供应商的。这意味着可能会要求给定的网站托管大量第三方HTML文件以支持可扩展功能。

事实上,截止最近Google还在提供了一个多广告供应商的iFrame Buster套件,可以在DoubleClick 的AdExchange文档中下载。

漏洞

谷歌后来宣布建议从发布商网站域名中删除其广告套件中的几个有问题的Busers,笔者决定对还存在的一些Busers以及DoubleClick未使用的更受欢迎的Busers做一下审查。结果发现大多数Busers中都存在基于DOM的XSS跨站脚本攻击漏洞,本文中将会介绍一些特例来说明。

Adform IFrame Manager(1.7.48)

我们使用早版本的Adform为例来做介绍。相关源码如下:

多个iFrame Busters中的XSS漏洞解析

如上所示,该buster只接受一个源URL,这个URL将作为外部JavaScript源写入DOM。上面的相关正则表达式测试,用来对将传递的脚本源URL做限制只允许特定域为白名单。

我们对该正则表达式分析,首先可以看到URL以"https://"开头并以"{任意字符}.adform.com"结尾。除了斜杠"/"之外,这部分允许插入任何其他字符。对于个过滤,我们可以轻易构建特定的URL来绕过白名单。例如,要嵌入攻击脚本,可以使用:

多个iFrame Busters中的XSS漏洞解析

改URL 的GET参数和故意错误URL个格式错误(反斜杠而不是转发)正好满足了正则表达式规则。在下面的示例中我们会看到,大多数已识别的漏洞都遵循类似的弱白名单过滤模式。

Eyeblaster

addineye iFrame Buster现在可以在很多大网站上看到。其完整的源代码有点冗长,我们节选我们专注地该漏洞部分_prepareVerificationJsonObj,其中JSON对象是由攻击者控制的document.location.search字符串发起的:

多个iFrame Busters中的XSS漏洞解析

由于最终JSON对象会传递给_sendAddInEyeVerificationToServer,我们倒推回去,可以看到它是从strAie查询字符串参数中找到的双冒号分隔字符串派生的。所以,我们可以在_prepareVerificationJsonObj中设置任意域和路径,而跳过白名单检查。一些完整的PoC URL示例如下所示:

多个iFrame Busters中的XSS漏洞解析

Adtech

Adtech还存在一个白名单弱过滤的例子,源码如下:

多个iFrame Busters中的XSS漏洞解析

在上面的实现中,代码首先会从传递的脚本URL中提取域,并确定它是否存在于allowed_domains白名单中(数组)。正则表达式中的问题乍看可能还不好看出来,但请注意它在冒号之前,对域做解析的部分,实际上可以匹配任何字串。为了绕过这一点,攻击者只需要满足白名单,同时使浏览器实际请求来自其他来源的文件。

为了达到这样目的,我们通过在URL中提供嵌入式基本身份验证认证来完成,构造的PoC示例如下:

多个iFrame Busters中的XSS漏洞解析

注意,由于Chrome 59版本59已经停止了嵌入式认证支持,因此该PoC无法在Chrome中运行,尽管它仍适用于大多数其他浏览器,包括Firefox。

Jivox

iFrame Buster XXS漏洞的最后一个示例,他有一个和上述不同类型的漏洞导致XSS。其源码如下图所示:

多个iFrame Busters中的XSS漏洞解析

一般而言,我们最想做做的是要控制的重要变量iBusterResource URL,它最终用于填充脚本标记的src属性。而该参数在父页面已经在写入DOM的字符串了,所以我们只需要在附加此字符串之前偷偷的将其改为我们的URL,同时使其余部分与实际请求无关。

关键是,在"."字符上也有拆分,所以传递的URL的第一个子域是代码作者希望接收的。

另外,注意到在document.write之前调用了一个unescape。所以着我们可以使用双重编码来满足这两个条件来绕过限制:

多个iFrame Busters中的XSS漏洞解析

在URL解码后,会生成iBusterResourceURL值:

多个iFrame Busters中的XSS漏洞解析

最后,在unescape之后:

多个iFrame Busters中的XSS漏洞解析

最后的散列使剩余的硬编码字符越过了URL的限制。

最佳实践

如果使用正则表达式子来过滤+白名单的限制逻辑,则可能存问题和bug。如果需要在JavaScript中做域解析,实现白名单,最好最安全的解决方案是使用DOM 接口,比如:

多个iFrame Busters中的XSS漏洞解析


分享到:


相關文章: