HTML5 App的代码注入攻击

原文连接

摘要

基于HTML5的手机app（译者注：如下简称HTML5 app）愈来愈流行了， 在大多数状况下它比native应用更容易适配不一样的移动操做系统。它开发起来很方便，可使用标准的web技术，包括HTML五、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实现程序逻辑。由于HTML五、CSS和JavaScript是跨平台的，因此这种app从一个平台移植到另一个平台也是很容易的，在必定程度上来讲甚至是通用的。基于这种优点，基于HTML5的app在迅速普及。Evans Data作的一个针对1200名开发者的调查发现使用HTML5技术进行app开发的占到了75%[1]。Gartner最近的一项报告称，在市场占有率上，HTML5 app将在2016 年和native app势均力敌。

很是不幸的是，使用HTML五、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代码

 

<script>alert(’attack’)</script>

<script> alert ( ’ attack ’ ) </script>

图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代码。可是，大部分多媒体文件都有被称为元数据的额外区域，向这里注入代码是很好的选择。

MP三、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/MP四、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标签：使用<script>标签是一种典型的引入JavaScript代码的方式。在这种状况下，咱们能够省略“http:” 和  “>”。下面的代码是咱们构造的ᴰ短的脚本代码，长度为28字符:

<script src=//mu.gl></script>

使用事件属性：不幸的是，正如咱们在第3节中ᨀ到，若是上面用的内容被innerHTML显示，代码是不会被显示或执行的。为了像上面同样击败 innerHTML，咱们须要用另外一种方式嵌入代码。JavaScript能够放在一些HTML 标签的事件属性中，如onclick、onscroll、onerror和onmouseover事件。这些标签能够是Button标签、A标签、IMG标记等等。下面是一个例子：

<img src onerror=jscode>

以上代码中咱们使用了img标签。当含有这样的HTML标签的数据在WebView中显示的时候，HTML会解析标签并尝试加载指定的图像。可是我 们故意没有ᨀ供图像源地址，因此会发生错误，这时onerror属性指定的代码 就会被触发。这种技术在运行着Android 4.4系统的Nexus 5手机上测试经过。 早期版本的Android系统，咱们须要为src属性指定一个不存在的URL，例如， 咱们须要设置“src=x”，这样多了两个字符。咱们的测试使用了Nexus 5，能够 不考虑这种状况。这种包含代码的方式将绕过innerHTML中实现的过滤机制。

而后，这些属性不容许从外部URL加载JavaScript代码，全部的代码都必须写在属性里面，这使得咱们很难形成较大的破坏。为了解决这个问题，咱们使用插入的代码动态的生成一段脚本，经过这段脚本引入外部URL。下面是一个例子，一共99个字符：

不少PhoneGap应用使用JavaScript库来简化自身，jQuery就是一个普遍应用的库。若是一个app真的使用了jQuery，咱们能够将上面的代码简化到45个字符。这里要用到jQuery的getScript函数。这里是一个例子（咱们不能省略“http:”，不然getScript没法识别HTTP方法）：

<img src onerror=$.getScript(’http://mu.gl’)>

5.4 绕过长度限制

目前为止，咱们借助jQuery可以构造的ᴰ短恶意脚本是45个字符。这个脚 本已经可以适用于咱们识别出来的大部分代码注入通道，可是仍然超过Wi-Fi 的SSID字段32个字符的限制，咱们须要想办法解决这个问题。咱们的思路是将这段JavaScript分割成几份，而后使用eval()把它们拼接在一块儿。例如，咱们能够将上面的$.getScript分割成5份，相似如下代码：

在上面的代码中，每一份的长度都不超过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. 参考

[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）