ACM

ACM通信

首页 / 杂志存档 / 2009年6月(第五十二卷第六期) / 保护浏览器中的帧通信 /全文

研究突出了

保护浏览器中的帧通信

作者:亚当·巴斯，科林·杰克逊，约翰·c·米切尔
ACM通信，2009年6月，52卷第6期，83-91页
10.1145/1516046.1516066
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit上分享在StumbleUpon上分享在黑客新闻上分享在推特上分享在Facebook上分享

许多Web站点在框架中嵌入第三方内容，依靠浏览器的安全策略来防止恶意内容。然而，帧在浏览器中提供了不够的隔离性，让框架内容导航其他帧。我们评估了现有的框架导航策略，并主张采用更严格的策略，我们将其部署在开源浏览器中。除了防止不希望的交互之外，浏览器严格的隔离策略也会影响合作框架之间的通信。因此，我们分析了孤立帧间帧间通信的两种技术。第一种方法是片段标识符消息传递，它最初提供了不需要身份验证的机密性，我们使用一个众所周知的网络协议中的概念进行修复。第二种方法，postMessage，最初提供身份验证，但我们发现了违反机密性的攻击。我们建议改进postMessageAPI提供机密性;我们的建议已经被标准化并在浏览器实现中采用。

回到顶部

1.简介

网站包含来自不同可信度来源的内容。例如，许多网站包含由广告网络或其子公司提供的第三方广告。^3.其他常见的第三方内容聚合包括Flickr相册、Facebook徽章和三大门户网站提供的个性化主页(iGoogle、My Yahoo!和Windows Live)。更高级的第三方组件使用包括Yelp使用谷歌地图显示餐厅位置，以及Windows Live联系人小工具。将来自多个来源的内容组合在一起的网站称为混搭，与当事人结合的内容称为积分器，和集成内容称为小工具。在简单的mashup中，集成器不打算与gadget通信，只要求浏览器提供隔离。在更复杂的mashup中，积分器确实希望进行通信，并且需要安全的帧间通信。当站点希望在其页面上的内容之间提供隔离和通信时，站点不可避免地依赖于浏览器呈现过程和隔离策略，因为Web内容是在浏览器控制下呈现和查看的。

在本文中，我们研究了计算机系统中一个反复出现的问题的当代Web版本:在提供安全组件间通信的同时隔离不受信任或部分受信任的组件。每当一个网站集成了第三方内容，如广告、地图或相册，该网站就有包含恶意内容的风险。如果没有隔离，恶意内容可能会破坏用户与集成商之间会话的机密性和完整性。尽管浏览器众所周知的“同源策略”¹⁹限制在一个帧中运行的脚本操作另一个帧中的内容，浏览器使用不同的策略来确定是否允许一个帧导航(改变另一个帧的位置)。尽管浏览器必须限制导航以提供隔离，但导航是主要公司使用的一种帧间通信形式的基础，导航可以用于攻击第二种帧间通信机制。

许多最近的浏览器都有过度允许的框架导航策略，这导致了各种各样的攻击。为了防止攻击，我们针对谷歌AdSense登录页面和iGoogle小工具聚合器进行了演示，我们建议收紧浏览器的框架导航策略。通过对四种策略的比较，我们主张使用一种特定的策略，该策略在限制导航的同时保持与现有Web内容的兼容性。我们与HTML 5工作组合作，将此策略标准化，并与浏览器供应商在Firefox 3、Safari 3.1和谷歌Chrome中部署此策略。因为该策略已经在Internet Explorer 7中实现了，所以我们的首选策略现在是标准化的，并部署在四个最常用的浏览器中。

在强隔离情况下，框架的交互受到限制，这就提出了隔离的框架如何作为mashup的一部分进行合作的问题。我们分析了帧间通信的两种技术:片段标识符消息传递和postMessage．表1总结我们的结果。

片段标识符消息传递使用帧导航在帧之间发送消息。此通道缺乏一个重要的安全属性:消息是机密的，但发件人不经过身份验证。这些属性类似于网络通道，其中发送方使用接收方的公钥加密其消息。的Microsoft.Live.Channels库使用片段标识符消息传递让Windows Live Contacts小工具与它的积分器通信，遵循类似Needham-Schroeder公钥协议的身份验证协议。¹⁷我们发现了针对该协议的攻击，与尼德汉姆-施罗德协议中的洛氏异常有关，¹⁵恶意小工具可以冒充联系人小工具的集成商。基于Lowe对Needham-Schroeder协议的改进，我们提出了一个解决方案¹⁵微软实现和部署的。
postMessage浏览器API是为帧间通信设计的吗¹⁰在Internet Explorer 8、Firefox 3、Safari 4、谷歌Chrome和Opera中实现。虽然postMessage已经在Opera中部署了，我们演示了使用框架导航对通道机密性的攻击。鉴于这次袭击，警方postMessage通道提供身份验证，但缺乏保密性，这类似于发送方对其消息进行加密签名的通道。为了保护通道，我们建议修改API。我们的建议已经被HTML 5工作组和所有主要的浏览器采纳。

本文的其余部分组织如下。第2节详细介绍了我们的威胁模型。第3节概述了现有的框架导航策略并对安全策略进行了标准化。第4节分析了两种框架通信机制，演示了攻击，并提出了防御措施。第5节介绍了相关工作。第6节结束。

回到顶部

2.威胁模型

在本节中，我们将定义精确的威胁模型，以便确定浏览器机制防御特定类型攻击的有效性。我们考虑两种攻击者，一种是“Web攻击者”，另一种是功能稍强的“gadget攻击者”。虽然网络钓鱼^4，6可以非正式地描述为Web攻击，但我们不认为Web攻击者或gadget攻击者可以通过使用令人困惑的域名(如bankofthevvest.com)或通过其他社会工程。相反，我们假设用户准确无误地使用了所有浏览器安全功能，包括位置栏和锁图标。

2.1.网络攻击者

一个网络攻击者在网络上拥有一台或多台机器的恶意主体。为了研究浏览器安全策略，我们假设用户的浏览器呈现来自攻击者Web站点的内容。

网络能力:Web攻击者没有特殊的网络能力。特别是，Web攻击者只能从他或她控制下的机器发送和接收网络消息，这些机器可能在攻击者选择的网络协议中充当客户机或服务器。通常，Web攻击者使用至少一台机器作为HTTP服务器，我们将其称为attacker.com．Web攻击者拥有他或她拥有的域名的HTTPS证书;证书颁发机构免费提供这类证书。Web攻击者的网络能力是决定性的较弱的因为Web攻击者既不能窃听发送到其他网络位置的消息，也不能伪造来自其他网络位置的消息。例如，Web攻击者不可能是网络“中间人”。
客户端功能:我们假设用户查看attacker.com在流行的浏览器中，呈现攻击者的内容。我们做出这样的假设是因为一个诚实的用户与一个诚实的网站的交互应该是安全的，即使用户在另一个浏览器窗口中访问了一个恶意的网站。Web攻击者的内容受浏览器安全策略的制约，这使得Web攻击者非常明确较弱的攻击者可以使用用户的权限执行任意代码。例如，Web攻击者不能安装系统范围的密钥记录器或僵尸网络客户端。

我们不假设用户对待attacker.com作为一个网站而不是attacker.com．例如，用户从不给出bank.com密码attacker.com．我们还假设诚实的站点不存在跨站点脚本漏洞。^20.事实上，本文中描述的攻击都没有依赖于将恶意JavaScript作为诚实的主体运行。相反，我们关注浏览器本身为攻击者提供的与诚实站点交互的特权。

除了保护访问恶意网站的用户外，我们还假设用户访问attacker.com进一步支持吸引用户的几个技术。例如，攻击者可以放置Web广告，主办具有有机吸引力的流行内容，或发送大量电子邮件鼓励访问者。通常,简单的查看攻击者的广告(例如在搜索页面上)允许攻击者发起Web攻击。在之前的一项研究中，¹²我们花30美元购买了超过5万次的印象。在每次这些印象中，用户的浏览器呈现了我们的内容，为我们提供了发起Web攻击所需的访问权限。

Web攻击者可以访问的攻击具有重大的实际影响，因为这些攻击不需要对网络进行不寻常的控制。一旦用户访问单个HTTP站点，标准的中间人网络攻击者也可以执行Web攻击，因为中间人可以在HTTP响应中注入恶意内容，模拟来自的回复attacker.com．

2.2.小工具攻击者

小工具攻击者是一个具有额外能力的Web攻击者:集成器嵌入攻击者选择的小工具。这个假设让我们能够准确地评估mashup隔离和通信协议，因为这些协议的目的是让集成器安全地嵌入不受信任的小部件。在实践中，小工具攻击者可以等待用户访问集成商，也可以将用户重定向到集成商的Web站点attacker.com．

回到顶部

3.框架隔离

Web站点可以使用框架将其屏幕实际空间的一部分委托给其他Web站点。例如，一个网站可以将其页面的部分内容出售给广告网络。浏览器显示主、或的位置顶级，在它的位置栏。子帧通常在视觉上与页面的其他部分难以区分，浏览器也不会在其用户界面中显示它们的位置。

3.1.背景

浏览器的脚本策略回答了“何时一个帧可以操作另一个帧的内容?”脚本策略是浏览器安全策略中最重要的部分，因为一个框架可以代表它可以编写脚本的每一个其他框架。例如,

试图从另一个窗口读取用户密码。现代Web浏览器允许一个帧读写另一个帧的所有属性，只有当它们的内容从同一帧中检索时起源，即当该方案(例如，http或https)，主机和端口的位置匹配。如果内容otherWindow从不同的来源检索，浏览器的安全策略将阻止上面的脚本访问otherWindow.document．

除了执行脚本策略之外，每个浏览器都必须回答这样一个问题:“何时允许一个帧浏览另一个帧?”在1999年之前，所有的Web浏览器都执行了一个允许策略:

例如，如果otherWindow包括一个框架，

导航帧到https://attacker.com/．在允许策略下，浏览器进行导航otherWindow即使它包含来自另一个来源的内容。有许多用于导航帧的习惯用法，包括

Which导航一个名为frameName．框架名称存在于跨起源共享的全局名称空间中。

3.2.Cross-window攻击

1999年，Georgi Guninski发现允许框架导航策略允许严重攻击。⁷当时，CitiBank登录页面上的密码字段包含在一个框架中，Web攻击者可以将该框架导航到https://attacker.com/，让攻击者用看起来相同的内容填充框架，从而窃取密码。这cross-window攻击程序如下:

用户查看显示攻击者广告的博客。
另外，用户访问bank.com，它将在一个帧中显示其密码字段。
广告将密码帧导航到https://attacker.com/．位置栏还在https://bank.com锁图标仍然存在。
用户输入他或她的bank.com密码进入https://attacker.com/框架上bank.com页，将密码提交给attacker.com．

在目前大量使用的浏览器中，Internet Explorer 6和Safari 3都实现了允许策略，并允许这种攻击。Internet Explorer 7和Firefox 2实现了更严格的策略(在后面的小节中描述)。许多网站，包括谷歌AdSense，在一个帧中显示他们的密码字段，容易受到这种攻击;看到图1．

3.3.同一窗口攻击

2001年，Mozilla通过实施更严格的策略来防止跨窗口攻击:

此策略可以防止跨窗口攻击，因为Web攻击者不控制受信任窗口中的框架，而且如果在窗口中没有立足点，攻击者就无法导航登录框架。但是，窗口策略不够严格，无法保护用户，因为小工具攻击者确实可以在mashup中的受信任窗口中立足。(回想一下，在mashup中，集成商将来自不同来源的gadget组合成单一体验。)

整合:小工具聚合器，如iGoogle, My Yahoo!和Windows Live提供了一种形式的mashup。这些网站允许用户通过在主页上包含小工具(如股票报价、天气预报和新闻订阅)来定制他们的体验。这些网站将第三方设备放在框架中，并依靠浏览器保护用户免受恶意设备的伤害。
广告:网络广告产生了将第一方内容(如新闻文章或体育统计数据)与第三方广告相结合的mashup。大多数广告，包括谷歌AdWords，都包含在框架中，这既是为了防止广告商(提供小工具的人)干扰发布者的网站，也是为了防止发布者使用JavaScript点击广告。

我们把有广告的页面称为简单的混搭因为积分器和小部件无法通信。简单的mashup依赖于浏览器提供隔离，但不需要帧间通信。

windows策略没有为mashup提供保护，因为集成商的窗口包含不受信任的小工具。提供恶意gadget的gadget攻击者确实控制了诚实积分器窗口中的一帧，使攻击者获得了安装一个小玩意劫持攻击。¹⁴恶意的小工具可以导航目标小工具到attacker.com并向用户模拟这个小工具。例如，iGoogle在Firefox 2等实现了许可或窗口策略的浏览器中容易受到gadget劫持;看到图2．考虑一个iGoogle小工具，它允许用户访问他们的Hotmail帐户。如果用户没有登录Hotmail，这个小工具会请求用户的Hotmail密码。恶意工具可以将Hotmail工具替换为并窃取用户的Hotmail密码。与跨窗口攻击一样，用户无法区分恶意密码字段和诚实密码字段。

3.4.更严格的政策

尽管浏览器供应商没有记录他们的导航策略，我们对现有浏览器的策略进行了逆向工程表2)．除了允许策略和窗口策略，我们还发现了另外两个策略:

Internet Explorer 6团队希望在默认情况下启用子策略，但却提供了允许策略，因为子策略与大量网站不兼容。Internet Explorer 7团队设计了后代策略，以平衡安全需求(以击败跨窗口攻击)和兼容性需求(以支持现有站点)。¹⁸

为了选择在安全性和兼容性之间提供最佳权衡的框架导航策略，我们诉诸于的原则像素代表团。当一个帧嵌入一个子帧时，父帧将屏幕的一个区域委托给子帧。浏览器阻止子帧绘制到它的边界框之外，但允许父帧使用位置:绝对的风格。帧导航攻击取决于攻击者升级他或她的特权，并利用屏幕上其他无法访问的区域。后代策略是最允许的(因此也是最兼容的)策略，它防止攻击者覆盖“属于”另一个源的屏幕不动产。尽管子策略比后代策略更严格，但增加的严格并不能提供显著的安全好处，因为攻击者可以通过绘制子框架所占据的屏幕区域来模拟导航子框架的视觉效果。然而，子策略增加的严格性降低了该策略与现有站点的兼容性，使浏览器供应商不愿部署该子策略。

最大化后代策略的兼容性需要考虑浏览器的脚本策略。考虑一个站点，它嵌入了来自第二个原点的两个子帧。这些子帧是否应该被允许导航它的兄弟帧?严格地解释，后代策略禁止这种导航，因为目标帧是兄弟帧，而不是后代帧。但是，这种导航应该是允许的，因为攻击者可以通过在兄弟帧中注入一个脚本来执行导航，从而导致帧自己进行导航。浏览器允许攻击者注入这个脚本，因为这两个帧来自同一个原点。更一般地说，浏览器可以通过识别来最大化后代策略的兼容性起源传播如果目标帧是与活动帧同源的帧的后代，则让活动帧导航到目标帧。通过这种方式定义，框架导航策略避免了创建子起源特权。¹¹这种增加的权限不会牺牲安全性，因为攻击者可以间接地执行相同的导航，但是精细化的策略对诚实的Web开发人员更方便。

我们与HTML 5工作组合作⁹并在HTML 5规范中标准化了后代策略。ie7、Firefox3、Safari 3.1和谷歌Chrome浏览器均支持该策略。我们还报告了Flash Player中的一个漏洞，可以用来绕过Internet Explorer 7的帧导航策略。Adobe在一次安全更新中修复了此漏洞。

回到顶部

4.帧通信

与简单的聚合器和广告不同，复杂的mashup包含相互通信的gadget以及与它们的集成器通信的gadget。例如，Yelp集成了谷歌Maps小工具，说明了在实际部署中需要安全帧间通信。谷歌提供了两个版本的地图小工具:

框架:在框架版本中，积分器将框架嵌入到maps.google.com，其中谷歌显示指定位置的映射。用户可以与映射交互，但积分器不能。
脚本:在脚本版本中，积分器嵌入了一个<脚本>运行JavaScript的maps.google.com．该脚本创建了一个丰富的JavaScript API，集成商可以使用它与映射交互，但是该脚本使用集成商的所有特权运行。

颇受欢迎的点评网站Yelp使用谷歌Maps小工具来显示餐馆和其他商家的位置。Yelp需要与地图小工具高度的交互性，因为它在每个餐厅的地图上放置标记，并在用户单击标记时显示该餐厅的评论。要实现这些高级功能，Yelp必须使用地图小工具的脚本版本，但这种设计要求Yelp完全信任谷歌地图，因为谷歌的脚本使用Yelp的特权运行，这使谷歌有能力操纵Yelp的评论并窃取Yelp的客户信息。尽管谷歌可能是值得信任的，但脚本方法不能扩展到非常受尊敬的小工具提供者之外。帧间安全通信保证了这两种选择的最佳效果:具有Yelp等功能的网站可以实现谷歌地图小工具脚本版本的交互性，同时保持小工具帧版本的安全性。

4.1.片段标识符消息传递

尽管浏览器的脚本策略隔离了来自不同来源的帧，但聪明的mashup设计师发现了帧之间意想不到的通道，片段标识符消息传递，^1，21这是由浏览器限制较少的框架导航策略控制的。这种“发现”技术允许mashup开发人员将每个gadget放在单独的框架中，并依靠浏览器的安全策略来防止恶意gadget攻击集成器和诚实的gadget。我们在分析之前分析使用中的片段标识符消息传递，并提出已经采用的改进。

机制:通常，当一个框架被导航到一个新的URL时，浏览器会从网络请求这个URL，并用检索到的内容替换框架的文档。但是，如果除了片段(#后面的部分)之外，新的URL与旧的URL都匹配，那么浏览器就不会重新加载框架。如果帧[0]目前位于http://example.com/doc，

在不重新加载帧或破坏其JavaScript上下文的情况下改变帧的位置。帧可以通过轮询读取它的片段window.location.hash看看片段是否发生了变化。这种技术可以用来在帧之间发送消息，同时避免网络延迟。

安全性能:片段标识符通道的安全属性不太理想。浏览器的脚本策略防止其他源监听消息，因为它们无法这样做读帧的位置(即使导航策略允许它们写帧的位置)。浏览器还可以防止任意源篡改消息的部分内容。但是，其他安全源可以覆盖整个片段标识符，让接收方猜测每个消息的发送方。

为了理解这些安全属性，我们将其与众所周知的网络通道属性进行类比。我们认为浏览器保证片段标识符通道具有机密性:消息只能由预期的收件人读取。然而，片段标识符通道不是安全通道，因为它缺乏安全通道身份验证:接收方不能明确地确定消息的发送方。攻击者可能能够使用浏览器的重放以前的消息历史API。

片段标识符通道类似于不可信网络上的通道，其中每条消息都使用预期接收方的公钥加密。在这两种情况下，当Alice向Bob发送消息时，除了Bob以外没有人知道消息的内容(除非Bob转发消息)。在这两种设置中，通道都没有提供确定是谁发送了给定消息的可靠过程。片段标识符通道和公钥通道之间有两个关键区别:

公钥通道容易受到流量分析的影响，但攻击者无法确定通过片段标识符通道发送的消息的长度。攻击者可以通过轮询浏览器的时钟来提取计时信息，但是获取高分辨率的计时信息会降低性能。
片段标识符通道受浏览器的帧导航策略的限制。原则上，这可以用来构造对片段标识符通道安全的协议，而对公钥通道不安全(通过阻止攻击者导航接收方)，但在实践中，这一限制并没有阻止我们构造对现有实现的攻击。

尽管有这些差异，我们发现网络类比在分析帧间通信时很有用。

Windows Live频道:微软在其Windows Live平台库中使用片段标识符消息传递来实现更高级别的通道API，Microsoft.Live.Channels．²¹Windows Live Contacts小工具使用这个API与它的集成商通信。积分器可以指示小工具从用户联系人列表中添加或删除联系人，小工具可以向积分器发送用户联系人的详细信息。每当积分器要求gadget执行敏感操作时，gadget会要求用户确认操作并显示积分器的主机名，以帮助用户做出信任决策。在我们分析之前，Microsoft.Live.Channels使用协议向片段标识符通道添加身份验证。通过逆向工程实现，我们确定库使用以下协议来建立安全通道:

在这种符号中，一个而且B帧,N_一个而且N_B是新鲜的nonces(每次运行协议时随机选择的数字)和URI_一个是一个的框架。在上述网络类比下，该协议类似于经典的Needham-Schroeder公钥协议。¹⁷Needham-Schroeder协议旨在通过不安全通道在双方之间建立共享秘密。Windows Live不像Needham-Schroeder协议那样使用加密，而是依靠片段标识符通道来提供机密性。

尼德姆-施罗德公钥协议有一个众所周知的异常，这是由洛提出的，¹⁵这会导致浏览器设置受到攻击。在Lowe场景中，诚实的负责人Alice与不诚实的一方Eve发起协议。然后伊芙让诚实的鲍勃相信她就是爱丽丝。为了利用洛维异常，一个诚实的主体必须愿意与一个不诚实的主体启动协议。在mashup中可以满足此需求，因为在初始化mashup时，集成者使用小工具攻击者的小工具启动协议。可以利用Lowe异常模拟gadget的积分器:

在这四个消息之后，攻击者就拥有了N_我而且N_G并且可以模拟小部件的积分器。我们已经针对Windows Live Contacts小工具实现了这种攻击。对于Contacts小工具来说，这种异常尤其成问题，因为它在安全用户界面中向用户显示集成商的主机名(参见图3)．

保护片段标识符消息传递:可以使用Needham-Schroeder-Lowe协议的变体来保护通道。¹⁵正如Lowe对原始协议的改进，我们建议在协议的第二条消息中包含响应者的身份，让诚实的发起者检测到攻击并中止协议:

我们联系了微软、OpenAJAX联盟和IBM，了解他们的片段标识符消息传递协议中的漏洞。微软和OpenAJAX联盟已经采纳了我们的建议，并在其库的更新版本中部署了上述协议。IBM采纳了我们的建议并修改了他们的SMash¹⁴纸。

4.2.postMessage

HTML 5¹⁰指定用于帧间异步通信的新的浏览器API。与片段标识符消息传递不同，postMessage为跨源通信而设计。的postMessageAPI最初是在Opera 8中实现的，现在Internet Explorer 8、Firefox 3、Safari 3.1和谷歌Chrome都支持API。我们在API的早期版本中发现了一个漏洞，后来通过我们建议的修改消除了这个漏洞。要向另一个帧发送消息，发送方调用postMessage方法:

在接收方帧中，浏览器生成一个消息事件，其中包含消息、发送方的原点(方案、主机和端口)以及对发送方帧的引用。

安全性能:的postMessage通道保证了身份验证，消息可以准确地识别发送者，但是通道缺乏保密性。因此,postMessage与片段标识符消息传递几乎具有“相反”的安全属性。的postMessage通道类似于不可信网络上的通道，其中每个消息都由其发送方以加密方式签名。在这两种设置中，如果Alice向Bob发送消息，Bob可以明确地确定Alice发送了消息。与postMessage,起源属性标识发送方;使用加密签名，签名可以识别签名者。通道之间的一个区别是加密签名可以很容易地重播，但是postMessage抵抗重放攻击。

攻击:我们发现了一次侵犯机密的攻击postMessage通道。因为一个信息的发送postMessage是针对帧的，攻击者可以通过将帧导航到attacker.com在浏览器生成消息事件:

递归Mashup攻击:如果积分器调用postMessage在包含在框架中的gadget上，攻击者可以在框架中加载积分器，并通过将gadget框架(攻击者的框架的后代)导航到来拦截消息attacker.com．当积分器调用时postMessage在“gadget的”框架上，浏览器将消息传递给攻击者(参见图4)．
回复:假设积分器使用起源决定是否回复消息事件:

攻击者可以通过在浏览器生成密钥之前导航源帧来拦截密钥消息事件。这种攻击即使在子帧导航策略下也可以成功，如果诚实的小工具通过top.postMesage(…)．攻击者的gadget可以嵌入一个帧到诚实的gadget，并在积分器回复“gadget的”帧之前导航诚实的gadget(参见图5)．

确保postMessage:虽然网站可能能够使用原始的建立一个安全的通道postMessageAPI，我们推荐使用postMessage提供保密性。在MashupOS,²²我们之前提出帧间通信api应该让发送方指定预期接收方的来源。同样，我们建议扩展postMessage带有第二个参数的API:targetOrigin．浏览器将传递消息只有在帧的当前原点与指定的匹配targetOrigin．如果发送方使用“*”作为targetOrigin，浏览器将把消息传递到任何原点。使用这个改进的API，帧可以使用以下习惯用法回复消息:

我们将这个API更改作为Firefox和Safari的补丁实现。我们的建议被HTML 5工作组接受了。⁸改进后的API现在可在Internet Explorer 8、Firefox 3、Safari 4和谷歌Chrome中使用。

回到顶部

5.相关工作

5.1.设备劫持的缓解措施

粉碎¹⁴通过仔细监视帧层次结构和浏览器事件以防止意外导航，减轻gadget劫持(也称为“帧钓鱼”)。尽管集成商和小工具都不能阻止这些导航，但如果mashup检测到非法导航，它可以警告用户并拒绝运行。SMash会等待一个gadget加载20秒，然后假定该gadget已被劫持。攻击者可能能够欺骗用户在此间隔内输入敏感信息，但使用较短的间隔可能会导致网络连接较慢的用户收到虚假警告。后代政策使这种减缓成为不必要的。

5.2.HTML和JavaScript的安全子集

避免基于框架的mashup的安全问题的一种方法是通过将gadget和集成器组合到一个文档中来避免使用框架。这种方法放弃了浏览器安全策略提供的保护，并要求gadget使用HTML和JavaScript的“安全子集”编写，以防止恶意gadget攻击集成器或其他gadget。有几种开源实现(FBML、ADsafe和Caja)可用。FBML是目前最成功的子集，被Facebook平台所使用。

5.3.子空间

在子空间,¹³我们使用了多层层次的框架来协调他们的document.domain属性直接在JavaScript中通信。与大多数基于框架的mashup类似，后代框架导航策略是必需的，以防止gadget劫持。

5.4.模块标签

被提议的<模块>标签²类似于< iframe >标记，但是模块运行在无特权的安全上下文中，没有主体，而且浏览器阻止集成器在模块之上覆盖内容。不像postMessage的通信原语<模块>标记显式未进行身份验证，因为模块缺少主体。

5.5.安全=限制和监禁

Internet Explorer浏览器支持安全属性¹⁶为帧。当设置为限制，该框架的内容不能运行JavaScript。同样，拟议的<监狱>标签⁵包含不可信的内容，防止被监禁的内容运行JavaScript。不幸的是，消除JavaScript会阻碍gadget提供交互体验。

5.6.MashupOS

在MashupOS,²²我们为隔离和通信提出了新的原语。我们的改进框架导航政策和postMessage让开发人员在使用现有浏览器时意识到MashupOS的一些好处。

回到顶部

6.结论

结合来自多个来源的内容的Web站点可以利用浏览器框架隔离和帧间通信。尽管浏览器的同源安全策略限制了帧之间的直接访问，但最近的浏览器使用了不同的策略来规范一个帧何时可以导航另一个帧。最初的允许框架导航策略允许一些攻击，而后续的窗口导航策略使mashup容易受到类似的攻击。更好的后代策略，我们与HTML 5工作组合作进行了标准化，平衡了安全性和兼容性，已被Internet Explorer 7(独立)，Firefox 3, Safari 3.1和谷歌Chrome采用。

在现有的浏览器中，帧导航可以通过一种称为片段标识符消息传递的技术用于帧间通信。如果直接使用，片段标识符消息传递缺乏身份验证。我们展示了使用的身份验证协议Windows.Live.Channels、SMash和OpenAjax 1.1都容易受到攻击，但可以通过类似于Lowe的Needham-Schroeder协议变体的方式进行修复。¹⁵微软Windows Live、IBM Smash、¹⁴以及OpenAjax联盟。

最初,postMessage(另一个帧间通信通道)则存在相反的漏洞:使用帧导航，攻击者可能会破坏机密性。我们建议延长postMessageAPI通过让发送方指定预期的接收方来提供机密性。我们的建议已经被HTML 5工作组、Internet Explorer 8、Firefox 3、Safari 4、谷歌Chrome和Opera采纳。

通过这些改进，框架提供了更强的隔离和更好的通信，成为集成第三方Web内容的更有吸引力的功能。未来工作的一个重要领域是提高浏览器安全用户界面的可用性。例如，允许gadget导航顶层框架，将用户从mashup重定向到攻击者选择的站点。尽管浏览器的位置栏使导航变得明显，但许多用户忽略了位置栏。未来工作的另一个领域是改进针对浏览器实现错误的隔离，这可能会让gadget破坏浏览器的安全机制。

回到顶部

致谢

我们感谢Mike Beltzner、Sumeer Bhola、Dan Boneh、Gabriel E. Corvera、Ian Hickson、Koji Kato、Eric Lawrence、Erick Lee、David Lenoe、David Ross、Maciej Stachowiak、Hallvord Steen、pelius Uhley、Jeff Walden、Sam Weinig和Boris Zbarsky的有益建议和反馈。这项工作得到了美国国家科学基金会和美国国土安全部的资助。

回到顶部