HTML5|HTML5 App的代码注入攻击 HTML5App的代码注入攻击

原文链接摘要
基于HTML5的手机app（译者注：以下简称HTML5 app）越来越流行了，在大多数情况下它比native应用更容易适配不同的移动操作系统。它开发起来很方便，可以使用标准的web技术，包括HTML5、JavaScript 和CSS，也可以借助一些现有的开发框架（比如PhoneGap）和手机操作系统进行交互。
众所周知，JavaScript是非常容易遭受代码注入攻击的，因此我们计划对HTML5 app进行一次系统的研究以评估基于web技术开发的手机app安全性是否可靠。成果令人吃惊，我们发现如果HTML5 app成为主流（至少目从目前的趋势看是这样的），我们很多日常行为习惯都可能引入安全风险，包括二维码扫瞄、Wi-Fi接入点扫描、播放MP4视频、配对蓝牙设备等等。
本文介绍了HTML5 app可能存在的各种漏洞，攻击者如何利用各种途径进行攻击以及攻击成功后可能造成的危害。除了通过样例程序演示攻击以外，我们还研究了PhoneGap 186款用于实现不同功能的插件，我们发现其中11款是有漏洞的。我们还对两款真实的HTML5手机进行了安全测试，发现它们也是有漏洞的。
介绍
故事从John Smith开始，他是一个普通人。和大多数人一样，他使用了一款装满了各种app的智能手机，这个智能手机是他每天生活的一个重要组成部分。早上7点起床，John吃早餐的时候会打开手机里面的app听收本地的广播节目。这个app可以显示当前频段正在播放的音乐的名称，他可以搜索不同的频段收听他喜欢的音乐。8点的时候，他乘公共汽车上班。他看到一个有趣的产品广告贴在他前面座位的背后。为了了解更多产品信息，他用手机上的RFID刷了这个广告标签。忙完了上午的工作后，John在一家新开的餐馆吃午餐。为了节省手机流量费，他用手机搜索免费的Wi-Fi热点。他很高兴的发现有好几个免费热点可以使用。下午5点，John下班回家。在公共汽车上他开始听他下载的MP3歌曲。他的手机MP3 app能够播放MP3文件里面的歌词，这让他非常开心。下车以后，他收到了他媳妇的短信让他买一些好吃的带回家。
他去了超市，在超市里门口他看到有二维码贴在那里。他知道二维码是打折信息就马上扫了下，他很高兴的发现可以有5美元的优惠。
上面这个故事展示了手机在我们日常生活中使用的普遍性，看上去没有必要为这些使用场景担心。然而这只是目前的情况，一种迅速发展的技术趋势将很快改变一切。当这种技术被广泛采用以后，故事里面John的每个行为都可能引入安全风险。广播节目、RFID标签、MP3文件、Wi-Fi接入点、SMS信息和二维码都可能成为攻击者注入恶意代码到John的智能手机的通道，会导致很多危害。恶意代码不仅仅会驻留在他的手机，还会像蠕虫一样向其他手机进行传播。这种技术越流行，这种恶意代码就传播的越迅速。
这种技术就是HTML5技术，它是HTML5 app的基础。在这种技术被用来开发手机app之前，绝大多数的手机app都是使用各自系统支持的native语言编写的。比如Android app往往使用Java编写，iOS app使用Objective-C编写，跨平台移植app是比较麻烦的。因为Android和iOS使用量都很大，开发者往往没有选择，只能使用不同语言开发两个不能版本的app。如果以后其他手机操作系统用户多了，开发者将会更加悲剧。
HTML5 app技术为这个问题提供了一个解决方案。和native apps不同的是，这种app是使用HTML5技术开发的，这是一种和平台无关的技术，所有手机操作系统都支持这种web技术。这种app使用HTML5和CSS绘制用户界面，使用JavaScript实现程序逻辑。因为HTML5、CSS和JavaScript是跨平台的，所以这种app从一个平台移植到另外一个平台也是很容易的，在一定程度上来说甚至是通用的。基于这种优势，基于HTML5的app在迅速普及。Evans Data做的一个针对1200名开发者的调查发现使用HTML5技术进行app开发的占到了75%[1]。Gartner最近的一项报告称，在市场占有率上，HTML5 app将在2016 年和native app平分秋色。
非常不幸的是，使用HTML5、JavaScript和CSS开发app将引入natvie语言开发中不存在的安全风险。目前Web安全中仍然面临的跨站脚本攻击（XSS）问题很大程度上是由于数据和代码混杂在一起造成的，攻击者可以通过注入字符串执行代码。在我们的场景下，所有数据都是从不可信的外部通道获取的。如果这些数据中包含代码并且app开发者没有意识到这个风险，外部注入的代码有可能就会在app内部执行导致安全破坏。这是一种假想的潜在攻击方式，是否能够真正在手机设备上完成是未知的。本文对这种攻击方式进行了系统的研究。我们研究的发现包括如下：

我们确认HTML5 app可以被类似XSS的技术手段攻击。这种攻击场景是真是
存在的，我们已经在多款常用的app中完成了这种攻击。主流手机平台（包括
Android，iOS，和Black- berry）的HTML5 app都受这种攻击技术的影响。
我们系统的研究了这种攻击的潜在攻击通道和场景，大部分攻击场景我们都做了POC。
我们分析了攻击者面需要面对的挑战并展示了如何绕过它们。

文章剩下的内容结构是这样的：第2章介绍WebView和PhoneGap框架。第3章介绍如何进行攻击。第4章介绍攻击渠道和场景。第5章攻击者面需要面对的挑战并展示了如何解决它们。第6章和第7章介绍PhoneGap插件和真实手机app的漏洞。章节8和9讨论相关的工作、解决方案和研究总结。
背景知识
HTML5 app不能直接在手机操作系统上运行，无论是Android还是iOS都不能直接运行HTML5和JavaScript，需要有一个web容器渲染基于HTML5的用户界面和执行JavaScript代码。大部分手机操作系统都这样一个容器：Android 的WebView、iOS的UIWebView以及Windows Phone的WebBrowser。为了简化过程，本文中使用WebView作为研究对象。WebView最初被设计的目的是为了方便native app引入和展示web页面。它将基础的web浏览器功能封装到一个类里面，可以被app当作浏览器组件来使用。通过WebView提供的API函数，移动应用也可以绘制HTML页面。
由于WebView引入的Web内容往往是不可信的，WebView像浏览器一样实现了沙盒机制，JavaScript代码只能运行在一个孤立的环境中。这样的沙盒技术是适用于Web的，但是对于手机app来说过于严格了。一个运行在孤立环境中的手机app是没有太多用途的，因为它无法访问系统资源，如文件、触摸屏、摄像头等。WebView组件运行应用程序打通一个内部JavaScript代码和native代码（例如，Java）的调用通道。这个通道使得JavaScript代码可以调用native代码，而 native代码是可以不受WebView的沙盒限制访问app授权的系统资源的。开发者可以在WebView中使用自己编写的native，但是会降低应用程序的可移植性。常见的做法是使用第三方的中间件作为native代码的一部分，将跨平台的问题留给中间件的开发商来解决。成熟的中间件是支持多种手机平台的。目前已经有人开发了很多中间件，包括PhoneGap [12]，RhoMobile [13]， Appcelerator [3]等。在本文中我们将关注流行的PhoneGap，但是我们的攻击方式是影响所有中间件的。我们的研究是在Android平台上，但由于app的跨平台特性，其他平台也存在这类安全缺陷，也受这种攻击的影响。PhoneGap和PhoneGap插件：PhoneGap帮助开发者使用标准的web技术创建HTML5 app。开发者可以使用HTML页面、JavaScript代码和CSS文件。 PhoneGap框架默认使用WebView，依赖WebView渲染HTML页面和执行 JavaScript代码。

文章图片

PhoneGap由两部分组成（图1）：框架部分和插件部分，框架部分是沟通WebView中的代码和插件模块的桥梁，插件部分负责系统和外部交互的具体实现。对于每种类型的资源如相机、手机短信、WiFi和NFC都有一个或多个插件可以使用。目前PhoneGap框架包括16个可以直接在应用程序中使用的内置插件。如果一个应用程序的需求不能通过内置插件满足，开发者可以编写自己的插件或使用第三方插件。目前已经有183个第三方插件可以使用，而且数量还在不断增加。
插件是使用其宿主移动操作系统的native语言开发的，但是为了方便JavaScript调用，很多插件都提供配套的JavaScript库，有的甚至提供演示的 JavaScript代码告诉开发者如何使用这个插件。当WebView中的JavaScript代码需要访问系统或外部资源时，它可以调用插件库提供的API函数，插件库中代码将调用PhoneGap API，最后通过PhoneGap框架调用对应的插件中的Java代码。当插件完成它的工作后，它通过PhoneGap框架返回处理后的数据到页面。这是JavaScript代码通过WebView获取系统或外部资源的过程，图1描述了完整的过程。
代码注入攻击
Web技术有一个广为人知的危险特性：它允许数据和代码混杂到一起，比如当一个字符串包含数据和代码时，代码会被识别出来并且被JavaScript引擎执行。这是一种功能设计，这样可以让JavaScript代码很方便的嵌入到HTML 页面中执行。不幸的是，这个功能的后果是，如果开发商只想处理数据，但使用了错误的API，字符串中的代码会自动和错误的触发。如果这样的数据和代码混合字符串来自不可信的输入，恶意代码就可以被注入到应用程序中执行，这就是JavaScript代码注入攻击。其中一种典型代表就是被我们称为跨站点脚本（XSS）的，根据OWASP top10［11］，这是目前Web应用程序中的第三常见的安全风险。
3.1 概述
使用Web技术开发的手机app将制造一种新的蠕虫，它可以将针对特定的手机应用程序注入恶意代码。这种攻击破坏性比Web应用程序的XSS攻击要大很多，不仅仅因为我们给手机上安装的app授予了很多权限，更因为在XSS攻击中恶意代码的注入大多数都需要通过Web应用服务器，这是恶意数据到达他们攻击目标的唯一通道，而在手机应用场景下有非常多可利用的攻击通道。这些通道的一个共同的特点是，他们都是连接移动设备和外界的通道，实质上是遭受从另一个设备（不一定是一个手机设备）进行攻击的通道。图2（a）说明了攻击的基本思路。

文章图片

由于智能手机实时地与外面的世界交互，和传统的网络通道相比有更多新的通道可以输入不可信的数据到手机设备。例如，二维码、RFID标签、媒体文件、Bluetooth设备和Wi-Fi接入点等，恶意代码可以嵌入在这些通道数据里面。
如果数据混合的代码没有机会被触发，就不会有代码执行造成的风险。这就是natvie语言开发的手机app能够免疫这种代码注入攻击的原因。例如，即使攻击者可以嵌入Java代码到二维码里面，也没有机会误触发执行这些代码。但由于web技术的危险特性，这不适用于HTML5 app。特别地，app将数据显示出来是很常见的，例如展示一个二维码对应的信息。有一些Web技术的API “很帅”：他们可以从代码中分离数据，将数据发送到HTML渲染引擎，将代码发送到JavaScript引擎，这里并没有考虑开发者本意是否是要执行代码。当代码被执行时，它可以利用分配给应用程序的权限在移动设备上进行攻击，在WebView中使用PhoneGap框架和HTML5的API打开一个“攻击窗口”。
3.2 触发注入的代码
有两种常见的方式可以触发执行数据字符串中包含的JavaScript代码。一种是使用eval()函数，这个函数可以把字符作为JavaScript代码执行。这种风险不是很常见，因为程序员知道输入的字符串是不能包含非法字符的。另外一种触发代码执行的方式是通过DOM显示API和属性，比如document.write()，appendChild()，innerHTML（属性）等。一些jQuery API也可以触发代码执行，比如html()和append()，它们也是基于显示API和属性实现的。JavaScript通过这些API和属性显示信息在HTML页面中（在PhoneGap应用程序中，这些页面就是用户界面）。在第二种场景中，触发执行字符串中的代码在web环境下可能是因为业务需要，但是手机app中这种需求很少见。
不是所有显示API和属性都能执行字符串中的代码，这取决于代码嵌入的方式。在一个HTML页面中，有两种典型的代码和数据混杂在一起的场景：脚本或标签事件属性。下面给出这两种场景的示例代码：

文章图片

文章图片

当那两个字符串被传递给DOM/j- Query显示API和属性时，代码alert(‘attack’)是否可以被执行的总结如表1所示。我们统计了在代码中使用每个api和属性PhoneGap app的所占比例（我们收集的764 app）。
3.3 危害
这种攻击所能造成的危害如图2(b)所示，可以分成三类：一种是直接攻击受害者手机终端造成的（图中用细的带箭头标示），另外两种是恶意代码形成的扩散攻击(图中用粗的带箭头的线标示)。
首先，注入的恶意代码可以通过WebView中的代码打开的“窗口”直接对手机终端进行攻击。由于WebView的沙盒机制，正常情况下JavaScript代码是不能对终端设备造成太大破坏的。但是为了方便访问操作系统和硬件设备，手机app创造了很多“窗口”。这些“窗口”包括HTML5 API (比如地理定位API )和app安装的所有PhoneGap插件。需要指出的是，PhoneGap有16个内置的插件，所以即使app没有使用他们，他们仍然可以被注入到app中的恶意代码利用。这些插件包括通讯录、文件和外置设备插件。恶意代码利用他们可以获取系统资源的访问权限。而且很多PhoneGap app也使用了其他第三方PhoneGap插件。例如大约30%的PhoneGap app使用了FaceBook插件，这些插件也容易被恶意代码利用。
其次，注入的恶意代码可以通过内部数据通道注入到同一个设备上安装的其他有漏洞的PhoneGap app。在手机终端上，不同的app共享数据是很常见的。例如，通讯录是共享的，所以当一个应用程序受到外部攻击时，恶意代码可以把自己插入到通讯录中。当另外一个存在漏洞的PhoneGap app读取并显示存有恶意代码的通讯录时，代码就会被触发执行，这样就可以在第二个app里面进行攻击。有很多类似这样的内部数据通道可以被利用，比如通讯录、日历、图像和SD卡上的MP3/MP4文件等。
第三，注入的恶意代码可以将被感染的手机终端设备变成攻击跳板终端设备，它可以使用相同的攻击技术去感染其他手机设备。比如，被感染的app有权限发短信，恶意代码就可以通过发送带病毒的短信到通讯录中所有好友的方式进行传播。它也可以将代码加入到MP3文件的元数据字段中，然后分享给好友。它也可以伪装成一个蓝牙设备，名字设置成恶意代码，等待其他设备使用有漏洞的app连接。手机终端上装的PhoneGap应用越多，这种传输型的攻击就越容易成功，恶意代码就传播的越快。
代码注入通道
在这个章节，我们来研究如何识别可以注入代码到终端设备中的数据通道。为了演示我们是如何利用这些通道进行攻击的，我们需要找出app中使用了这些通道并且使用不安全的API显示数据的场景。考虑到我们只收集了几百个PhoneGap app，它们中的大部分要么没有使用这些通道要么没有显示这些通道获取的数据，所以使用真实的app做这个演示还是比较困难的。因此我们自己动手开发了用于演示各种攻击通道的PhoneGap app，为了保证研究的科学性，我们严格遵守以下原则：
（1）使用已存在的PhoneGap插件；
（2）如果一个PhoneGap插件有自己的JavaScript库，我们就使用它；
（3）我们使用的存在漏洞的API是现有的PhoneGap应用程序中常用的；
（4）PhoneGap应用程序实现的功能是现有的app中很常见的，不是特意制造的（作为证明，我们随时可以用非PhoneGap应用程序实现相同的功能）。
所有的攻击演示都可以在我们的网站上看到［10］。
4.1 ID通道
在很多情况下，手机在连接到外部实体设备之前，会获取外部实体的ID并且展现给用户看。这就建立了手机和外部实体的通道，甚至是在它们连接之前。我们研究这种通道是如何被用来注入恶意代码到手机设备中的。
Wi-Fi接入点：搜索附近的Wi-Fi接入点，很多智能手机用户都使用Wi-Fi scanner app来扫?周围可用的Wi-Fi热点。这类app会显示扫?到的Wi-Fi热点名称（SSID）和其他信息给用户。图3(a)是WIFI Analyzer显示的结果，这是一款从Google Play免费下载到的软件。在Google Play上有超过250款同类的软件，其中一些是非常流行的下载量超过1000万。

文章图片

随着这类app的流行，不难想像在不久的将来其中的很多app都有可能是基于HTML5开发的。当这种情况场景变成现实，Wi-Fi热点的SSID将变成一个潜在的代码注入通道。为了展示这种攻击，我们把一个Android手机配置成一个接入点。Android允许将接入点的SSID设置成任意字符串，我们将SSID设置为如下的JavaScript代码

图3(a)显示的是我们设置JavaScript代码，它在SSID中没有执行因为这个 app是用Java开发的。如果这个app应用程序是用PhoneGap，开发的，SSID会在WebView 显示，这里就容易产生一个高危的错误。如果app使用了不安全的API显示SSID，JavaScript就会被执行。
为了证明这个推断，我们使用PhoneGap框架和它的Wi-Fi插件写了一个Wi-Fi热点扫描app。如图3（b）所示的结果，这一次没有正确的显示SSID，而是作为代码执行了。在这个app里面，我们没有做任何特殊的处理。在开发这个app的时候，我们使用了html()函数来显示SSID信息，根据我们收集的数据来看，有16.36%的PhoneGap app做法是和我们一样的。即使我们使用 innnerHTML替换显示API，它比html()更安全并且不会执行内部的script标签中的代码，我们依然有办法完成代码注入攻击。在第五章中我们会给出相关的细节。
考虑到使用移动终端设置一个Wi-Fi接入点是非常容易的，这种攻击实施起来成本很低。在本章节，我们没有展示可以取得的攻击成果（只弹一个alert() 是没有危害的）。在第五章节，我们会介绍如何通过恶意代码进行真正的攻击和破坏。
BlueTooth：蓝牙具有类似的属性，在第一次使用BlueTooth连接其他外部设备的时候，需要进行配对。它会显示所有所有被探测到的BlueTooth设备ID，用户可以选择其中的一个进行配对。和Wi-Fi一样，这个ID也打通了从移动终端到其他外部BlueTooth设备的数据通道。只要能收到BlueTooth设备的信号，ID数据就可以直接进入移动终端设备。
这种攻击和Wi-Fi上的攻击非常相似：攻击者需要打开它手机上的BlueTooth功能，使用恶意的JavaScript作为设备名称，然后广播它的名称到附近的设备。附近的任何手机终端只要使用存在缺陷的PhoneGap app去连接配对，就会变成受害者。我们在Google Play上找到一款可攻击的PhoneGap app。在第七章我们会给出细节作为一个研究案例。
4.2 不同手机终端之间的数据通道
除了从网络、Wi-Fi以及蓝牙获取数据外，手机终端还有一些与传统的台式机和笔记本完全不同的获取数据的通道。比如，大部分智能手机可以扫?二维码（使用相机功能）、接收短信，还有一些智能手机支持读取RFID卡功能。这些数据通道使得用户从外界获取信息非常方便，所以被广泛使用在手机app中。通过研究我们发现，所有基于HTML5技术开发的手机app，都可以通过这些数据通道注入恶意代码。
近场通信(NFC)：近场通信是一个用于智能设备之间的近距离无线通信的协议。NFC技术已经被大量的移动设备所支持，包括谷歌Nexus系列，三星Galaxy S III和S4，三星Galaxy Note 3等。这些手机上NFC?流行的用途是读
取外部NFC标签中的信息，这已经成为一种便捷的获取外部数据的方式：用户只需要点击他们的设备上的NFC标签就可以获得数据。广告商和商户利用 NFC标签进行促销和广告宣传。例如，谷歌已经携手NFC专业技术公司Tapit 在澳洲东部的公共交通系统推出了在线音乐服务。将内置NFC标签的海报放在公共汽车和火车上的座位后面，感兴趣的用户可以直接使用手机扫描标签获取信息。
在Google Play里面有不少读取NFC标签的app，比如NFC TagInfo和NFC Reader。这些app通常注册了操作NFC的Intent对象，当手机设备检测到一个 NFC标签时，它就可以读取标签中的数据，然后发送含有数据的intent。这时候等待中的app将被触发，它会获取到数据并输出给用户看。图4(a) 展示了一个典型的NFC阅读程序的用户界面，需要注意的是我们作为数据放在NFC标签中的JavaScript代码只是简单的作为文本内容显示了，因为这个app是用Java 开发的。

文章图片

如果这样一个NFC读卡程序是用PhoneGap开发的，而且它使用了不安全的API显示从NFC标签读取的数据，对手机终端将会造成巨大的危险。为了展示这个风险，我们用PhoneGap框架和它官方?供的NFC插件开发了一个app，我们使用html()展示从NFC标签读取的数据
从图4(b)中我们可以看到，从NFC标签中获取的JavaScript代码已经被执行了。随着NFC应用日益广泛，存在缺陷的PhoneGap app在读取不可信的NFC 标签时将存在很大的安全隐患。攻击实现起来很容易：攻击者替换公共场合的NFC标签（包含恶意JavaScript代码），引诱用户来刷就可以了。这是一种被动的攻击。攻击者也可以将恶意的NFC标签放到攻击目标周围实现主动攻击。在标签中，攻击者可以指定应用程序接收NFC标签数据。因此，当攻击者把标签放到受害者的手机设备附近时，只要该目标手机设备没有锁屏，该设备将自动从标签读取数据，并启动指定的应用程序（通常是一个存在漏洞的PhoneGap app）来处理标签数据。
条形码：条形码?初是使用特殊的光学扫描仪进行扫描的，但随着智能手机的普及现在大多数手机设备都可以使用相机和软件扫描条形码。在Android设备上，谷歌的Goggles软件和一些三方软件比如Scan是比较常用的条形码扫描软件。通过这些软件开发一个读取条形码的app是很简单的：它可以简单的发一个intent给系统。这个intent会触发已经安装的扫描软件去扫描条形码，将条形码图片转换成数据，返回数据到?初的app。

文章图片

智能手机使用的一种常见的条形码是二维码（或QR码），它可以存储超过2k字节编码的文本消息。因为存储信息多和扫描方便，二维码是在现实生活中有广泛的应用。它们被张贴在商店入口?供销售和优惠券信息，贴在建筑物门上指引方向，在产品包装上?供额外的信息等等。由于二维码无处不在，扫描它已经成为我们生活中的一种常见行为，很少有人意识到扫描二维码可能带来的安全风险。
JavaScript代码可以被嵌入二维码中，对于一个native应用来说这不是问题，代码会被作为文本来显示不会被执行。图5(a)是一个native app扫描二维码的情景，我们在二维码中放入代码，但从图上可以发现我们的代码被作为文本显示。不幸的是，如果这是一个PhoneGap app，情况将有很大不同。我们开发了这样一个app，当我们用它来扫描二维码的时候，嵌入的JavaScript代码被执行了（参考图5(b)）。
我们已经发现了一款真实的存在漏洞二维码扫描软件，在第七章我们会给出完整的细节。
文本提取：除了可以从条形码图片提取数据以外，其他类型的图片也可以提取数据。文本提取就是个例子。很多手机应用都采用了标准技术实现了文本提取功能，支持从照相机拍摄的图片中自动提取信息，提取的文字会显示给用户。很多手机app可以从信用卡图像提取和显示信息，有一种类似读取信用卡信息的第三方插件。类似条形码的场景，如果HTML5 app显示了从图片中提取的信息，就会触发嵌入在图像中的恶意代码。
外围设备的数据通道：很多手机终端有额外的外置设备可以读取一些特别用途的数据。比如，信用卡读卡器（译者注：类似国内的拉卡拉那种设备）就是一种特别流行的外设，Square和PayPal都在使用这种外置设备。当用户在这种接在手机上的外设上刷信用卡时，读卡器会获取卡的信息，包括帐户、卡号和其他附加信息。这些信息会被反馈到app中，然后显示在屏幕上请用户确认。
很多小的商户使用这种外置设备接受顾客的支付。但是，如果这种app是用HTML5开发的，攻击者只需要用一个伪造的信用卡做一笔简单的支付就可以想手机设备中注入恶意代码。这种app都是和支付服务相关的，恶意代码在app 中运行起来以后会造成巨大的损失。
短信息：另外一种可以从外部获取内容的渠道是短信息。攻击者可以向短信内容注入恶意脚本，然后发给攻击目标。当使用了存在缺陷的API函数的HTML5 app显示恶意短信的时候，JavaScript会被成功触发。
4.3 多媒体的元数据通道
播放多媒体的手机app是非常流行的，比如播放歌曲、电影和看图片。这些多媒体文件都是从互联网下载或者朋友分享的，大部分是由音频、视频和图像组成的，看上去很难植入JavaScript代码。但是，大部分多媒体文件都有被称为元数据的额外区域，向这里注入代码是很好的选择。
MP3、MP4和图像：MP3 和MP4 文件是标准的音频和视频文件格式。然而，除了视频和音频，这类文件还包含很多元数据字段，诸如标题、艺术家、专辑、年代等等。当用户使用手机app听mp3音乐或者看mp4视频时，元数据字段中的信息通常会被显示出来，这样用户就知道歌曲的名称、所属的专辑、艺术家名字等等。

文章图片

图 6(a)展示了一类典型的MP3播放app的界面，从图上我们可以看到JavaScript代码是可以写入到元数据字段的，但是native语言开发的app只会显示JavaScript代码不会执行。可以用来向元数据字段写信息的工具有很多，比如iTune、Google Play Music、N7Player等等。
图像文件情况大体一样，我们可以从Google Play可以找到很多用于元数据读取的apps。它们可以显示作者名字、版权和图像?述。如图7(a)所示， JavaScript代码可以被插入到很多元数据字段中并且能够被native app显示出来。现在我们想像下，如果app使用PhoneGap开发的，使用了存在缺陷的API 从输出元数据会是什么情况。为了展示可能造成的影响，我们开发了一个这样的PhoneGap应用，结果如图6(b)和图7(b)所示: 嵌入在元数据中的JavaScript 代码被执行了。

文章图片

调频收音机：无线电波是另外一种潜在的注入代码到手机终端的渠道。近年来，一些新款的智能手机都有了内置的调频收音机，用户可以收听当地电台的广播节目。Verizon无线、AT&T和T-Mobile?供的手机都是可以收听广播的，无线电行业协会正在争取Apple也加入进来。Nokia在全球范围内已经销售了超过7亿部内置调频收音机的手机，可以看出用户是认可这种功能［4］。用户也愿意付出$20到$50去购买一个可插拔的调频收音机用在手机上。
如今，调频广播不仅包括音频轨道，它还包括使用RDS（无线电广播数据系统）协议的数据流。RDS是一种传统的调频广播中用于嵌入数字信息的通信协议。RDS标准化了几种类型的信息传递，包括时间、电台号和节目信息。无线电中数字信息包括PI（节目识别），RT（无线电文本），RT是和节目同步的64字符的自由文本存储空间（用于存储标题和艺术家等信息）等。有一种流行的调频收音app叫FM TwoO，它已经被下载了上百万次，它可以显示附加的数字信息给用户。
使用GNU-Radio软件和USRP (成本低于$2000)［7］，攻击者可以很容易的搭建一个调频广播台，可以播放他们自己制作的通过RDS通道嵌入了恶意代码的无线电节目。如果用户使用了HTML5 app收听这种节目，一旦显示了嵌入的RDS信息，恶意代码就会在受害者手机上被执行。
绕过限制条件
在前面的章节为了简单起见，我们使用弹框的方式来证明我们可以通过多种通道成功地注入代码，但是弹框是没有任何实质性危害的。在本章，我们来研究如何编写恶意代码实现最大限度的攻击。如果代码长度没有限制，这个问题就不需要探讨了，因为攻击者可以编写代码实现他们想做的任何事情。不幸的是在本文描述的攻击场景下，代码长度限制是我们需要面对的一个巨大挑战。例如，在Wi-Fi攻击中，我们使用SSID字段作为攻击通道，这个字段只能包含32个字符[15]。问题在于攻击者能否在这么短的条件下实现有意义的攻击，用最小的输入实现最大的破坏。
5.1 数据通道的长度限制
为了更好的理解长度限制，我们对已经识别的可以注入代码的数据通道进行了系统的研究。研究的结果如表2所示：

文章图片

从表中可以看出，长度限制对MP3/MP4、JPEG、二维码(QR码)和NFC这几个通道影响不大，它们允许输入超过2000个字符，这对攻击者来说足够了。不幸的是，Wi- Fi的SSID字段、图片文件的Model和Maker字段、蓝牙和短信息看上去是非常有限的。特别是Wi-Fi，仅有的能利用的数据通道长度被限制在32字符。在后面的章节，我们将把这个极端情况作为目标。我们将找到办法利用这32字节的数据通道构造可以被注入到手机终端中的JavaScript代码。
可以造成的破坏程度取决于实际注入的代码，所以病毒代码的长度取决于你想取得的攻击成果。长度可以相当长，是否会产生问题由长度限制决定。为了解决这个问题，我们使用如下的方案：我们通过有长度限制的攻击通道注入一段短的代码到受害者手机中，这段代码的目标是加载一个外部URL。因为外部代码是通过常规数据通道（比如网络连接）进入受害者手机的，这时候就没有长度限制了。因此，攻击者可以放置任意代码实现最大化的攻击。
在下面的子章节，我们会聚焦上面?到的短的通用代码，找出能够引导攻击或者说能够引入外部URL的?短的JavaScript代码。
5.2 短URL
我们需要使用一个URL指向外部代码，所以尽量减小URL的长度是很重要的。我们研究了很多方法，其中一个方法是使用在线URL缩写功能，比如 Google URL缩写功能[8]和tr.im [14]等等。URL缩写功能是用来在一些app中显示超过限制的长URL的。尝试了几个在线平台之后，我们得到了?短的URL http://tr.im/4ktkq。另外一个方法是购买比较短的域名，我们找到了域名e.gg，需要$1，490一年。还有一些长一点的（比如4ac.us）也能够卖到，价值$3.99 一年。巧合的是参与本课题的一个学生拥有一个域名mu.gl（他每年为此支付$49），因此我们在本文中使用http://mu.gl。
尽管URL缩写方案使用的URL比购买域名来的长一些，但是它依然具有某些优势：不仅免费，而且能够隐藏攻击者。它们可以轻易的使用别人的web 服务器部署恶意代码，而不是使用自己的服务器。
5.3 压缩恶意代码
有很多方法可以引入外部的JavaScript代码，我们将展示每种场景下最短的引入外部JavaScript文件的方式。
使用Script标签：使用
使用事件属性：不幸的是，正如我们在第3节中?到，如果上面用的内容被innerHTML显示，代码是不会被显示或执行的。为了像上面一样击败 innerHTML，我们需要用另一种方式嵌入代码。JavaScript可以放在一些HTML 标签的事件属性中，如onclick、onscroll、onerror和onmouseover事件。这些标签可以是Button标签、A标签、IMG标记等等。下面是一个例子：

文章图片

很多PhoneGap应用使用JavaScript库来简化自身，jQuery就是一个广泛应用的库。如果一个app真的使用了jQuery，我们可以将上面的代码简化到45个字符。这里要用到jQuery的getScript函数。这里是一个例子（我们不能省略“http:”，否则getScript无法识别HTTP方法）：

文章图片

在上面的代码中，每一份的长度都不超过32个字符。这种方法是通用的，换句话说，初始的代码越长，我们需要分割的份数就越多。下一个挑战就是怎么样把这些分片的代码注入到目标用户的手机上。对某些数据通道来说是很简单的，因为这些数据通道有多个字段可以使用。例如JPEG元数据里就有多个字段可以用，所以我们成功完成攻击只需要5个字段。当目标app显示5个字段的时候，恶意代码就会被成功执行。即使目标app只显示一个字段，我们也可以通过分别注入5份代码到5个不同图片的方式进行攻击。

文章图片

对Wi-Fi来说，只有一个字段我们可以注入代码，问题就是我们如何将上面的5份代码同时注入。这里有两种方案。第一种方式是使用多个Wi-Fi接入点。按照上面的例子，我们需要设置5个接入点，每个分别使用一段代码作为其SSID。当目标用户使用有漏洞的app扫描附近的Wi-Fi时，5份代码会全部被注入。我们需要确保最后一份代码包含eval(a+b+c+d)那一份，必须在目标用户手机上最后显示，因为这一段代码需要先定义a，b，c 和d。为了达到这个效果，我们只需要确保第5个接入点?后广播它的SSID就可以了。图8(a) 展示了一款叫做WIFI Analyze的non- PhoneGap app5显示个不同的恶意代码接入点的场景。而当这5个接入点在PhoneGap app种显示时，jQuery 代码将会被执行。
攻击者也可以使用一个接入点完成攻击。大部分Wi-Fi扫描app会定期刷新屏幕更新可以被检测到的接入点列表。为了完成我们的攻击，我们不需要我们构造的恶意的SSID在同一时间显示。它们每一个被显示的时候，注入在 SSID的代码就会被执行。如果5份代码都被执行了，我们的攻击就成功了。因此，我们只需要使用一个接入点、每次将接入点SSID修改其中一份代码，每次一个，第5份代码作为最后一个。在图8(b)，我们从non-PhoneGap app中在五个不同的时间做的5次屏幕截图，每次都是一个不同的SSID。实际上，这5个SSID都来自同一个设备。我们已经在我们开发的PhoneGap app上做了验证，这些验证SSID被显示的时候，jQuery代码就会被执行。
PHONEGAP插件
PhoneGap应用程序需要使用插件来与Webview之外的对象实体进行交互。在本章节中，我们要找到那些存在安全缺陷的插件。如果一个插件使用了不安全的api显示从可以攻击的通道获取的数据，它就是存在安全缺陷的。在本次研究中，我们从从GitHub [ 6 ]下载了186个第三方插件作为测试对象。
6.1 可被利用的插件
如果一个插件可以被成功攻击，它需要返回数据到WebView中的页面，并且数据必须是能够从外部控制的，不是所有的插件都符合这个条件。我们开发了一个工具对这186个插件进行了分析，我们发现其中58个插件是完全不输出数据的。另外51个插件输出的数据攻击者无法控制，比如返回逻辑结果、常量字符串或者状态数据等等。换句话说，这些数据要么是系统控制的，要么是开发者控制的，所以很难从外部注入代码。剩下的77个插件是符合我们要求的，它们可以进一步按照数据来源分成三类，如下表(Table 3).

文章图片

在这77个插件中，24个插件从Web中获取数据（例如，PhoneGap插件可以获取Facebook 和Twitter上的数据）。这些数据也可能包含恶意代码，但是这些风险（比如XSS）已经广为人知了，我们不再对这类插件进行讨论。另外38个插件从手机设备资源获取数据（例如日历和通讯录），换而言之，数据通道是内部的。这些数据可能包含代码，攻击者必须先安装一个恶意的app 能够将恶意脚本注入这些资源，然后一个有缺陷的PhoneGap app显示来自这些资源的数据时，恶意脚本才能以目标app的权限执行。这个通道也可以用来在同一个手机上进行跨PhoneGap app攻击。
我们的主要兴趣在“外部数据”这一类，其中包含15个插件。它们从外部资源获取数据，并返回数据到的WebView的页面中。我们对它们进行了更深入的研究。
6.2 存在安全缺陷的插件
在我们研究的15个插件中，有四个是语音识别和信用卡扫描相关的。鉴于读出JavaScript并让app识别和获取信用卡扫描硬件都比较困难，我们没有对这四个插件进行研究。因此，我们的研究范围缩小为这11个插件。在这11个插件中，有5个自带JavaScript代码，包括3个蓝牙插件、1个Wi-Fi插件和一个短信插件。研究过以后，我们发现?供这些JavaScript代码有两个目的：一个目的是为开发者?供示例代码，告诉他们如何使用这个插件；另外一个目的是提供JavaScript库，使得插件使用起来更容易。这两种情况下，如果插件自带的JavaScript代码是有缺陷的，将导致非常显著的破坏，因为大部分app开发者要么直接使用?供的库要么参考示例代码的写法。从插件包含的JavaScript代码，我们发现它们基本上都使用innerHTML或者html() 显示数据。因此，如果数据包含恶意代码就会被执行。我们已经通过试验证实了我们的推断。
另外的六个插件，它们没有?供有缺陷的JavaScript代码，但是仍然有潜在的安全缺陷的，因为它们没有过滤来自可被利用通道的代码。如果PhoneGap app使用这些插件并且碰巧也使用了存在缺陷的数据输出api，将会造成安全漏洞。考虑到这些有缺陷的API在PhoneGap app中是被广泛使用的(参考Table 1)，我们相信开发者将这几个插件和这些API一起使用进而造成安全漏洞的概率会比较高。在第四章中我们开发的存在漏洞的app，我们就使用了这些插件（包括二维码、NFC和短信插件）。这表明这些插件和错误的api使用方法组合起来将会导致存在漏洞的app。
案例研究
通过我们自己开发的程序研究过这些潜在的攻击以后，我们非常想知道现实中真实存在的app是否也受这种攻击的影响。出于这个目的，我们进行了有步骤的搜索。我们从Google Play上下载了25类共计12，068个免费的app，包括旅游、交通以及社交等等。我们识别出了190个PhoneGap app。从PhoneGap 官方网站[12]我们收集了另外574免费的PhoneGap app，我们一共收集了764 个PhoneGap app。虽然这个数字相对Google Play上的海量软件来说是比较小的，但是我们相信随着HTML5 app越来越流行，这个数字会在短期内显著的增长。
为了确定一个PhoneGap是否受这种攻击的影响，我们用AndroGuard [2]写了一个Python工具来扫瞄这764个PhoneGap app，分析如下的信息：
? app是否从我们已经识别的通道中读取外部数据
? app是否使用存在缺陷的API或属性显示信息
显示的信息是否来自以上的通道
我们发现结果如下：
(1) 142个app符合第一个条件。
(2) 290个app至少使用了一种有缺陷的API或者属性显示信息
结合以上两点，我们发现32个app符合前两个条件。我们没有去写复杂的数据流分析工具去检查是否符合第三个条件，而是手工对这32个app进行了分析。?终，我们发现有两个app符合第三个条件。这意味着，他们非常有可能存在漏洞。我们用真实的攻击方法对他们进行了测试，结果证明他们确实存在漏洞。我们会在本章后面部分给出试验细节。
案例研究 1: GWT移动PhoneGap示例应用。这是一个PhoneGap示例app，他告诉开发者如何使用PhoneGap和它的插件。这个app使用全部的三个内置插件和三个第三方插件——ChildBrowser插件,Bluetooth插件和Facebook插件。这个app授予了这些插件全部权限。
这个app的一个功能是使用Bluetooth插件列出所有能检测到的Bluetooth设备（通常是为了配对的需要）。不幸的是，它使用了innerHTML 显示Bluetooth 设备的名称。这个API是可以进行代码注入攻击的。
为了对这个存在漏洞的app进行攻击，我们把攻击设备调成蓝牙模式，把恶意的JavaScript代码嵌入名称字段（长度限制为248，足够使用）。为了比较，我们同时还用了一个non-PhoneGap app做Bluetooth配对，测试结果图9(a)，从中我们可以看出在non-PhoneGap app中代码作为纯文本显示了。
代码如下所示（为了方便阅读，我们加了一些空格）

文章图片

PhoneGap.exec() 最终会触发一个WebView之外的PhoneGap方法（Java代码），它需要5个参数。后面的三个参数在上面代码第九行，分别是插件名称 (Contacts)，需要通过插件调用的方法(search)，还有传递给方法的参数。简单的说，这三个参数请求PhoneGap返回手机通讯录中的所有姓名。如果 PhoneGap.exec()请求失败，第八行的函数会被执行（这里是空函数）。如果请求成功，第2-7行定义的函数会被调用，这里就是要实现的攻击效果。
当这个回调函数被调用后，PhoneGap插件返回的数据会存储到变量a中，它是一个存储了从通讯录中读取到的姓名的数组。从第3行到第4行，我们看到代码利用通讯录的数据构造了一个叫m的字符串。在第5行，出于演示的目的，我们将这个字符串显示出来了（参考图9(b)）。在第6行的真实攻击中，看上去我们只是构造了一个img标签，但是它的真实目的是调用一次HTTP GET 方法请求远程服务器（攻击者控制的），通过这个请求将窃取的通讯录数据发送给攻击者。
作为一个PhoneGap演示app，存在漏洞的GWT移动PhoneGap示范程序对真实的app有很大的影响，因为开发者通常是通过这样的演示程序学习怎么开发PhoneGap app（这个app的源代码可以从GitHub [9]上获取到）。在公开本文之前，我们已经联系这个app的开发团队修复了漏洞。

文章图片

研究案例 2: RewardingYourself app。This app manages users’ miles or points in their loyalty program and find out how much they are worth. （译者注：这句实在是看不懂，望高手赐教）。这个app使用了所有PhoneGap官方插件和一个第三方的条形码扫描插件。当这个app扫描一个条形码时，会使用可以被注入代码的innerHTML显示条形码里面的数据。我们制作一个包含如下脚本的二维码：

文章图片

这段代码使用Geolocation.watchPosition()来窃取用户的物理位置。这个API 是HTML5中引进的，它注册了一个当终端的物理位置变化时就会被自动调用的处理函数。从代码中我们可以看到处理函数被调用时，位置信息会被存储到变量loc中并且在第六行显示（见图10(b)）。在第7行和第8行，loc的内容被发送到外部电脑。由于处理函数时被循环调用的，一旦受害者扫描了二维码，只要这个有漏洞的app在运行，手机就会不断的发送位置信息给攻击者(见Figure 10(c))。
这个app也可以在其他平台上使用，包括iOS和Blackberry。不幸的是，我们在iOS上无法使用它扫?二维码。它依赖于另外一个二维码扫描app来读取二维码，但是这个app不能在iOS上工作。这个RewardingYourself app可以用在Blackberry，我们使用同样的二维码进行攻击测试获得了成功。这证明了我们的攻击方法是和平台无关的假设。

文章图片

解决方案和其他相关工作
找到这种威胁的解决方案已经超出了本文范畴，这将是我们下一阶段研究的焦点。在本文中，我们参考XSS攻击的解决方案简单的给出一些解决问题的思路。理论上来看这些方法是可行的，但是在实战中运用还有很多工作要做。
基于数据净化的解决方案：数据净化是一种常见的技术，它通过过滤数据中混杂的代码来阻止代码注入攻击。净化后的数据变成一个纯文本无法触发代码执行。基于净化的解决方案已经在web安全领域被广泛研究，面临的主要挑战是如何识别出混杂在数据中的代码。人们提出了很多方法来解决这个问题，包括Bek [22]、CSAS [31]、ScriptGard [32]等。不幸的是，不断有新的绕过现有净化方案的攻击方式被?出[20，21]。
我们可以采用一些净化方法移除字符串种的脚本来阻止攻击；但是挑战在于我们在什么地方进行数据净化。对XSS攻击而言很简单，它只有一种数据通道（web服务器）。但是对于我们?出的攻击，有很多通道可以用来注入代码。有很多地方可以进行净化操作：其中一个地方是PhoneGap框架，这是所有外部数据进入WebView的唯一通道。然而这种方案仅限于PhoneGap。如果我们能在WebView种进行净化会更合理，这是一个更通用的方案，但是目前还不清楚这种处理是否会影响WebView原有的功能。
基于污点分析的解决方案：另外一种方案是采用污点分析来确定是否存在代码注入漏洞。污点分析框架可以被应用在服务端[25，28，30，36] 或者客户端[19，29]。污点分析的思路是标记不可信输入，跟踪他们在程序中的扩散。任何直接或者间接执行污染数据的尝试都会被记录和阻止。
使用污点分析方案，我们必须标记进入终端的外部数据。挑战在于需要跟踪数据通过终端设备、Dalvik虚拟机、JavaScript引擎和不同组件之间的处理过程。如果我们能做到这些，我们就可以阻止代码被触发，甚至可以阻止恶意代码进入终端设备。
缓解破坏：与阻止代码注入攻击的思路不同，很多研究者致力于缓解脚本注入造成的破坏。这个想法是限制不可信代码的力量。开发者需要配置一些策略，基于内容的可信程度对每个DOM元素赋予不同的权限。例如，Escudo [23] 和Contego [26] 在某些特定的DOM元素中限制脚本的权限。内容安全策略[33，35] 为JavaScript?供了一个严格的制约，不允许inline方式执行JavaScript 和eval()。CSP可以解决本文?出的问题，但是强制使用缺省的CSP策略需要app开发者付出巨大的努力去修改现有的app，因为将不支持inline-JavaScript。CSP对HTML5 app保护的有效性值得进一步研究。这个框架是为浏览器设计的，但是我们可以参考上面的思路来做缓解攻击的工作，换句话说，我们可以开发一个安全的WebView为HTML5手机app?供可信计算的基础。
其他相关工作：WebView和PhoneGap是HTML5手机app的重要组成部分。很多研究已经揭示了他们的安全性[17，18，24，27，34]。NoFrak [18]和[24] 关注如何阻止不可信的外部web代码访问手机本地资源。他们的解决方案不能用于防御我们的攻击，因为我们的攻击方式中代码来自的外部通道不属于web。 XCS [16] 发现了很多有趣的注入代码到服务器的通道，比如打印机、路由器和电子相框等。一旦代码被web接口搜索，就会在桌面浏览器上执行。在我们的工作中，大部分数据通道是完全不同的手机平台的，研究的问题也是完全不同的攻击方式。
总结和未来的工作
在本文中，我们发现了一种新的针对HTML5手机app的代码注入攻击。我们在手机终端上使用poc app和真实的app系统的研究了这种攻击的可行性。 HTML5 app以其可移植性优势已经越来越流行，我们预计这种攻击将在不久的将来爆发。能够在爆发前识别这种攻击是非常重要的，它可以帮助我们在思维中明确各种技术例如PhoneGap所带来的风险是不断变化的。在我们下一步的工作中，我们会开发解决这种攻击的解决方案，和PhoneGap团队（还有其他类似团队）一起找到切实可行的解决方案，在保持HTML5手机app优势的基础上提高其安全性。
10. 致谢
我们要感谢多位匿名审稿人有价值和令人鼓舞的评论。这个工作获得了NSF 的资助和Google的研究奖励，但是本文的任何意见、成果、结论和意见并不受NSF和Google的影响。
11. 参考
【HTML5|HTML5 App的代码注入攻击】[1] 75% of developers using html5:survey.
http: //eweek.com/c/a/Application-Development/ 75-of-Developers-Using-HTML5-Survey-508096.
[2] androguard:reverse engineering, malware and goodware analysis of android applications
http://code.google.com/p/androguard.
[3] Appcelerator. http://appcelerator.com.
[4] The facts about fm radio in mobile phones.
http://radioheardhere.com/fm-mobile.htm.
[5] Gartner recommends a hybrid approach forbusiness-to-employee mobile apps. http://gartner.com/newsroom/id/2429815.
[6] Github:build software better, together. https://github.com/.
[7] Gnuradio, usrp and software defined radio links. http://olifantasia.com/cms/en/node/9.
[8] Google url shorener. http://goo.gl/.
[9] Gwt mobile phonegap showcase source code.
https://github.com/dennisjzh/GwtMobile.
[10] Mobile apps under a new type of attack.
http://www.cis.syr.edu/~wedu/attack/index.html.
[11] Owasp. the ten most critical web applicationsecurity risks.
http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf.
[12] Phonegap. http://phonegap.com.
[13] Rhomobile. http://rhomobile.com.
[14] tr.im. http://tr.im/.
[15] Wiki:service set (802.11 network).http://wikipedia.org/wiki/Service_set_(802.11_network).
[16] Hristo Bojinov, Elie Bursztein, and Dan Boneh.
XCS: cross channel scripting and its impact on web applications. In Proceedings of the 16th ACM conference on Computer and communications security, pages 420-431. ACM, 2009.
[17] E. Chin and D. Wagner. Bifocals: Analyzing webview vulnerabilities in android applications.
[18] Martin Georgiev, Suman Jana, and Vitaly Shmatikov. Breaking and fixing origin-based access control in hybrid web/mobile application frameworks. 2014.
[19] O. Hallaraker and G. Vigna. Detecting malicious javascript code in mozilla. In Engineering of Complex Computer Systems. ICECCS 2005.
[20] R. Hansen. Xss cheat sheet. http://ha.ckers.org/xss.html, 2008.
[21] Mario Heiderich, Jo rg Schwenk, Tilman Frosch, Jonas Magazinius, and
Edward Z. Yang. mxss attacks: attacking well-secured web-applications by using innerhtml mutations. 2013.
[22] P. Hooimeijer, B. Livshits, D. Molnar, P. Saxena, and M. Veanes. Fast and precise sanitizer analysis with bek. In Proceedings of the 20th USENIX conference on Security, 2011.
[23] K. Jayaraman, W. Du, B. Rajagopalan, and S. J. Chapin. Escudo: A fine-grained protection model for web browsers. In ICDCS, 2010.
[24] X. Jin, L. Wang, T. Luo, and W. Du. Fine-Grained Access Control for HTML5-Based Mobile Applications in Android. In Proceedings of the 16th Information Security Conference (ISC), 2013.
[25]N. Jovanovic, C. Kruegel, and E. Kirda. Pixy: A static analysis tool for detecting web application vulnerabilities. In IEEE Symposium on Security and Privacy, 2006.
[26]T. Luo and W. Du. Contego: Capability-based access control for web browsers. In Trust and Trustworthy Computing. Springer, 2011.
[27]T. Luo, H. Hao, W. Du, Y. Wang, and H. Yin. Attacks on webview in the android system. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), 2011.
[28]A. N. Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans.Automatically hardening web applications using precise tainting. Springer, 2005.
[29]F. Nentwich, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna. Cross-site
scripting prevention with dynamic data tainting and static analysis. In Proceeding
of the Network and Distributed System Security Symposium (NDSS), 2007.
[30]T. Pietraszek and C. V. Berghe. Defending against injection attacks through context-sensitive string evaluation. In Recent Advances in Intrusion Detection, pages 124-145. Springer, 2006.
[31]Mike Samuel, Prateek Saxena, and Dawn Song. Context-sensitive
auto-sanitization in web templating languages using type qualifiers. In
Proceedings of the 18th ACM conference on Computer and Communications Security, 2011.
[32]P. Saxena, D. Molnar, and B. Livshits. Scriptgard: automatic
context-sensitive sanitization for large-scale legacy web applications. In
Proceedings of the 18th ACM conference on Computer and communications security, 2011.
[33]S. Stamm, B. Sterne, and G. Markham. Reining in the web with content
security policy. In Proceedings of the 19th international conference on World wide web, pages 921-930. ACM, 2010.
[34]R. Wang, L. Xing, X. Wang, and S. Chen. Unauthorized Origin Crossing on Mobile Platforms: Threats and Mitigation. In ACM Conference on Computer and Communications Security (ACM CCS), Berlin, Germany, 2013.
[35]J. Weinberger, A. Barth, and D. Song. Towards client-side html security policies. In Workshop on Hot Topics on Security (HotSec), 2011.
[36]Y. Xie and A. Aiken. Static detection of security vulnerabilities in scripting languages. In Proceedings of the 15th conference on USENIX Security Symposium, volume 15, pages 179-192, 2006.
via 作者：Xing Jin, Tongbo Luo, Derek G. Tsui, and Wenliang Du 翻译：flyh4t（machuanlei@nsfocus.com）
转载于:https://www.cnblogs.com/miyeah/p/3932868.html