XSS in Mobile Applications = “Danger, Will Robinson!”

As Danny Chrastil mentioned in a recent article, XSS; Beyond the Alert Box, Cross Site Scripting (XSS) is still very prevalent and dangerous holding the #3 spot on the OWASP Top 10 list for web application security.  In his article he mentioned that new technologies like HTML5 (and others) are increasing the attack vector of exploiting XSS.  In this article I would like to elaborate on this and focus on the dangers of XSS in mobile applications that are based on HTML5; the new attack vectors this technology opens up; and why it is more dangerous than being done in a browser. 

 

When mobile apps first started popping up they were actually mostly immune to XSS as they were native apps (i.e. written in Java for Android and Objective C for iOS) and thus mostly used user interface (UI) components from the native programming language instead of HTML components as used in regular web applications.  However, it was very difficult, time-consuming and costly to have to write your same app 2 or more different ways to support the various mobile platforms.  Well, all the platforms supported some way of having a web component that was like an embedded browser in your application.  If this was used in a framework, then the developers could just use this framework and would just need to know HTML, JavaScript and CSS and would be able to have the same code run on all mobile platforms… and thus, PhoneGap was born.

 

PhoneGap Architecture.jpg

Figure 1 – Image from Cross-Platform Mobile Development: PhoneGap vs Xamarin

 

As always though, with great functionality comes great vulnerability.  We have now just introduced the nasty problem of XSS into our mobile world.  Normally, the WebView component is sandboxed so that it would have the same attack surface and exploitability here as a browser would.  However, PhoneGap digs some tunnels out of the sandbox in order to allow the app to access the system and device.  This is done via plugins which allows the app to access useful parts of the phone such as network, contacts, geolocation, camera, media, etc.

Let’s look at the exploitability first.  Now, it is not only possible to do the normal XSS things like session hijacking, keystroke logging and redirection, but it is also possible to steal a user’s contacts, track them via their GPS, steal their files, media, etc.

 

Now what about the attack surface?  Could we inject JavaScript via a Wi-Fi connection?  What about a Bluetooth connection? Near Field Communication (NFC)? Yes. Yes. Yes. Even the camera? Images? Music and video?  Yes to all. 

Let’s take a look at Wi-Fi.  There are numerous apps available that will scan for open Wi-Fi networks and display their names (SSIDs) along with other information on the screen.  If one of these apps were to be an HTML5-based app, what would happen if I set up a Wi-Fi network with JavaScript in the SSID field?  Well, when the HTML5-based Wi-Fi scanner picks up my SSID and writes it to the screen I’m sure you can guess what will happen.  That’s right, XSS. Granted there are some limitations here.  How can I do anything useful with this when the SSID field only allows 32 characters?  Don’t worry, we got this.  One way is to host your script on the Internet and use a URL Shortener to point to it.  Another option (which is a little more difficult to pull off) is to set up multiple Wi-Fi networks and spread your script across all the SSIDs or even just use the one Wi-Fi network but change its SSID so each time the app refreshes its list of networks a new piece of the code will be pieced together.

 

With the explosion of cross-platform HTML5-based mobile applications, we need to be aware of the dangers involved with code injection in the Mobile Application Security world.  With HTML5-based mobile apps, the user has so many more ways of being attacked by XSS and so many more bad things that can be done to them or their phone.  This article is a summary of a great paper, Code Injection Attacks on HTML5-based Mobile Apps* (formerly “XDS: Cross-Device Scripting Attacks on Smartphones through HTML5-based Apps”), written by students at Syracuse University.  For all the cool technical details on how to exploit the new input channels and how to get around their constraints, please read this paper. 

 

* This paper also contains a really useful table (Table 1, Section 3.2, page 4) which can be used for DOM XSS in a browser as well.  With reflected and persistent XSS, the browser is more trusting of content coming from the server so will allow your script tag to be written via document.write() or .innerHTML.  However, with DOM XSS, the browser is a little more aware and prevents a script tag to be written via .innerHTML, however using an image tag is ok.  This table lists all of the DOM and jQuery APIs and which support script tags and image tags.

 

About HP Fortify On Demand

 

HP Fortify on Demand is a cloud-base Application Security solution. We perform multiple types of security testing, including advanced manual XSS detection.

 

If you have questions or comments reach out to us on Twitter @hpappsecurity or at fodsales(at)hp.com!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
Adam Cazzolla is a Sr. Security Consultant with HP Fortify on Demand.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation