ACM通信

研究突出了

跨渠道脚本的出现

作者:Hristo Bojinov, Elie Bursztein, Dan Boneh
ACM通讯，2010年8月，Vol. 53 No. 8, 105-113页
10.1145/1787234.1787257
评论

轻量级、嵌入式Web服务器的数量很快就会超过常规的Internet Web服务器。它们驻留在承载个人和公司数据的设备中，通常用于配置和管理。我们揭示了一系列针对消费电子产品和小型办公电子产品的攻击，从网络存储到数码相框。这些攻击以Web服务器逻辑为目标，并基于一种新的漏洞类型，我们称之为跨通道脚本(XCS)。XCS是一种复杂的跨站脚本(XSS)形式，通过不同的协议进行攻击注入和执行。

回到顶部

1.简介

当前的消费类电子设备通常附带用于系统管理的嵌入式Web服务器。提供基于web的用户界面的好处有两方面:首先，用户不需要学习复杂的命令行语言，其次，供应商不需要提供客户端软件。相反，用户通过熟悉的浏览器UI与设备进行交互。市场数据证实了基于浏览器的设备管理模式的成功:即使只考虑网络连接存储(NAS)和数字相框产品，嵌入式Web服务器在数量上也有望超过互联网上的通用Web服务器(图1)．

尽管基于浏览器的设备管理是一种经济有效且方便的方法，但由于薄弱的Web应用程序中存在大量潜在漏洞，它可能会带来相当大的安全风险。此外，由于支持大量网络协议以及它们之间的交互，保护消费类电子设备上的Web应用程序可能很困难。例如，用户可以通过SMB协议将文件上传到网络存储设备，通过Web界面管理文件的权限，最终通过FTP与朋友共享文件。在嵌入式系统上运行的软件和它们存储的任何状态的整体不透明性进一步增加了安全风险，因为它有效地阻止了安全产品扫描这些系统，并报告正在进行的漏洞或攻击。

在这个复杂的环境中，许多嵌入式设备容易受到Web攻击是不足为奇的。事实上，我们评估的23种设备^3.容易受到多种类型的Web攻击，包括跨站脚本(XSS)，⁵跨站请求伪造(CSRF)^2，12和许多其他人。

回想一下，在Type 1(反射的)XSS攻击中，用户跟随一个恶意链接到受害站点。站点中的漏洞导致将攻击脚本嵌入到产生的HTTP响应中。然后，该脚本可以接管页面并代表攻击者执行任意操作。类型2(持久)XSS使攻击者能够将恶意脚本注入受害者站点的持久存储中。当不知情的用户查看包含该脚本的页面时，该脚本可以接管该页面。例如，2型跨站可以影响留言板;攻击者可以发布一条包含脚本的消息，该脚本随后由碰巧查看攻击者发布内容的每个用户的浏览器执行。最近的一个此类攻击的例子是XSS Twitter蠕虫病毒，它在2009年4月中旬袭击了Twitter。¹³

跨渠道脚本:我们研究的许多嵌入式设备都容易受到一种我们称之为持久XSS的类型的攻击跨渠道脚本,或者我。在XCS攻击中，使用非Web通道(如SNMP或FTP)注入持久的XSS漏洞，该漏洞在用户连接到Web界面时被激活。例如，我们研究的几种NAS设备允许攻击者通过SMB上传几乎任意文件名的文件。攻击者利用这种缺乏限制的特点，制作一个包含恶意脚本的文件名。当NAS管理员通过Web界面查看NAS内容时，设备愉快地向管理员的浏览器发送一个HTTP响应，其中包含包括恶意文件名在内的文件名列表，然后浏览器将其解释为脚本。该脚本在管理员的浏览器上执行，使攻击者能够完全控制管理员会话。在第3节中，我们将介绍我们发现的最有趣的XCS攻击。

我们还发现了一类相关的攻击，其中使用Web漏洞来攻击非Web通道。我们称之为相反的我脆弱性。我们在第4节中给出了例子。

与传统的Web站点相比，XCS和反向XCS更有可能影响嵌入式设备，因为这些设备通常提供许多服务(例如，Web、SNMP、NFS、P2P)，这些服务是由通用组件拼凑在一起的。组件之间的交互可能没有被完全分析，从而导致XCS漏洞。相反，许多Internet Web站点只提供Web界面，因此不太可能受到XCS的影响。有趣的是，大型Web站点，如Facebook和Twitter，为提供XCS机会的第三方应用程序提供非Web云api，如第5节所讨论的。

检测XCS或反向XCS漏洞可能很困难，因为这些攻击会滥用Web界面和备用通信通道之间的交互。仅仅检查Web应用程序代码和其他服务代码不足以检测漏洞。Web应用程序和其他服务(如FTP服务器)可以在隔离的情况下完全安全，只有在同时使用时才容易受到攻击。

XCS漏洞可以用于执行各种攻击，包括

• 漏出敏感数据，例如nas保护的文件或用户的击键
• 重定向用户到一个驾车下载的网站¹⁰或者钓鱼网站
• 利用用户的IP地址为DDoS⁹或者代理攻击者的流量

在消费电子设备上，利用XCS可以成为对用户局域网进行更大规模攻击的一个跳板，该攻击旨在将家庭机器同化为僵尸网络⁴或者侵入用户的公司网络。例如，反向XCS可以用来重新启动交换机，从而关闭整个局域网。

组织:在本文的其余部分，我们将更详细地定义XCS，然后介绍真实世界的XCS攻击并讨论它们的影响。然后，我们介绍了反向XCS的概念，并给出了实践中的实例。通过展示如何使用基于Restful api的RXCS来攻击非常流行的Web站点，我们还展示了反向XCS是一种通用的强大攻击。最后，我们简要介绍了对XCS的防御，并请读者参阅我们的原始论文以获得更详细的讨论。

回到顶部

2.跨渠道脚本简而言之

XCS攻击是一种使用非Web通道将脚本注入到在不同的安全上下文中运行的Web内容的攻击。

XCS攻击包括两个步骤，如图2．在第一步攻击者使用非web通道(如FTP或SNMP服务)在服务器上存储恶意JavaScript代码。在第二步中，恶意内容被发送到受害者通过Web应用程序。一旦受害者通过浏览器访问恶意内容，就会按照她的权限执行。虽然XCS利用是一种持久的(类型2)XSS，但我们认为应该根据两个原因区分这两者。

首先，XCS漏洞很难检测到，因为它们涉及到多种协议。用于检测XSS的静态分析器(如Pixy⁸)不会检测到XCS，因为它们的污染分析假设用户输入存储在全局变量中。由于存在大量可能的受污染数据源，使用污染分析方法检测XCS是很困难的。例如，对于PHP，除了显而易见的文件()和其他文件相关函数，还需要考虑许多其他特定于协议的函数。这包括读取数据的每个SNMP函数，例如snmpget（），函数()列出一个FTP目录，当然还有返回结果集的数据库函数，例如mysql_fetch_object()。即使正确列举了所有函数，假警报的数量也会非常多。目前对静态分析的研究显示出在不久的将来改善这种状况的希望。¹

第二，在输入时清理数据的XSS防御不太可能防止XCS。这些机制主要应用于从Web流量中获取的数据，而在XCS中，攻击矢量是通过非Web通道呈现的，这不大可能消除Web漏洞。这种检测和防止XCS漏洞的困难解释了为什么我们检查的每个嵌入式设备都能够发现XCS问题。

回到顶部

3.真实的我

我们提出了四个案例研究，阐述了流行的嵌入式设备和移动电话中不同类型的真实世界XCS漏洞。第一个示例使用文件传输协议(如FTP)将脚本注入持久存储，第二个示例使用P2P网络，第三个示例将脚本注入日志文件。最后一个例子使用日历协议渗透Palm Pre。

3.1.一个两阶段的XCS漏洞

NAS设备是一种轻量级服务器，为网络上的其他设备提供数据存储服务。低端NAS市场非常活跃，有超过50家供应商提供产品，包括苹果，布法罗，戴尔，莱西,连系。由于NAS设备需要通过网络进行管理，因此大多数供应商为此目的在其中构建了Web服务器。NAS设备本身就支持多个接口，因此是利用XCS的主要候选者。此外，快速添加新功能的市场压力(例如，P2P文件下载和RSS流量)为实现疏忽提供了大量机会，这些疏忽将变成XCS漏洞。我们评估了来自不同知名供应商的5个NAS设备，并在所有设备中发现了多个XCS漏洞。五款产品均支持FTP和CIFS (SMB)文件传输协议。

我们所研究的三个产品都遭受了最普遍的XCS攻击:创建的文件具有专门设计的文件名，以包含恶意负载，当管理员使用Web界面查看NAS内容时将执行该负载。在图3，管理员刚刚访问了某个共享存储，攻击者在其中植入了一个具有特殊设计名称的文件。因此，浏览器不是显示文件的名称，而是执行一个脚本来访问限制来自管理员会话的存储区域，但没有得到他或她的批准(精心设计的攻击脚本也会掩盖其踪迹，显示管理员期望的目录内容)。

攻击的第一步是向NAS注入有效负载，攻击者在此上传带有恶意文件名的文件。可以使用公共目录将文件上传到NAS(通常默认配置公共FTP目录)。由于FTP和SMB协议的两个限制，通过文件传输协议注入负载有点棘手:

1. 文件名有长度限制。
2. 文件名不能包含'/'，因此我们不能在其中嵌入HTML结束标签。因此，不可能直接加载外部脚本。

为了克服第二个限制，我们使用"JavaScript包装:我们编码(打包)我们的第二阶段有效负载，使用HTML转义，所以打包的字符串不包含一个'/'，我们使用第一阶段(unpacker)写入HTML页面。例如，针对其中一个设备，我们使用了以下两级有效负载:

第一阶段(unpacker)通过避免使用脚本脚本< > < / >运行JavaScript代码。相反，我们使用iframe的onload事件在iframe加载后立即执行代码。当HTML编码不足以构建可接受的第二阶段有效负载时，我们使用JavaScripteval ()执行更复杂的编码。

要避免文件名长度限制，有两种可能的方法。第一种方法是通过从Internet上的外部脚本加载完整的exploit来保持第二阶段有效负载较短。我们能够在三种设备上使用这种方法:在所有情况下，远程脚本调用都符合必要的长度限制。尽管如此，通过配置防火墙阻止从NAS到外部网络的请求，可以防止这种方法(尽管这可能会干扰NAS上的软件更新过程)。克服文件名长度限制的第二种方法是将第二阶段的漏洞简单地跨越多个文件名。每个文件名包含第二级有效载荷的一个编码片段。第一步负载用于读取所有文件名并重新组合负载。

NAS XCS攻击可能是有害的。例如，攻击者可以注入一个恶意文件名，当被NAS管理员查看时，该文件名将接管管理员的浏览器会话。这可以用来窃取NAS上受保护的文件，窃取管理员的密码，或用恶意软件感染管理员的机器。

3.2.XCS来自P2P通道

另一个NAS产品在其P2P (Peer-to-Peer)特性中隐藏了一个更微妙、可能更强大的XCS漏洞。该设备允许用户通过提供嵌入式客户端直接下载BitTorrent文件。这个客户机是通过备用端口(8080)上可用的Web界面控制的:例如，用户可以通过提供来添加种子.torrent文件。BitTorrent文件基本上是一个要下载的文件列表，以及用于查找对等点的散列和跟踪器url。

为了利用XCS漏洞，攻击者构造了一个torrent文件，该文件包含一个文件名，充当恶意负载。一旦用户下载了torrent文件，Web界面就会显示torrent中的文件列表，导致浏览器执行嵌入在恶意文件名中的有效负载(如图4)．

更详细地说，这次袭击，在图5，收益如下:

步骤1:攻击者创建一个.torrent它包含一个受欢迎的电影和一个附加文件，该文件的文件名中会有恶意负载。

步骤2:攻击者种子并上传.torrent像海盗湾这样的热门追踪网站。这使得攻击者可以访问超过1400万的潜在受害者。

步骤3:在torrent名称的诱惑下，许多用户将获取.torrent一旦在NAS Web界面中打开，攻击者就会获得对浏览器会话的控制。

在这种攻击中，在获取种子之前，用户无法知道种子中包含恶意负载。种子名称本身是完全合理的，没有任何东西来警告用户，它包含一个恶意文件。

一旦洪流被取走，攻击就开始了。此外，由于种子实际上包含了真实的电影，如果有效载荷足够隐蔽，用户可能永远不会知道发生了感染。

3.3.基于我

熄灯管理系统:当操作系统崩溃或损坏时，管理员通常需要本地访问控制台以重新启动或重新配置计算机。这种情况出现在数据中心和个人计算机上，管理员必须走到损坏的机器前进行诊断并重启它。物理干预的需要是有问题的，特别是当有服务水平协议时，因为它大大增加了停机时间。为了解决这个问题，所有主要的硬件供应商都开发了称为熄灯管理系统(LOM)的固件组件，无论机器上的软件有多坏，管理员都可以远程访问这些组件。LOM可以在服务器、台式机和笔记本电脑上找到(每台使用英特尔Core2芯片组的电脑都有一个，以英特尔vPro技术的形式)。大多数板载网卡提供Web界面，管理员可以通过Web界面远程管理计算机。

LOM漏洞:我们检查了4个广泛使用的LOM系统上的Web界面，并在所有系统上发现了几个XCS漏洞。我们注意到，LOM网站无法被操作系统或在其上运行的任何软件(如IDS、防火墙或杀毒软件)监控或过滤，这使得这些漏洞更加复杂。(这样做的原因是为了防止配置错误的操作系统禁用LOM系统，因为这将破坏LOM的目的。)LOM安全机制:供应商采取各种安全措施，防止非法访问LOM系统。这些措施包括使用SSL来防止网络攻击、几种形式的用户身份验证以及大量记录用户活动。具有讽刺意味的是，正是日志记录工具和Web界面之间的交互导致了我们所发现的最糟糕的XCS示例。这种攻击几乎适用于两个不同供应商的产品，只需访问受影响系统上的Web界面就可以实现。不需要经过身份验证的会话。

滥用伐木设施:这个XCS使用了日志注入⁶将脚本注入到设备上的持久存储中。攻击原理如下:

步骤1:攻击者试图登录被管理机器提供的LOM Web站点。他输入了一个恶意的有效负载作为用户名，而不是试图猜测登录。例如，恶意负载可能首先关闭将用户名作为参数传递的函数调用，然后关闭当前脚本标记，最后注入从远程URL获取的攻击者脚本的调用。整个序列非常紧凑:

步骤2:日志记录功能将这个用户名原样记录到机器上的LOM日志文件中。尽管可以通过Web界面查看日志文件，但日志记录功能不会转义写入日志文件的数据以防止Web攻击。

步骤3:当LOM管理员查看日志时，恶意负载将由浏览器执行。可以使用恶意负载将非法管理员帐户添加到LOM，从而授予攻击者完全访问权。攻击者还可以通过将浏览器指向恶意网站来感染管理员的计算机。¹⁰

对戴尔远程访问控制器的这种XCS攻击的结果显示在图6其中映像被注入到管理页面。

3.4.Cellphone-based xc

XCS攻击不仅限于Web管理界面。现代智能手机平台，如谷歌的Android和Palm的WebOS，使用HTML和JavaScript构建应用程序视图。以Palm Pre为例，整个GUI是在Webkit基础上使用JavaScript和HTML构建的。考虑到这些优雅的设备支持的服务和协议的数量，XCS是一个重要的问题。事实上，最近的一份报告显示⁷显示Palm Pre易受XCS攻击，XCS通过日历标题或内容注入其有效载荷。

回到顶部

4.反向XCS:数据导出和超越

一个相反的我attack使用Web界面最终攻击非Web通道。这类攻击的主要应用是窃取不应该共享的数据，这些数据要么是受访问控制机制保护的，要么是根本不应该共享的。

我们使用两个真实世界的漏洞来演示反向XCS。第一个是利用嵌入在相框中的网络服务器，从SD卡上盗取照片。第二种方法结合了XCS和反向XCS，通过P2P网络从NAS中提取受保护的数据。

4.1.相框里的幽灵

一家大型消费设备供应商构建的相框在端口5050上有一个嵌入式Web服务器，并带有默认密码。与我们评估的大多数嵌入式设备一样，相框容易受到CSRF和XSS攻击。更准确地说，在设置页面中，可以使用帧名输入来注入和存储一个非转义的有效负载:我们的“鬼”。鬼影会反射在显示当前照片的相框主页面上，并提供更改它的控件。

图7描述攻击的工作原理:首先，攻击者向用户将要访问的站点注入恶意代码。然后用户浏览器就会运行恶意代码，用幽灵病毒感染相框(参见图8)．最后，每当用户访问相框Web服务器时，虚影就会执行并窃取存储在SD卡上的当前照片。

请再次注意，防火墙无法阻止这种攻击，因为用户浏览器是用来感染帧和窃取数据的。提出了在图8，攻击可以分为两个阶段:感染而且执行。¹⁰图9显示了行动中的幽灵。我们在界面的底部添加了一个可见的调试跟踪。

感染:感染阶段的目的是将幽灵存储到相框中。要做到这一点，需要三个步骤。首先，恶意代码执行端口扫描，以检测照片框是否存在于用户局域网中。为此，它测试一组可能的内部ip(例如192.168.0.0/24)上的5050端口是否打开。由于相框使用的端口不常见，因此，如果这个端口是打开的，那么很有可能存在一个相框。其次，对于发现的每个开放端口，使用默认密码登录使用CSRF攻击。最后，使用第二个CSRF攻击将虚影注入到相框名称中。因为用户可能已经登录了，所以更可靠的技术是首先执行用于注入虚区的CSRF，然后尝试登录，最后重新注入虚区。在最坏的情况下，这种方法只会覆盖我们的幽灵，这不是一个问题，我们能够感染帧自定义密码，只要用户已经登录到他们。

执行:我们在实现用于窃取数据的幽灵时面临的四个挑战是:

1. 载荷大小:可注入的有效载荷的大小是有限的。
2. JavaScript错误:代码不能触发一个JavaScript错误，否则浏览器将停止执行，从而阻止导出。
3. 抓取数据:我们必须找到获取二进制数据的方法。XMLHTTPRequest不直接支持这一点。
4. 漏出数据:一旦数据加载到内存中，我们必须在保持常规帧代码运行的同时提取它。

第一个挑战是通过使用加载器解决的:注入的代码不是鬼本身，而是一个请求浏览器将鬼作为外部JavaScript加载的有效负载。

第二个挑战更加困难，因为注入的虚函数会在JavaScript函数中间的变量名中反映出来。因此，以下负载被注入到帧中:

此有效负载被设计为关闭变量、函数和脚本，请求幽灵作为新脚本并恢复函数。恢复是必需的，因为否则帧控制将被破坏。

为了处理与之密切相关的第三和第四个挑战，我们必须提出一种新方法，它使用AJAX技巧并以一种新颖的方式操作XMLHTTPRequest对象。下面是用作幽灵的代码草图:

这段代码的工作原理如下:首先，它在页面中注入一个不可见的表单，名为f(用于张贴被窃取的数据)和一个iframe命名uploadTarget进入Web页面(第1行)。这个iframe用于利用通过JavaScript控制iframe的能力，在iframe中执行表单f动作。因此，鬼的第二步(第2行)是通过使用以下JavaScript命令将form f action重定向到我们不可见的iframe:document.f.target = ' upload_target ';。提交到iframe是必须的，以防止整个页面的重定向，这将打破过滤循环并警告用户。请注意同源策略——保护用户访问合法网站的会话不被其他恶意网站利用的机制¹¹在这里不是问题，因为从合法站点向恶意站点发布数据是相反的方向，而且目前完全不受限制:这样的发布被假定在请求发起者的控制下。

此时，问题是如何获取将要被窃取的数据。发布文件的标准方法是使用文件输入字段，用户将使用该字段选择要发布的文件。当然，在我们的例子中，我们需要找到一种替代方法，因为我们没有用户的合作，而且，出于明显的安全原因，不可能使用JavaScript操作文件输入。因此，我们必须想出另一种方法。根据我们所观察到的，我们想要窃取的文件位于与幽灵相同的域中，我们想出了使用一个XHR(XMLHTTPRequest)加载JavaScript变量中的数据(第3行)。

同源策略再次无法阻止这种行为，因为我们的“幽灵”在这里充当一种自身免疫性疾病:受感染的页面攻击同一网站的其余部分。使用这种方法的一个困难是，XHR对象的设计不是只获取二进制数据，而是文本，因此仅使用XHR是不够的。为了解决这个问题，我们提出了改变http请求头的想法，更准确地说是Mimetype编码。例如，在Firefox中，可以通过以下方法覆盖XHR中使用的mime类型并请求自定义字符集编码:

使用带有此覆盖的XHR对象允许幽灵获取任何类型的文件并将其加载到JavaScript变量中。伪影代码的其余部分很简单:它用于解码XHR自定义编码(第4行)，在base64中重新编码文件(第5行)，将其发布到iframe中(第6行)，并重新加载接口以提取下一张照片。

我们必须处理的最后一个问题是在相框中使用的重新加载计时器:每500毫秒页面就重新加载一次。当然，这种行为破坏了鬼的活动，所以鬼的一部分被用来覆盖超时值与一个巨大的数字，当照片被提取时，重载方法被鬼显式地调用。通过这种方式，幽灵能够透明地适应任何上传速度。

4.2.P2P客户端中的幽灵

回顾3.2节，有些设备有嵌入式P2P客户端。除了作为XCS注入载体之外，该客户端还可能被反向XCS滥用，以播种非法数据和窃取数据。这种攻击背后的思想如下:控制Web界面的攻击者使用它插入他希望NAS为他播种的种子。

这可能有两个目的:一方面，他可以使用NAS容量和用户带宽为他播种非法文件。结合3.2节中的P2P XCS方法，这是一种大规模播种非法数据的方法。另一方面，攻击者可以利用P2P客户端，通过P2P网络窃取NAS内容。

用户不会注意到这种攻击，因为就像在相框中那样，完全控制页面可以让攻击者隐藏他的恶意活动。通过使用CSS显示属性攻击者可以屏蔽他的恶意种子，只显示用户请求的种子。因此，除非用户查看页面源，否则他将完全不知道该攻击。关键的挑战是找到一种方法让幽灵控制哪些文件需要被植入。为了实现这一点，我们使用了一个外部加载的JavaScript，它通过读取客户端页面并将其与攻击者提供的列表进行比较来跟踪当前文件。如果有一个文件没有被播种，那么JavaScript就会通过劫持用于添加torrent文件的Web函数来添加它。请再次注意，防火墙不能阻止这种攻击，因为客户端被授权下载自己的种子。

4.3.绕过CSRF防御

反向XCS的另一个应用是利用受感染的页面使用XHR或CSRF攻击同一站点，这是以前攻击的自然扩展。这种组合允许绕过当前的CSRF防御，因为它们都以某种方式依赖于同源策略。换句话说，同源策略不适用于我们的攻击，因为我们使用受感染的页面攻击同一域中的其他页面。

对CSRF的两个主要防御²验证HTTP头引用/来源，并使用一个隐藏的秘密令牌。在XCS上下文中检查HTTP报头是无用的，因为请求来自相同的域。通过向页面发送一个XHR请求，读取其结果并提取令牌值来动态构造将用于执行CSRF攻击的表单，可以阻止安全令牌的使用。由此得出的直接结论是，任何受到XCS攻击的设备也会受到CSRF攻击，无论它实施了何种CSRF防御。此外，由于XCS注入向量不是基于Web的，纯Web防御机制对XCS攻击没有影响。

回到顶部

5.回到Web: Restful RXCS

到目前为止，我们有意避免直接提及产品供应商。在本节中，我们将讨论两个特定的社交网络站点所带来的挑战;然而，讨论的问题范围更广。我们认为具体化有助于说明每个环境中的问题，而不需要指向任何第三方应用程序开发人员。

在本节中，我们将介绍利用大型社交网络网站提供的api的RXCS漏洞。基于rest的api正在成为与云服务交互的普遍方式。许多流行的云服务，包括Twitter、Facebook、E-bay、谷歌和Flickr，都提供了这种API。

例如，Twitter RESTful API允许任何人通过发出以下调用来查询XML格式的用户配置:

这个调用将返回以下格式化的数据，第三方应用程序随后可以对这些数据进行处理，以计算统计信息或存储在数据库中供以后使用。

这里的问题在于，第三方应用程序和云服务之间存在隐式信任。第三方应用程序开发者认为云服务提供了“安全”的数据。然而，定义什么是安全数据并不容易，而且每个云服务都有自己的消毒策略，这些策略通常没有明确的文档记录。预期数据和提供数据之间的不一致会导致RXCS。我们举两个例子。

5.1.Facebook RXCS

Facebook在显示时转义，这意味着提供给第三方应用程序的数据不会转义。Facebook的服务条款规定，第三方应用程序不应该直接输出从API获取的数据，而是使用Facebook的输出函数。类似地，应用程序不应该存储任何用户数据。然而，一些应用程序很可能会显示或存储数据，即使Facebook可能会监控API的使用情况，以防止违反服务条款。

为了给出一个例子，我们指出攻击一个脆弱的第三方应用程序可以通过注意所有的配置文件细节，从兴趣爱好到音乐和电影，都没有逃脱。因此，只要添加<脚本>标记将文本反映到应用程序。理论上，这可能会被用来绕过Facebook的安全策略。问题的根源在于Facebook信任第三方应用程序来正确处理API数据，而应用程序开发人员经常对数据的安全性进行假设。

假设您有一个显示Facebook用户最喜欢的电影信息的应用程序。在电影配置文件数据中添加恶意负载就足够了:然后可以将此负载反映给使用该应用程序的所有Facebook用户。

5.2.Twitter RXCS

Twitter的过滤策略与Facebook相反:转义是在输入时执行的，所以提供给第三方应用程序的所有数据都是HTML转义的。如果应用程序想要处理“原始数据”，它必须在处理数据之前对数据进行反转义。当然，当应用程序想输出数据时，它必须以自己的方式重新转义数据。这个不可转义、再转义的过程是乏味且容易出错的。事实上，找到一个容易受到RXCS注入攻击的Twitter应用程序并不困难。在图10，一个这样的应用程序被要求搜索一个字符串，该字符串是攻击者放置的消息的标签。当应用程序找到字符串(以及植入的消息)时，它会在处理后在浏览器中显示该消息，嵌入的有效负载会在不经意间被执行。

可以看到，与云服务的交互依赖于许多没有正确形式化的假设。特别是，理解这种交换背后的信任模型以及如何组合过滤策略是我们希望在未来工作中解决的开放问题。

回到顶部

6.防御xc

防止XCS的一种方法是确保发送到用户浏览器的所有数据都被正确地消毒。原理上，静态分析仪可以进行流量分析来检测潜在的XCS。^1，14这种方法必须污染Web应用程序中的所有输入通道，包括设备上的所有持久数据，并在Web页面中显示受污染的数据时发出警报。跟踪数据生命周期很容易错过一些XCS通道或无法污染XCS内容。另一个流行的XSS防御(例如Twitter使用的)是在输入时清除所有用户数据，然后再将其写入站点的持久存储中。这不大可能缓解XCS漏洞，因为恶意内容是通过非Web通道注入的，而这通常不会清除Web漏洞。此外，这种防御不能直接作用于非web原始数据，例如纯文本事件日志。如果这些数据也被其他非基于Web的应用程序(如后端统计分析器或IDS)使用，那么就会出现问题。

在我们关于XCS的原始论文中，^3.我们提出了一种名为SiteFirewall的防御方法，并将其与当前Web安全领域的其他发展进行了比较。SiteFirewall、CSP、SOMA和其他机制通常试图阻止在浏览器上下文中运行的Web站点执行涉及其他Web站点的操作，这些操作可能会访问或窃取私有数据。

虽然最近关于XCS防御的工作主要集中在浏览器上，但我们只是开始解决一些固有的服务器端问题。首先，设备供应商在选择Web服务器实现时必须更加谨慎，并要求外部嵌入式Web服务器开发人员和他们自己的工程人员提供更好的安全性。其次，复杂的嵌入式应用程序逻辑和状态需要更加可见，这将允许从同一主机(在LOM情况下)或通过网络(对于没有运行通用操作系统的设备)扫描漏洞。第三，Web社区需要认识到嵌入式Web站点与通常在Internet上看到的Web站点具有根本不同的使用模型:我们必须使这两种模式安全地共存。

回到顶部

7.结论

网络设备并不像人们通常认为的那样安全无害。以浏览器为中心的Web 2.0计算的出现扩大了通过嵌入式设备进行攻击的范围，从而产生了XCS。在硬件供应商开始常规地设计和测试安全性之前，还有很多工作要做，Web浏览器能够安全地处理不同类别的Web应用程序，用户能够做出和执行有关管理其网络化私有数据的决策。我们希望我们至少朝着这个目标迈出了第一步。

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2010 ACM有限公司

---

没有发现记录