无脚本攻击 - 在不触碰窗台的情况下偷取馅饼(半机翻有删增)

由于其高实际影响，跨站点脚本（XSS）攻击引起了安全社区成员的广泛关注。同样，提出了过多或多或少有效的防御技术，解决了XSS漏洞的原因和影响。因此，攻击者通常无法在多个现实场景中注入甚至执行任意脚本代码。

在本文中，我们研究了在XSS之后仍然存在的攻击面，并且通过阻止攻击者执行JavaScript代码来减少类似的脚本攻击。我们解决了攻击者是否真的需要JavaScript或类似功能来执行针对信息窃取的攻击的问题。令人惊讶的结果是 ，攻击者还可以滥用层叠样式表（CSS）与其他Web技术（如纯HTML，非活动SVG图像或字体文件）一起使用 。通过几个案例研究， 我们引入了所谓的无脚本攻击 ，并证明攻击者可能不需要执行代码从受到良来好保护的网站中提取敏感信息。更确切地说， 我们表明攻击者可以使用看似良性的功能来构建侧通道攻击 ，以测量和泄露给定网站上显示的几乎任意数据。

我们在本文结束时讨论了针对此类攻击的潜在缓解技术。此外，我们还实施了一个浏览器补丁，使网站能够做出关于在分离视图或弹出窗口中加载的重要决定。这种方法证明对于防止我们在此讨论的某些类型的攻击很有用。

介绍

在Web 2.0技术和云计算时代，我们可以使用丰富的强大在线应用程序。这些Web应用程序允许诸如在线银行，在线商店发起商业交易，撰写可能包含敏感信息的电子邮件，甚至在线管理个人医疗记录等活动。因此，很自然地想知道保护此类数据需要采取何种措施，特别是在安全和隐私问题方面。

突出的现实攻击向量是跨站点脚本（XSS），一种注入攻击 ，其中攻击者将恶意脚本注入到其他良性（和可信）网站 。具体来说，XSS为攻击者提供了在脚本的帮助下跨不同站点操作Web页面的选项。对于这种攻击，JavaScript通常被用作选择的语言;一旦恶意脚本执行，它就可以完全访问属于受信任网站的所有资源（例如，cookie，身份验证令牌，CSRF令牌）。由于其高实际影响，XSS攻击和相关的浏览器安全研究近年来引起了安全界的广泛关注。

通过防止代码的可执行性来防止XSS

根据上述发展和公布的工作，已经提出了许多或多或少可行的防御技术。所有这些尝试都有一个明确的目标：停止XSS攻击。通常，可以说如果攻击者设法在目标域上执行JavaScript，那么她可以控制受害者导航的整个网页。因此， 建议的缓解策略是出于安全原因停用/限制JavaScript代码执行 ，使用NoScript ，内容安全策略（CSP）等工具，或者使用HTML5-sandboxed iframe。 如果应用程序可以在没有外部JavaScript的情况下运行，那么这种方法是合理的， 而现代Web 2.0应用程序并不总是如此。此外，一个网站增强了其健壮性并提升了防御攻击的保护级别(这种行为的一个例子是破坏框架的代码，以减轻经典的点击劫持攻击).结果，限制或禁用JavaScript同步禁用上述保护机制。

回过头来看，我们注意到XSS攻击需要满足三个保证其成功的先决条件：

1.可注射性：攻击者必须能够将数据注入Web浏览器呈现的文档对象模型（DOM）中

2.可执行性：如果注入了JavaScript（或任何其他代码），则必须执行它。

3.穿透能力： 攻击者获取的数据必须传递到另一个域或资源，以便进一步分析和利用。

事实上，XSS最近取代了 SQL 注入和相关的服务器端注入攻击，成为OWASP排名中的头号威胁，这表明许多Web应用程序都满足了这三个前提条件。如上所述， 针对XSS的若干当前缓解方法集中于第二前提条件 ，主要是因为 可注入性通常是许多Web2.0应用中的期望特征 。鼓励互联网用户通过DOM越来越多地使用DOM来贡献不同Web应用程序之间的内容和数据交换。因此，服务器端和客户端XSS过滤器尝试从注入的内容中删除脚本，或者，他们尝试以不在浏览器的DOM中执行的方式修改/替换这些脚本。典型的建议是：如果我们成功地防止注入JavaScript被反射或执行，可以认为Web应用程序可以抵御XSS攻击。

请注意，浏览器的呈现引擎通常用于其他工具，例如电子邮件客户端或即时消息程序，以显示HTML内容。默认情况下，在这些类型的软件中禁用脚本以防止在电子邮件处理或即时消息传递的上下文中发生XSS等攻击。同样，防御方法是通过防止第二个前提条件发生来缓和攻击。

超越基于脚本的攻击

在本文中，我们通过在实践中检查来评估限制脚本内容是否足以用于减轻攻击。我们提出攻击者实际上需要JavaScript（或其他语言）来执行XSS攻击的问题。我们在整篇论文中使用的攻击模型如下。 首先，我们假设前提条件1仍然满足 ，这在如上所述的现代Web应用程序中是合理的。 其次，我们假设脚本完全禁用，因此我们可以确定XSS攻击不起作用，因为不能满足可执行性的前提条件 （即，不会执行JavaScript内容）。前提条件3由绝大多数Web应用程序授予，因为需要进行大量工作以确保应用程序本身阻止对任意外部域的HTTP请求。

值得注意的是， 这种攻击模型可以让攻击者将任意标记（如层叠样式表（CSS）标记）注入网站 。我们表明CSS标记（传统上被认为仅用于装饰/显示目的）实际上使攻击者能够执行恶意活动。更准确地说， 我们证明了攻击者可以将CSS与其他Web技术结合使用，例如非活动SVG图像，字体文件，HTTP请求和普通非活动HTML，这些都可以实现类似JavaScript的部分行为。 因此，攻击者可以从指定站点窃取敏感数据，包括密码。对于这项工作，我们的运行示例是一个Web应用程序，其中包含用于输入信用卡信息的表单。我们介绍了几种我们称之为无脚本攻击的新型攻击， 因为攻击者可以通过向此页面注入标记来获取信用卡号，而无需依赖任何类型的（JavaScript）代码执行 。我们提出了几种概念验证无脚本攻击，其复杂程度越来越高，说明了我们技术的实际可行性。

所讨论的攻击都不依赖于受害者的用户交互，而是使用良性HTML，CSS和Web开放字体格式（WOFF）功能的组合，结合基于HTTP请求的侧通道来测量和渗透几乎任意网站上显示的数据。

必须强调的是，旨在防止XSS的传统服务器和客户端防御机制（如HTMLPurifier，NoScript或其他几种经过测试的XSS过滤解决方案）尚未完全准备好应对我们的无脚本攻击。这主要是因为我们不依赖于注入脚本或执行代码。

作为进一步的贡献，我们提出了针对这种新型攻击的新保护机制。由于攻击媒介的过滤可能会影响网站的常规内容，因此我们专注于消除可以执行提议的攻击的条件，从根本上防止对攻击者服务器的请求。我们已经实现了一个浏览器补丁，它为网站提供了一个能力，可以确定它是在分离视图还是弹出窗口中加载。这种方法证明对于防止某些类型的无脚本攻击和其他攻击向量是有用的。

贡献

总之，我们在本文中做出以下三点贡献：

• 我们描述了一种攻击面，该攻击面是由现代Web应用程序中不受信任内容的脚本功能划分而产生的。我们将展示攻击者如何在严格受限的执行环境中部署恶意代码。我们将此类攻击标记为无脚本因为它们不需要执行（JavaScript）代码。

• 我们讨论了几个新颖的攻击向量，这些向量足够复杂，可以从给定的网站中提取敏感数据（我们的运行示例涉及获取信用卡号），这样做无需执行脚本代码 。攻击利用一系列良性特征，这些特征组合在一起会产生导致数据泄漏的攻击向量 。我们证明了专有功能以及W3C标准化浏览器功能可用于连接无害功能，以充当强大而强大的侧通道攻击。 所描述的攻击涉及跨站请求伪造（CSRF）和保护CSP ，它们适用于泄漏给定网站上显示的几乎任意数据。 此外，我们将Web和SVG字体识别为强大的工具，用于帮助攻击者从注入的网站获取和泄露敏感数据。 我们已经为所有攻击实施了概念验证示例。

• 我们详细阐述了针对无脚本攻击的现有防御机制，特别是指内容安全策略（CSP）等保护技术。遗憾的是，我们还确定了基于CSP的保护方面的差距，并涵盖了X-Frame-Options标题在无脚本攻击方面的局限性。此外，我们引入了一个新的浏览器功能，我们已经为Firefox浏览器实现了一种补丁形式，有助于减轻无脚本攻击。作为额外的结果，此功能还可以帮助缓解其他几种攻击技术，例如双击顶点和拖放攻击。

攻击面和场景

在过去几年中，随着许多新的复杂技术的引入，防止对Web应用程序的攻击，成功攻击的标准得到了显着提升。我们推测这主要是由于大量已发布的漏洞利用，与HTML5相关的技术的兴起，以及非浏览器环境中HTML使用的日益普及，即浏览器的渲染引擎被广泛使用诸如Pidgin和Skype等即时通讯工具，Outlook，Thunderbird和Opera Mail等电子邮件客户端，娱乐硬件和软件以及最终操作系统（如Windows8）等环境。因此，所有这些环境都需要保护基于HTML的攻击。这导致了许多防御方法的稳步发展。另外值得注意的是，安装NoScript等安全扩展的用户数量正在增长：NoScript通过简单地禁止JavaScript执行来阻止对网站用户的大范围攻击。因此，针对Web应用程序的攻击变得更加困难，并且部署最新防御技术的网站已经可以抵抗大量攻击媒介。

鉴于所有这些防御策略， 我们希望攻击者能够发展为在渲染上下文中起作用的技术，这些上下文不允许脚本执行或严重限制已执行脚本的功能 。

例如， HTML5建议将沙盒的iframe用于不受信任的内容 ;这些本质上限制了脚本执行，直到完全阻止它，它们将成为未来Web应用程序的关键信任令牌。因此可以想到一个非常基本的问题：对手是否仍然可以在这种受限制的环境中执行恶意计算？

一个持续可行的攻击场景是开发通过（ab） 使用看似良性的特征并将它们连接成实际攻击向量来跨域检索和泄漏数据的技术 。我们假设这些情景在未来将变得重要，因为上面讨论的一些防御技术继续增长。此处引入的攻击基于这种“可注入”的精确方法和目标系统，但 它们无法执行任何JavaScript（或其他语言）代码 。因此， 我们称我们的方法无脚本攻击 。在创建这些攻击期间，我们的目标是实现类似于传统XSS攻击的数据泄漏。

以下列表简要描述了在浏览器或类似浏览器的软件中使用HTML的一些场景，但出于安全和/或隐私原因，JavaScript受到限制或完全禁用。我们的攻击技术针对这些情况，因为即使在如此严格受限的环境中，无脚本攻击还是能导致信息泄露

1.HTML5 Iframe 沙箱:

HTML规范描述了一种功能，该功能允许网站构建任意数据，而不会使其执行脚本和类似的活动内容。 只需应用具有沙箱属性的iframe元素即可调用所谓的iframe沙箱 。默认情况下，沙箱是严格的，并阻止执行任何活动内容，表单功能，定位不同视图和插件容器的链接。可以通过向该属性内容添加以空格分隔的值来放宽限制。因此，使用这些设置，开发人员可以例如允许编写脚本但禁止访问父框架，允许表单功能或允许弹出窗口和模式对话框。虽然沙盒的iframe目前仅在Google Chrome和Microsoft Internet Explorer中可用，但我们预测它们会被广泛采用，因为所述功能会出现在HTML5规范中。早期版本的Internet Explorer中提供了标记为安全限制的iframe的沙盒Iframe的简化版本，例如在MSIE 6.0中。

2.内容安全策略 (CSP):

内容安全策略是一种提议且积极开发的隐私和安全工具。具体来说，它可以在Mozilla Firefox和Google Chrome浏览器中使用。 CSP的目的是基于HTTP头和元元素限制所讨论的网站的内容使用;例如，开发人员可以指示用户代理忽略内联脚本，跨域资源，事件处理程序，插件数据以及Web字体等可比较资源。在第4节中，我们将讨论当前状态下的CSP如何帮助减轻第3节中引入的攻击。

3.NoScript和类似的脚本拦截器：

NoScript是由Maone，G组成和维护的相当流行的Firefox扩展。除了与此工作无关的几个功能之外， NoScript的目的是阻止访问过的网站上的不受信任的脚本内容。

通常，除了少数可信的默认来源之外的所有脚本和内容源都被阻止。特定用户可以临时或以永久方式决定是否信任内容源并启用它。

NoScript属于我们的研究范围：我们试图绕过其保护并获得执行恶意代码的能力，尽管它存在。让我们强调，无脚本攻击已被证明对此目的非常有效。

4.客户端 XSS 过滤器

多个用户代理提供集成的XSS过滤器。这适用于Microsoft Internet Explorer和Google Chrome以及安装了NoScript扩展程序的Firefox 。我们的无脚本攻击旨在绕过这些过滤器并执行恶意代码 ，尽管它们存在。在几个例子中，我们能够实现我们的目标，尽管过滤器检测到攻击并阻止脚本执行反应。

5.电子邮件客户端和即时消息：

如上所述，浏览器的布局引擎通常不是浏览器本身专用的，因为诸如电子邮件客户端和即时消息程序之类的多个 工具 同样使用可用的HTML呈现引擎来实现其目的。 Mozilla Thunderbird可以作为一个具体的例子来讨论。默认情况下，在此类软件中禁用脚本： 允许在邮件正文中使用JavaScript甚至插件内容的电子邮件客户端可能会导致严重的隐私隐患 。因此，无脚本攻击为攻击者提供了执行恶意代码的潜在方式。

总之，有很多攻击场景，其中攻击者无法执行脚本，或者受到执行脚本功能的严重限制。

超越基于脚本的攻击

在本节中，我们将讨论在调查与无脚本攻击相关的攻击面时我们开发的攻击的技术细节。正如我们将看到的，无脚本攻击可以提供一个可行的解决方案，然而在上一节中描述的上下文中渗透和窃取敏感信息，绕过许多可用的防御解决方案，例如沙盒Iframe，脚本阻止程序（即NoScript）或客户端XSS过滤器。对于本文的其余部分，我们假设攻击者具有以下功能：

1.攻击者可以将任意数据注入浏览器呈现的DOM中

例如Webmail应用程序中的HTML邮件正文。对于鼓励用户贡献内容的现代Web 2.0应用程序，这是一个可行的假设。此外，根据OWASP排名，XSS攻击被列为头号威胁这一事实表明许多Web应用程序中存在注入漏洞。

2.我们假设脚本完全禁用

例如，我们的用户安装了NoScript或类似的防御解决方案，防止攻击者进行代码注入和后续执行。请注意，传统的XSS攻击在此设置中是不可行的，因为无法执行JavaScript（或任何其他语言）内容。

我们借助处理信用卡号的简单Web应用程序来说明我们的攻击

它可以与亚马逊网上商店或应用了适合处理或委托信用卡交易的后端的类似网站进行比较。此Web应用程序允许我们在概念验证场景中演示我们的攻击向量。我们专门选择了信用卡号码处理，因为它们只包含16位数字，例如4000 1234 5678 9010.这使我们能够在短时间内泄露信息。请注意，我们的操作也适用于其他攻击情形，我们将举例说明如何使用我们的方法窃取CSRF令牌和其他类型的敏感信息。此外，我们实现了一个 无脚本键盘记录程序 ，允许远程攻击者捕获在网页上输入的击键，即使禁用了JavaScript（此漏洞也被跟踪为CVE-2011-匿名化）。

攻击组件

以下各节中描述的攻击利用了现代用户代理中可用的几种标准浏览器功能，并在HTML和CSS3规范草案中定义。在继续演示它们如何组合以构成工作攻击向量之前，我们列出并简要解释这些功能。 更具体地说，我们展示了如何滥用合法的浏览器功能来泄露内容或建立功能性的侧通道以从Web浏览器获取特定信息。

我们发现以下浏览器功能是构建攻击的有用构建块：

1.基于SVG和WOFF的Web字体：

HTML和CSS规范建议浏览器供应商为不同的Web字体格式提供支持。

其中包括可缩放矢量图形（SVG）字体和Web开放字体格式（WOFF）。我们的攻击使用这些字体并利用其功能来改变显示的网站内容的属性。 SVG字体允许攻击者轻松修改字符和字形表示，更改单个字符的外观以及使其维度多样化。可以简单地使用诸如宽度之类的属性来通过分配“零宽度”来确保某些字符没有尺寸，而其他属性可以具有不同的且受攻击者控制的尺寸。 WOFF结合CSS3允许使用称为自由连字或上下文替代的特征。通过为WOFF字体指定那些，几乎任何长度的任意字符串可以由单个字符表示（再次给出用于最终测量目的的不同尺寸）。

2.基于CSS的动画：

使用基于CSS的动画，可以随着时间的推移更改各种CSS和DOM属性，而无需使用任何脚本代码。允许通过CSS动画进行更改的属性由规范标记为可动画。

例如， 攻击者可以使用CSS动画来更改包含敏感信息的DOM节点周围的容器的宽度或高度。

通过能够缩放容器，可以强制所包含的内容以特定方式对尺寸变化作出反应。一种反应是断线或溢出容器。如果这些行为是可测量的，动画可能会根据特定行为的计时参数导致信息泄漏。

3.CSS内容属性：

CSS允许使用名为content的属性来提取任意属性值，并在所选元素之前，之后或之后显示值。属性值提取可以由属性值函数的use attr触发。对于此功能的良性用例，请考虑以下情况：开发人员希望通过在显示链接后简单地呈现href属性的内容来显示其网站上所有或所选链接的链接URL，但仅限于绝对链接网址。通过使用以下CSS代码，这是可行的：

a[href^=http://]:after{content:attr(href)}

此强大功能 还可用于提取敏感属性值，如CSRF令牌，密码字段值和类似数据 。随后，可以在属性上下文之外使它们可见。将提取的信息与字体注入相结合，可提供强大的测量杆和侧通道。实际上，这种组合构成了第3.2节和第3.3节中讨论的攻击的重要方面。

4.CSS媒体查询

CSS Media Queries为网站开发人员提供了 一种部署依赖于设备的样式表的便捷方式 。用户代理可以使用媒体查询来例如确定访问网站的设备是否具有视口宽度大于300像素的显示器。如果是这种情况，将部署针对更宽屏幕优化的样式表。否则，将选择针对智能手机和通常较小的屏幕和视口进行优化的样式表。清单1中显示的示例代码说明了一般技术;如果访问部署此CSS代码段的网站的设备的视口宽度大于400像素，则背景变为绿色;如果屏幕仅允许较小的视口宽度，则背景将为红色。

请注意，这些不同的组件都是浏览器中的合法和良性功能。只有在组合时，它们才会被滥用以建立辅助渠道并衡量给定网站的特定方面。

使用Smart Scrollbars进行基于测量的内容渗透

最初，我们决定将我们的分析重点放在基于Webkit的浏览器上，因为这个浏览器布局引擎已经广泛部署。其中包括谷歌Chrome和Safari，这反过来意味着我们涵盖台式电脑，笔记本电脑，iPhone和iPad，以及各种Android浏览器，Blackberry和Tablet OS设备。

Webkit项目作为开源运行，以非常短的开发周期和快速实现新的W3C和WHATWG功能建议而闻名。除了这些指定和推荐的功能外，Webkit还提供了各种非标准功能，这些功能仅在使用此特定布局引擎的浏览器中提供。

其中一项专有功能使攻击者能够提供棘手的攻击，对允许提交用户生成的样式的网站起作用。可以提取网站显示的几乎任意信息，包括信用卡号，元素维度等文本内容，甚至HTML/XHTML属性值，例如用于保护非幂等HTTP请求的CSRF令牌。一旦使用3.1节中描述的CSS内容功能，后者就成为可能。

我们开发了一个能够提取CSRF令牌详细信息的演示漏洞;举一个例子，测试显示读取32个字符的CSRF令牌需要少于100个HTTP请求。

如上所述，CSRF令牌被希望保护可能有害的GET请求的网站使用。如果攻击者可以发现链接以启动对存储项的修改，则可以通过从其他浏览器导航选项卡向该链接发出HTTP请求来完成损害。一个不可思议的链接(应用了长而加密的安全令牌)可以防止这种攻击。必须知道令牌才能成功执行请求。在允许攻击者执行任意JavaScript的攻击场景中，通过简单的DOM遍历到其中一个受保护链接并随后利用侧通道将令牌发送到域外位置以便以后重新使用，很容易提取令牌。但是在我们的攻击场景中，攻击者无法执行JavaScript，因此令牌提取和泄露（除了使用开放的textarea元素和表单提交之外）很复杂。

Vela等人在2009年使用属性选择器创建了一个示范性的 重载CSS属性读取器 。不幸的是，这种方法不适合读取高熵32+字符的CSRF令牌。

为了实现纯粹的基于CSS的数据泄露攻击，我们利用3.1节中列出的所有可用功能，另外将它们与专有Webkit功能之一相结合。 以下概述介绍了我们从初始CSS注入转移到敏感CSRF令牌的完整堆栈数据泄漏的步骤：

• 攻击者注入一个包含一组CSS选择器和一个font-face声明的样式元素。这些CSS选择器选择CSRF令牌保护链接（CTPL）及其容器元素。 font-face声明导入一组经过精心准备的SVG字体：对于可出现在CSRF令牌中的每个字符，都会导入一个字体文件。除导入的字体外，任何其他字符的宽度均为零。每个具有宽度的字体的单个特定字符应用具有独特宽度值。

• CSS动画块与前面提到的CSS一起注入。此动画以CTPL的容器为目标，并将其从初始大尺寸缩小到特定的最终尺寸。确定最终尺寸至关重要;攻击者需要找出动画停止泄漏有关收缩容器所包含内容的信息的正确像素大小。

• 注入的CSS包含由CTPL的:: before伪选择器嵌入的内容属性。此内容属性应用值attr（href）。

  因此，攻击者可以将href属性的值映射到DOM并使其可见。通过这样做，可以应用注入的SVG字体。对于每次出现的CTPL，都可以选择不同的SVG字体。在第一个选定的链接中，将选择仅为字符a提供维度的字体。对于第二个CTPL出现，将选择仅为字符b提供维度的字体，依此类推。接下来，所有CTPL都可以使用单独的字体，而连接到指定字体的字符的所有CTPL都将没有任何维度。最后，包含由所选字体标注的字符的所有CTPL将具有以像素为单位的字符宽度×出现的维度。

• 通过将CTPL的容器元素的框大小从100％减小到一个像素，攻击者可以唤起一个有趣的行为：该框对于CTPL来说太小了，因此应用维度的字符将突破到下一行。如果该框具有不同的高度且没有水平溢出属性，则会出现滚动条。滚动条出现的那一刻构成攻击者在本地确定正在使用的字符的开口：特定的SVG字体，零宽度字符和通过像素精确动画强制减少框大小的滚动条就足够了。

最终，攻击者可以在本地确定角色是否具有唯一的尺寸，因此存在于CTPL中。无法远程确定此角色的唯一障碍是缺少适用于滚动条的反向通道。没有标准化的方法将背景图像或类似属性应用于滚动条。

Webkit - 所有其他经过测试的浏览器布局引擎中的例外 - 提供此功能。开发人员可以选择窗口或HTML元素滚动条的任何组件，并应用几乎任意的样式。这包括框阴影，圆角边框和背景图像。但是，我们的调查显示，页面加载后会直接请求典型的滚动条背景图像。因此，该属性对于定时目的和侧通道的开发似乎是无趣的，所述侧通道获得关于出现时间或纯粹存在的信息。尽管如此，对Webkit可用伪类和状态选择器的进一步研究揭示了一种工作方式，即将滚动条状态与背景图像结合使用，以实现实际定时和测量攻击。若干状态选择器允许分配背景图像，并且基于该事实，必须实际发生特定状态（诸如影响滚动条轨道的背景的递增滚动）。此时，后台将在进入此CSS选择状态时加载，而不是在页面加载时加载。这允许对手确实使用滚动条外观的测量来进行定时和侧通道数据泄漏。

清单2中显示的CSS代码示例演示了一个能够作为辅助通道工作的状态选择器。

在我们基于Webkit滚动条功能的测试期间，确定敏感内容只需几秒钟。如果执行CSS动画，受害者不一定会注意到恶意性质。

我们在http：// html5sec上创建了一个公共测试用例。

org / webkit / test在Google Chrome开发团队负责任地披露问题后，展示了这种侧向引导攻击。为了缓解这种攻击，我们建议平等对待滚动条背景和滚动条状态背景;应在页面加载期间加载所有背景图像和类似的外部资源，而不是在外观或状态发生时加载。这两个方面创建了一个攻击窗口，允许侧面信道攻击和外观探测可用于泄漏敏感数据和页面参数，如上文所述的攻击所示。

将一般攻击技术与在受攻击网站上显示信用卡号的运行示例相连接，注入的字体将为信用卡号的每个数字组提供一个连字。要创建包含强制信用卡号码所需的所有可能数字组的WOFF字体，需要不超过9,999或999,999个不同的连字数量，具体取决于信用卡制造商。然后，每个数字组将具有不同的宽度，因此可以通过确定在缩小尺寸的动画过程期间何时出现滚动条来确定该数字组。我们在示例场景中成功测试了这种方法，发现我们可以可靠地确定和泄露这些信息。

使用滚动条检测和媒体查询进行内容渗透

在我们研究Webkit特定滚动条数据泄漏功能的过程中，我们尝试开发一种技术，可以通过标准化功能在任何其他浏览器中完成类似的结果。此外，提取单个字符可能会成为一项持久的任务，对于有效的针对性攻击而言并非最佳。因此，我们的目标是继续研究具有更大影响的攻击技术，与上面提到的相当具体的“智能滚动条”方法相比，总体上更有效，更通用。请注意，如果不深入了解攻击面和可能的影响，以及所涉及的特征和对手，第4节中讨论的有效防御即使不是不可能也是复杂的。

我们利用前面提到的部署CSS媒体查询的技术来提升基于滚动条的数据泄漏，使其适用于所有现代浏览器。它还有助于分离核心问题，从一个小的实现怪癖转变为代表一个实际的基于设计的安全问题。如3.1节所述，媒体查询允许确定设备的视口大小。

基于此判断过程，他们部署了各种最有可能优化的CSS文件和规则。要让滚动条成为数据泄漏问题的来源，如3.2节中的上述攻击所述，攻击者需要找出滚动条出现的时间和原因。更具体地说，攻击者可以调整元素直到特定点，并使用滚动条来确定元素是否包含具有不同值的某个其他元素或文本节点。如果滚动条存在与否，CSS Media Queries将帮助推出实际部分。以下步骤演示了如何使用CSS Media Queries检测滚动条存在的详细信息：

• 一个网站部署了一个嵌入另一个网站的Iframe。恶意准备的CSS注入是此嵌入式网站的一部分。 iframe设置为100％的宽度，因此填充整个嵌入窗口的宽度 - 特征。 iframe的高度可以设置为任意值，具体取决于应泄漏的数据。

• 嵌入网站设置为特定宽度。这将确保，如果Iframe的宽度为100％，嵌入式站点将遵循该宽度并相应地设置其视口尺寸。框架/嵌入式网站使用注入的CSS媒体查询来部署两个状态。第一个状态使用与嵌入页面几乎相同的宽度。考虑宽度为430px的框架视口，然后框架网站的第一个媒体查询将侦听设备视口宽度为400px。第二个CSS媒体查询现在将侦听设备视图端口宽度为390px。请注意，一旦Iframe仅将宽度减小十个像素，400px的媒体查询将不再匹配。同时，应激活第二个媒体查询并部署其指定的样式，包括背景图像请求等。

• 下一步，嵌入注入站点的Iframe的高度将会改变。这可以通过CSS动画和特定于Webkit的信息泄漏，在托管Iframe的网站上运行的脚本，或者在攻击者生成弹出窗口或在编辑模式中显示的Iframe的情况下手动调整大小来执行;如果主机站点在编辑模式下显示Iframe，则单击并拖动操作将完成调整大小（考虑用于社交工程的浏览器游戏场景）。

CSS动画仍然是最不可能不需要任何用户交互的情况。一旦Iframe的高度降低，大小更改将强制其内容换行。就其本身而言，这条断开线将生成一个垂直滚动条，该滚动条由注入的溢出行为或简单的窗口默认值强制执行。

滚动条将占用大约10-15个像素，从而将视口大小从400减小到390或更小的像素宽度。这将触发第二媒体查询并且可以显示背景图像，并行地泄漏换行的确切位置和时间，滚动条外观以及由此包含的信息的宽度和性质。这最终确定了攻击，并将上述功能与CSS Media Queries的组合分类为另一个潜在的信息泄漏。图1中的屏幕截图说明了这种情况。

同样，我们在 http://html5sec.org/scrollbar/test上创建了一个公共测试用例，以演示滚动条存在的无脚本确定。要启动测试，必须首先调整窗口的大小，然后以将其下边界拖向上边界的方式手动减小高度。请注意，这当然可以跨域自动完成。

要将此攻击技术与我们的运行示例相结合，我们只需使用缩小大小的弹出窗口或iframe来确定何时可见内容大小被削弱并导致滚动条出现。此时，整体视图大小也将减小，并通过让CSS媒体查询通过（例如）背景图像发起HTTP请求来引起侧信道的出现。请注意，这次我们不需要利用定时攻击：媒体查询CSS提供有关滚动条出现的像素宽度的详细信息。将该信息与替换信用卡号的上下文连字的已知不同宽度相结合，可以产生详细且精确的侧通道攻击。

使用上下文替代建立字典字体

为了加快在注入的网站上识别和确定特定字符串和子字符串的过程，攻击者可能需要大量不同的字体和请求。上述攻击样本被描述为能够从注入的网站中提取单个字符。为了提高效率，攻击者可以使用SVG和WOFF字体提供的自由选择或上下文替代。通过注入包含数十万个字符串组合的字典的跨域字体，可以大大加快检测过程。

注意，每个字符串表示的字符信息可以是小的：字体使用矢量图形，并且提供不同宽度的检测特征所需的全部可以由包括两个单个点的路径包含。在一个大小为1兆字节的单个字体文件中，攻击者可以存储大量依赖于所表示字符串性质的上下文备选方案。对于数值的数据泄漏（例如，为了能够泄漏信用卡号或类似信息），攻击字体的尺寸可以更小并且仍然容易发现并表示信用卡号包括的单个块。创建攻击字体所需的工具可免费提供给合法使用;用于创建包含字典的SVG字体，简单的文本编辑器就足够了。将字体压缩为SVGZ（压缩SVG）格式以优化大小需要简单的gzip实现。对于编辑和滥用WOFF字体， http://fontforge.sourceforge.net/上提供的免费和开放textttFontForge工具可以很容易地使用。

我们的研究结果表明，字体注入可能会对未来的攻击格局产生积极影响。

虽然CSP和NoScript默认防止跨域字体注入，但我们需要监视公共字体API的使用。这是因为它们可能被滥用并提供攻击字体，绕过基于白名单的过滤器和保护工具。

通过这样做，他们将破坏用户对Google W ebFonts和TypeKit等提供商的信任，这两者都是免费的Web字体部署服务。

缓解技术

在本节中，我们将分析现有的攻击缓解技术，以确定网站所有者和开发人员可以在多大程度上防范无脚本攻击。承认无脚本攻击的广泛可能性（本出版物仅讨论了两种可能更多的攻击变体），我们得出结论，需要多层保护才能有效地和整体地防御基于CSS，SVG和HTML的数据泄漏。

内容安全策略(CSP)

CSP最初由Mozilla开发，现在由W3C Web应用程序安全工作组指定为草案。 CSP的主要目标是通过将至少一个域确定为脚本代码的有效源来缓解跨站点脚本等内容注入漏洞。要实现这一目标，可以使用frame-src或sandbox等指令。举一个例子，在frame-src的情况下，可以让支持用户代理检查哪些帧可以嵌入到网站中。因此，可以在可控制的网站上获得关于允许内容的精细粒度。因此，CSP能够减少恶意代码注入攻击的潜在有害影响。请注意，CSP认为任意样式，内联CSS和Web字体都可能有害，因此提供了匹配规则。

在我们的无脚本攻击环境中，最好限制基本先决条件，以防止网页（或更确切地说是用户）受到攻击。因此，我们分析了针对我们在本文中介绍的攻击的给定CSP指令。首先，我们发现W3C草案的几乎所有指令，除了用于报告策略违规的指令报告 - uri，都有助于防止网站及其用户受到攻击者的影响。指令default-src强制用户代理执行 - 除了一个例外 - 草案的剩余指令以及指令值的给定默认源。在详细了解default-src影响指令之前，重要的是要知道CSP无法检测到带有脚本或样式表代码的纯注入到易受攻击的Web页面中。因此，只能阻止从外部资源加载的文件的内容。

这导致能够阻止外部文件中包含的恶意内容。看看我们的攻击表明，至少使用CSP的style-src和img-src来进一步减少攻击面是有意义的。通过使用stylesrc指定受保护Web页面的样式，可以限制对不需要的CSS文件的访问。因此，用于读取DOM节点的基于CSS的动画或CSS内容属性的使用在这种情况下将不再用作攻击工具。这同样适用于img-src;如前所述，SVG文件可用于执行无脚本攻击和拦截事件，击键和类似的用户交互，而无需使用脚本技术。

因此，建议从其他站点（尤其是其他域）阻止SVG文件，以实现更高级别的安全性。基于我们的示例攻击，我们还建议使用frame-src来限制嵌入帧的资源以及用于限制外部字体源的font-src。

一旦通过限制外部文件资源来提高安全性的可能性已经明确，我们将留下以下考虑：可以限制受保护站点内可能的攻击向量吗？当我们使用sandbox作为不受default-src控制或设置的指令时，就是这种情况。它根据HTML5沙箱属性值限制可用内容。因此，该指令可用于例如停用脚本的执行;因此，基于JavaScript的攻击将无法运行。什么不被认为是危险的是无脚本代码。在我们的例子中，如果遇到典型的脚本攻击，沙箱会很有帮助。

总之，我们得出结论，CSP是朝着正确方向迈出的一小步和有益的一步。它特别有助于消除可用的侧通道以及一些攻击向量。在我们在第1节中描述的攻击模型中，CSP因此有助于减轻前提条件1并消除前提条件3.然而，它不足以完全覆盖各种无脚本攻击。我们建议的是增加CSP设置的范围，以便至少有一个选项禁止执行样式表或 - 甚至更好 - 选择样式表属性。

CSP的报道还有一件事仍然存在：与点击劫持相关的行为。我们在3.3节中讨论的滚动条检测依赖于弹出窗口，以防被攻击的网站使用帧破坏程序。与可用的帧检测和破坏功能相反，现代浏览器中没有可靠的方法来实现弹出窗口和分离视图的相同安全性。因此，在4.2节中，我们提出了针对无脚本攻击和类似威胁的其他保护机制。

检测分离视图

我们在第3节中描述的一些攻击可以通过使用Iframe和类似的内容框架技术来利用。然而，通过简单地使用适当的X-Frame-Options标头，网站可以轻松部署防御性测量。知道这种防御技术的攻击者已经开始利用不同的方式利用弹出窗口和分离视图来完成数据泄漏攻击，甚至点击劫持攻击，而不受帧破坏代码和X-Frame-Options的影响头。

其中一些攻击已在双击劫持标签下进行了记录，而其他技术则涉及将活动内容（如applet）或复制和粘贴操作拖放到跨域的可编辑内容区域中。由于扩展的攻击面，我们要强调的是，就现代浏览器而言，网站没有可行的方法来确定它是否在分离的视图中加载相应的弹出窗口。

为了解决这个问题，我们为最新版本的Web浏览器Firefox（Nightly14.0a1，截至2012年4月提供）创建了一个补丁，提供了一种可能的解决方案来防止所描述的攻击。该补丁通过两个附加属性扩展了众所周知的DOM窗口对象：isPopup和loadedCrossDomain。这两个属性都由布尔值表示，任何网站都可以随时以只读方式访问。正如命名已经暗示的那样，只有当前DOM窗口对象表示的实际GUI窗口是分离视图时，window.isPopup才为真。同样，仅当跨域加载当前DOM窗口对象时，window.loadedCrossDomain才为true。

这些功能使网站能够使用简单的JavaScript代码检查自己的状态。

随后，在不安全的情况下，可以采取适当的对策。例如，网站可以通过限制自身以跨域方式或在iframe内部加载到分离视图中来保护自己免受第3节中描述的攻击。虽然后者已经可以在现代浏览器中开箱即用（通过将X-Frame-Options标题设置为SAMEORIGIN或DENY），但前者不能。幸运的是，我们可以通过Firefox浏览器的自定义扩展轻松实现，如下面的清单3所示。

该补丁包含C++类nsGlobalWindow和nsWindowWatcher以及Firefox代码库的nsIDOMWindow和nsIWebBrowserChrome接口中的更改。虽然isPopup属性可以通过检查某个已存在的内部窗口标志直接实现，但loadedCrossDomain属性的引入需要额外的代码。每当网站尝试打开新窗口时，此代码会将调用网站的URI的主机名与要加载的网站的主机名（包括端口）进行比较。如果主机名不同，则设置新引入的内部标志以指示此条件，反之亦然，在相反情况下未设置此标志。因此，如果Firefox浏览器重用已存在的弹出窗口以在弹出模式下显示新网站，则loadedCrossDomain属性也会正确更新。

允许网站确定是否在分离视图中加载，可以立即缓解多种攻击技术。这包括上述几种无脚本攻击，双击劫持，拖放以及多次复制和粘贴攻击。我们计划与不同的浏览器开发团队讨论这个补丁，并评估几种浏览器如何采用这种技术来保护用户免受攻击。

其他防御技术

无脚本的攻击可能发生在过多的变化中，并且通常基于其他良性特征的恶意连接。到目前为止，我们已经详细阐述了如何加强浏览器并为网站所有者提供新的杠杆，以最小的努力加强他们的应用程序。此外，我们通过为图像，字体，CSS和其他资源定义严格的原始策略，通过从不同来源请求数据来潜在地导致信息泄漏，从而阐明了CSP如何帮助防止无脚本攻击。

Zalewski等。讨论了2011年无脚本攻击的另一个方面，指向悬空开放标签，更具体地说，用于数据泄漏的按钮，文本区域和半开图像src属性等元素。这些攻击简单而有效，需要Web应用程序和最终的HTML过滤技术来应用语法验证并强制执行用户生成的（X）HTML内容的语法有效性。开放的textarea可以轻松地将网站的其余部分转换为其自己的内容，从而泄露敏感数据和CSRF令牌。请注意，通过将点击坐标发送到跨域的任意接收器，即使是图像映射和类似的弃用技术也可用于无脚本数据泄漏。除了前面提到的保护技术和机制之外，经典的HTML内容和语法验证与Zalewski创造的同样重要，它可以防止“后XSS世界”中的攻击。请注意，这是一个类似于我们在本文中检查过的攻击者模型。消除侧通道而不是攻击向量对于解决该特定问题同样更重要。

相关工作

安全社区的成员已经对Web应用程序的攻击给予了很多关注。我们现在将回顾这一领域的相关工作，并讨论无脚本攻击的新方面和贡献。

历史嗅探

从概念的角度来看，基于CSS的浏览器历史嗅探与我们的工作密切相关。该技术使对手能够确定用户过去访问过哪些网站。多年来，历史嗅探记录在几个浏览器错误报告中。该方法已用于不同的攻击场景。在一项实证研究中，Jang等人发现几个热门网站实际上使用这种技术来泄露有关访问者浏览行为的信息。鉴于此攻击媒介的普遍存在，最新版本的常见Web浏览器已实施某些防御措施，以保护用户免受基于CSS的历史嗅探。

我们也使用CSS作为攻击的一部分，但我们不使用历史嗅探背后的实际概念。更具体地说，我们演示了攻击者如何滥用基于CSS的动画，CSS内容属性和CSSMedia查询来访问和收集特定信息。

因此，我们的攻击也会对最新版本的流行Web浏览器起作用。必须要注意的是，虽然许多记录的历史嗅探攻击在使用JavaScript来泄露数据时明显更快，但这些攻击也可以仅基于CSS实现，而且没有活动脚本代码，这反过来又根据我们的定义将它们区分为无脚本攻击。

时间攻击

Felten和Schneider在网络安全的背景下提供了一种更为一般的历史嗅探攻击形式，他分析了与资源是否被缓存相关的时序差异。在类似的攻击中，Bortz和Boneh展示了如何实现定时攻击以从Web应用程序中恢复私人信息。最近，陈等人。展示了与流行网站相关的不同侧通道泄漏，并且还基于时序信息。在其他领域，定时攻击是一种完善的技术，用于从许多不同类型的系统（例如，OpenSSL，SSH 或虚拟机环境）中泄露信息。

虽然定时测量被用作本文所述的攻击的一部分，但我们利用其他类型的定时攻击，并使用此一般概念来确定Web浏览器上下文中的特定信息。

客户端和服务器端XSS检测或预防

由于其高实用率，XSS攻击已被专门的大量研究所涵盖。我们现在将简要讨论发现和防止此类攻击的不同客户端和服务器端方法。请注意，由于其不同的基本原则，它们在无脚本攻击的情况下的有效性受到限制。

贝茨等人研究能够阻止XSS的客户端过滤方法。他们在noXSS，NoScript和IE8 XSS过滤器中发现了缺陷，并且发 现一些攻击向量仅在XSS过滤后被激活。与其他方法相比，它们倾向于将XSSAUDITOR放在HTML解析器和JavaScript引擎之间。但是，这种设计不会阻止无脚本攻击，因为它们不针对JavaScript引擎。

Curtsinger等提出了一个名为ZOZZLE的浏览器扩展，用于对带有贝叶斯分类的恶意JavaScript代码进行分类。如果这种基于学习的防御机制能够对抗无脚本攻击，那么这仍然是一个悬而未决的问题

Pietraszek等人介绍了上下文敏感的字符串评估（CSSE），这是一个通过依赖一组元数据来检查传入的用户生成数据字符串的库

根据从附加元数据派生的上下文，正在应用不同的过滤和转义方法来保护现有应用程序。这种低级方法被描述为对现有应用程序可操作，几乎不需要应用程序开发人员实施。

Kirda等。提出了一个名为Noxes的客户端XSS预防工具。通过防止浏览器联系不属于Web应用程序域的URL，此工具可防止攻击者将敏感数据泄露给其服务器。从概念的角度来看，这种方法也可以用来限制对手可以通过无脚本攻击实现的目标，因为它可以防止侧通道泄露被盗信息。此外，作者根据攻击者可以选择的编码和混淆技术的多种方式，详细阐述了服务器端XSS检测和预防的难点。以类似的方式，我们认为无法在服务器端阻止无脚本攻击。

吉姆等人。引入了浏览器强制嵌入式策略（BEEP)，这是一种策略驱动的浏览器扩展，能够控制某个脚本是否可以执行。

更具体地说，BEEP使用户能够将合法脚本列入白名单并禁用网页的某些区域的脚本。整个概念代表了CSP的另一个基础。 Nadji等人。提出了类似的方法：文档结构完整性（DSI）确保动态内容与服务器端的静态内容分离，而两者在客户端以完整性保留方式组合。

Louw和Venkatakrishnan的蓝图遵循类似的方法：服务器端应用程序将内容编码为模型表示，可以由工具的客户端部分处理。

Saxena等介绍了ScriptGuard，一种上下文敏感的XSS卫生工具，能够自动进行上下文检测和一致的卫生例程选择。请注意，所有这些方法都侧重于防止代码脚本，这意味着无脚本攻击可能会绕过这种保护机制，因为我们不使用动态内容。

Heiderich等。发布了由SVG图形绕过现代HTML清理程序引起的XSS漏洞以及在浏览器恶意软件和复杂的跨上下文脚本攻击的情况下基于DOM的攻击检测。

Martin和Lam 以及Kieyzun等人引入了能够自动生成针对Web应用程序的XSS和SQL注入攻击的工具。 XSSDS 是一个通过比较HTTP请求和响应来确定攻击是否真正成功的系统。在最近的论文中，提供了发现参数注入和参数篡改漏洞的不同方法。这些类型的工具尚不可用于自动发现和创建无脚本攻击，尽管我们期望可以识别类似的概念并将其应用于将来适当一致的工具开发。

总结和展望

在本文中，我们介绍了一类针对Web应用程序的攻击，我们将其称为无脚本攻击。这些攻击的关键属性是它们不依赖于JavaScript（或任何其他语言）代码的执行。相反，它们完全基于现代用户代理中可用的标准浏览器功能，并在当前的HTML和CSS3规范草案中定义。在某种程度上，这种攻击可以看作是基于CSS的历史偷窃和类似攻击向量的概括。我们讨论了几种对无脚本攻击有用的浏览器功能，包括攻击者可以访问信息或建立辅助通道的各种方式。此外，我们针对示例性Web应用程序提出了几种无脚本攻击，并演示了攻击者如何通过滥用合法的浏览器概念成功获取敏感信息，如CSRF令牌或用户输入。此外，我们还发现攻击者还可以泄露特定信息并建立使这种攻击可行的辅助渠道。

虽然本文中讨论的攻击可能并不代表非法检索敏感用户数据的全部方法，但我们认为我们讨论的攻击组件对其他攻击媒介非常重要。因此，详细分析和进一步详细阐述与可能的防御机制有关的调查可能会产生更多的攻击媒介。我们希望本文能够刺激针对不依赖于JavaScript代码执行的Web应用程序的攻击。

作为另一个贡献，我们引入了一个浏览器补丁，使网站能够确定它是否在分离视图或弹出窗口中加载，展示了针对多种攻击的缓解技术。在我们未来的工作中，我们将研究更多处理和防止无脚本攻击的方法。