Code Injection Attacks on HTML5-based Mobile Apps:
Characterization, Detection and Mitigation
Xing Jin, Xunchao Hu, Kailiang Ying, Wenliang Du, Heng Yin
and Gautam Nagesh Peri
Department of Electrical Engineering & Computer Science, Syracuse University,
Syracuse, New York, USA
{xjin05, xhu31, kying, wedu, heyin, nperi}@syr.edu
ABSTRACT
Due to the portability advantage, HTML5-based mobile apps are
getting more and more popular. Unfortunately, the web technol-
ogy used by HTML5-based mobile apps has a dangerous feature,
which allows data and code to be mixed together, making code in-
jection attacks possible. In this paper, we have conducted a sys-
tematic study on this risk in HTML5-based mobile apps. We found
a new form of code injection attack, which inherits the fundamen-
tal cause of Cross-Site Scripting attack (XSS), but it uses many
more channels to inject code than XSS. These channels, unique to
mobile devices, include Contact, SMS, Barcode, MP3, etc. To as-
sess the prevalence of the code injection vulnerability in HTML5-
based mobile apps, we have developed a vulnerability detection
tool to analyze 15,510 PhoneGap apps collected from Google Play.
478 apps are flagged as vulnerable, with only 2.30% false-positive
rate. We have also implemented a prototype called NoInjection as
a Patch to PhoneGap in Android to defend against the attack.
Categories and Subject Descriptors
D.4.6 [OPERATING SYSTEMS]: Security and Protection; D.2.5
[SOFTWARE ENGINEERING]: Testing and Debugging—Code
inspections and walk-throughs
General Terms
Security
Keywords
HTML5-based Mobile Application; Code Injection; Static Analy-
sis
1. INTRODUCTION
Smartphones have grown to become very popular over the years.
A report from comScore [19] in February 2013 shows that smart-
phones surpass 50 percent penetration and break into “late major-
ity” of adopters. All these facts have led many developers to switch
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
CCS’14, November 3–7, 2014, Scottsdale, Arizona, USA.
Copyright 2014 ACM 978-1-4503-2957-6/14/11 ...$15.00.
http://dx.doi.org/10.1145/2660267.2660275 .
to develop mobile applications (apps). However, to support differ-
ent platforms, developers may need to develop different versions
of apps based on the language used in the system, such as Java
in Android and Object C in iOS. Using HTML5-based techniques
to develop mobile apps provides a good solution to overcome this
limitation. Unlike native apps, these apps are built on standard web
technologies such as HTML5, CSS and JavaScript, which are uni-
versally supported by all mainstream mobile systems. Porting such
apps from one platform to another is greatly simplified [10, 33].
With the increasing support for HTML5, HTML5-based mobile
apps are becoming more and more popular [7, 9, 17]. A survey
from Evans Data shows that among the 1,200 surveyed developers,
75% are using HTML5 for app development [1].
Unfortunately, the web technology has a dangerous feature: it
allows data and code to be mixed together, i.e., when a string con-
taining both data and code is processed by the web technology, the
code can be identified and sent to the JavaScript engine for execu-
tion. This feature is made by design, so JavaScript code can be em-
bedded freely inside HTML pages. This feature has led to the wide-
spread code injection attack, called Cross-Site Scripting (XSS), on
web applications. Built upon the same technology as web appli-
cations, HTML5-based mobile apps are subject to the similar code
injection attacks.
However, we have found out that code injection attacks against
HTML5-based mobile apps are significantly different from the XSS
attack in terms of code injection channels: Web applications only
have one channel for code injection; that is through the web server
(or web site), which is why it is called “cross-site”. HTML5-based
apps have many channels for code injection, because mobile apps
interact with other entities via many data channels, including bar-
code, SMS, file system, Contact, Wi-Fi, NFC, etc. We have found
that all these channels can be used for attacks. More specifically,
we have found that a vulnerable HTML5-based app can be compro-
mised by simply scanning a 2D barcode, reading data from Contact
list, displaying information from MP3 music, or even scanning for
Wi-Fi access points. These attacks affect all major mobile plat-
forms, including Android, iOS, Windows Phone, etc. We have con-
ducted a systematic study to identify all the potential attack chan-
nels. We have built demonstration videos to show the feasibility of
the attacks [5].
To evaluate the prevalence of this vulnerability in Android apps,
we have developed a detection tool to conduct large-scale static
analysis on Android apps. An app is vulnerable when it reads from
a code injection channel and renders the input using an unsafe API.
We transform the detection problem into an equivalent onerror="2 navigator.geolocation.watchPosition(
3 function(loc){
4 m=’Latitude:’+loc.coords.latitude+
5 ’\n’+’Longitude:’+loc.coords.longitude;
6 alert(m);
7 b=document.createElement(’img’);
8 b.src=’http://128.***.213.66:5556?c=’+m })>
The above code uses Geolocation.watchPosition() to
steal the device’s geolocation. The API registers a handler function
that will be called automatically each time the position of the device
changes. From the code, we can see that when the handler function
is invoked, the location information is stored in the variable loc,
and displayed at Line 6. At Lines 7 and 8, loc’s content is sent to
an outside computer 1.
We scan the QR code using pic2shop. Immediately, a window
pops up, displaying the user’s current GPS location (Figure 3(b)).
This indicates that the JavaScript code in the QR code has been
injected into the device and successfully triggered. We then put the
phone in the pocket, and took a walk in the campus. The phone kept
sending its locations back to the “attacker”, who simply plotted
them on Google Map (Figure 3(c)).
1In this QR code, we intentionally used an invalid IP address
128.***.213.66 to ensure that the location will never be sent
out even if readers scan the QR code using a vulnerable app.
3
From this example, it is not difficult to see how the code gets into
the victim’s device, but it is not clear how the code gets triggered.
There is another critical condition for the above attack to work: the
QR code needs to be displayed by the app. If app developers are
not careful and choose a wrong way to display the QR code, they
may end up executing the JavaScript code inside the QR code. This
is exactly the case in pic2shop.
Let us summarize the key characteristics of the vulnerability ex-
ploited by the above attack. For an HTML5-based app to be vul-
nerable to the XSS-like attack, it needs to satisfy the following two
conditions:
• The app needs to use a channel to get data from outside (out-
side of the app or device). In Section 3.2, we present a sys-
tematic study of these potential channels.
• The data from outside need to be displayed inside the HTML5
page. There are many ways to display data; some are safe,
and some are not. Section 3.3 will discuss this in details.
3.2 Code Injection Channels
Any channel that mobile apps use for getting data from outside
of the program can be used for code injection, and some channels
are more obvious than the other. We have conducted a systematic
study on these channels, and have confirmed that they can indeed
be used for the attack. We divide them into two categories: the
external channel and the internal channel, referring to whether the
data come from outside of the device or from inside.
3.2.1 External Code Injection Channels
Just like other apps, HTML5-based mobile apps need to inter-
act with the outside world, including the environment, users, other
devices, etc. These interaction channels, intended for data, can be
used for code injection. We can further divide them into three cate-
gories. The web channel is not included, because that is the channel
used by the traditional XSS attacks.
Data Channels Unique to Mobile Devices. Other than get-
ting data from the Internet, Wi-Fi, and Bluetooth, mobile devices
also get data from many channels that are not very common in tra-
ditional computers. For example, most smartphones can scan 2D
barcodes (using camera), receive SMS messages, and some
smartphones can read RFID tags (NFC). These data channels
make it very convenient for users to get information from outside,
so they are being widely used by mobile applications. In our stud-
ies, we find out that if these mobile applications are developed us-
ing the HTML5-based technology, all these data channels can be
used for injecting code. Malicious JavaScript code can be embed-
ded in the contents of 2D barcodes, RFID tags and SMS messages.
See our attack demo using SMS and 2D barcode in [5].
Metadata Channels. A very popular type of apps on mobile
devices is the media-play apps, such as audio players, video play-
ers, and picture viewers. The main functionality of these apps is to
view media files, which are often downloaded from the Internet or
shared among friends. Since they mostly contain audio, video, and
images, it does not seem that they can be used to carry JavaScript
code. However, most of these files have additional fields called
metadata, and they are good candidates for code injection. MP3,
MP4, and JPEG files are standard formats for multimedia files,
and they all contain metadata fields, such as title, artist, album,
etc. Attacker can inject malicious code into these metadata fields.
When these metadata are displayed—as they often are—in vulner-
able HTML5-based apps, the malicious code will get executed. See
our attack demo using MP3 in [5].
ID Channels. This type of channels is less obvious. When a
mobile device needs to establish a connection (e.g. Wi-Fi or Blue-
tooth) with an external entity, it first conducts a scan to find the IDs
from the nearby devices. These IDs are often displayed to the users,
so they can choose the right one to connect. These IDs, provided by
the untrusted external entity, can be used as a code injection chan-
nel, so code injection can happen before the connection is actually
established. In other words, by simply scanning for Wi-Fi access
points or Bluetooth devices, an HTML5-based app can be attacked.
To launch the attack, attackers can configure an Android phone
so it functions as a WiFi access point; they then embed their ma-
licious JavaScript code in the SSID of the access point. When an
HTML5-based app scans for Wi-Fi access points, the SSID will
often be displayed to the user, so the JavaScript code inside the
SSID can be potentially triggered. Similarly, the attacker can also
turn a mobile device into a Bluetooth device, embed a malicious
JavaScript code in its device name, and broadcast the name to nearby
devices. Any mobile device that is trying to pair with a Bluetooth
device (not necessarily the attacker’s one) can be potentially af-
fected.
This type of channels does pose a challenge because of their size
limitation. For example, SSID is limited to 32 bytes, which is not
enough to include a meaningful piece of JavaScript code. To re-
solve this issue, attackers can break up the malicious JavaScript
code into multiple pieces, each within the 32-byte limit. For ex-
ample, if the entire code consists of "P1 P2 P3", it can be bro-
ken into the following four pieces: "A=P1", "B=P2", "C=P3",
and "eval(A+B+C)". The attacker can periodically change the
value of the SSID to one of these four pieces. If somebody is scan-
ning, he/she will end up getting all the four pieces. The execution
of these four pieces is equivalent to executing "P1 P2 P3". See
our attack demo using Wi-Fi access points in [5].
3.2.2 Internal Channels
In addition to interacting with the outside world, mobile apps
often interact with other apps on the same device. Therefore, if a
malicious app is installed on the victim’s device but its privilege is
limited, this app can inject malicious JavaScript code into vulner-
able HTML5-based apps that have more privileges, hence achiev-
ing privilege escalation. We have conducted a systematic study on
these internal channels, and we divide them into three categories
(our discussion only focuses on Android, but similar consideration
can be made to iOS and Windows Phone).
Content Provider. Content Provider is typically used by An-
droid apps to store data that can be shared among apps. Because
of its ...="">. When
the app needs to display potentially dangerous data, it can display
the data in this field; JavaScript code will not be triggered. (2) An
app can use alert() to display data to users in a separate win-
dow, instead of inside the same HTML page. This call does not
trigger JavaScript code. (3) An app can invoke the default browser
to display untrusted data, instead of displaying data inside the app.
This way, even if the JavaScript code is invoked, the damage is
limited to the default system browser, which does not have much
privilege.
5.2 Framework-Level Mitigation
As we describe in Section 2, The PhoneGap framework con-
sists of two parts: bridge and plugin. The bridge part connects
JavaScript and native code, while the plugin part is used to directly
access different types of resources, such as Camera, SMS, Con-
tacts, etc. Plugins can be developed by third parties.
To mitigate code injection, we can implement filters inside the
framework, because all the data have to pass through the bridge
and plugins. We have two choices. One choice is to place the filter
inside plugins, and the other is to place the filter inside the bridge.
5.3 System-Level Mitigation
A well-known system-level solution designed to defeat XSS at-
tacks is called Content Security Policy (CSP) [49, 52]. CSP en-
forces a fairly strong restriction on JavaScript by disallowing in-
line JavaScript and eval(). CSP can be used to defeat the code
injection attack identified in this paper, but CSP is not yet fully
supported by WebView. The code that implements CSP can be
found in WebKit, which is the basis for WebView, but it is not clear
whether, if at all, WebView will enable CSP, because CSP is quite
restrictive, and enforcing it may break many existing apps, espe-
cially those that have inline JavaScript code. A great amount of ef-
forts are needed to rewrite the existing apps once CSP is enforced.
5.4 Our Implementation
After comparing the above approaches from the practicality as-
pect, we chose to implement the framework-level mitigation, be-
cause this is the most practical solution: it does not involve operat-
ing system modification, while still being transparent to apps. We
just need to convince the PhoneGap group to adopt this approach,
or convince app developers to use our modified PhoneGap library.
We have implemented a prototype called NoInjection as a patch
to the PhoneGap framework in Android. Its main design princi-
ple is to add a filter inside the bridge, right after the data enter the
bridge from plugins (see Figure 1 for the architecture of Phone-
Gap). This implementation is transparent to plugins, as well as to
apps. App developers do need to download our revised PhoneGap
library (called cordova.jar) when compiling their code. This
library can be downloaded from our web site [5].
For the filtering part, we simply use an open-source library called
jsoup. jsoup is an HTML parser implemented in Java; it pro-
vides an API called clean() to filter out JavaScript code from
a string. This library has been tested quite extensively, and it can
filter out JavaScript code that is embedded in a variety of ways.
Therefore, the effectiveness of our solution depends on the jsoup
library. Moreover, jsoup also provides a whitelist mechanism to
allow some valid HTML tags. This mechanism allows us to filter
out all the JavaScript code, while keeping the valid HTML tags,
e.g., we can keep the img tag if it does not have an event attribute.
Overall, our implementation of NoInjection adds only 148 lines
of Java code to PhoneGap, plus the jsoup library. To measure the
performance overhead of NoInjection, we benchmarked the modi-
fied PhoneGap against the original PhoneGap. We called each plu-
gin’s API 1000 times to get the average time spent on each invo-
cation. The results show that the modified PhoneGap takes 2.675
ms for each call, and the original PhoneGap takes 2.435 ms. The
overhead for our implementation is 9.85% for each call. Since these
invocations only contribute to a small portion of the overall running
time, the overhead caused by our work is quite insignificant.
Theoretically, our solution should be able to apply to the exist-
ing PhoneGap apps, by replacing their PhoneGap library with our
revised one. However, in practice, this is hard, because most of
the PhoneGap apps use older versions of PhoneGap library, while
our revision is conducted on the most recent version. To apply our
solutions to the existing PhoneGap without recompiling the app,
we need to patch the corresponding PhoneGap versions. While our
solution can benefit new PhoneGap apps, it does show a limitation
when dealing with the existing PhoneGap apps.
9
6. RELATED WORK
6.1 XSS Attack Detection and Mitigation
Due to the high practical prevalence, XSS attacks have been
studied by a lot of researchers. Here we will focus on the client-side
XSS attack detection and mitigation, because some work may help
detect and mitigate the code injection attacks on HTML5-based
mobile applications if they are properly used.
Detection on XSS Attack A series of works use static and dy-
namic analysis to detect XSS vulnerabilities. Vogt et al. [50] use
taint-analysis to track the flow of sensitive information inside web
browsers. Saxena et al. [46] propose a system called Flax that uses
“taint enhanced blackbox fuzzing" to find command and code in-
jection vulnerabilities in JavaScript. Sebastian et al. [38] directly
integrate tainting techniques into the browser’s JavaScript engine
to track unsafe data flows. DOMinator [23] uses Firefox’s Spider-
Monkey Javascript engine to understand the code. It keeps a call
stack on user controllable strings and raises alert when these strings
are passed into the sinks. IceShield [30] performs dynamic analy-
sis of JavaScript code in browsers to detect code injection attacks.
Rozzle [37], a JavaScript multiexecution VM, explores multiple
execution paths within a single execution to expose environment-
specific malware. These works may help detect the code injection
attacks on HTML5-based mobile applications. However, defining
source entries for HTML5-based mobile applications still remains
as a challenge.
Mitigation on XSS Attack One way to mitigate XSS attack is to
use sanitization mechanisms. The key challenge is how to identify
the code mixed in data. Several approaches have been proposed
to address this challenge, including XSS Auditor [20], Bek [32],
CSAS [45], ScriptGard [47], etc. We can adopt some of the saniti-
zation methods to remove script from string to prevent the attack;
however, the challenge is where to place the sanitization logic. Our
prototype chooses to implement the logic at the framework level,
because it is the most practical solution.
Another way to mitigate XSS attacks is to limit the damage caused
by the code injection attack, rather than preventing it. Content Se-
curity Policy [49, 52] is the representative of this category, and it
was discussed in Section 5. ConScript [42] and Escudo [34] also
defines policy to limit privilege of the script in some specific DOM
elements. They have the same problem as CSP, which requires sig-
nificant code rewriting for the existing apps.
6.2 Static Analysis of Android Vulnerabilities
Recently, some works use static analysis tools to detect vari-
ous vulnerabilities in Android systems. Stowaway [26] finds over-
privileged apps that require additional permissions beyond normal
functionalities. Woodpecker [28] analyzes preloaded apps in the
phone firmware to expose capability leaks on stock Android phones.
ContentScope [55] focuses on passive content leak and content pol-
lution vulnerabilities. SMV-HUNTER [48] and MalloDroid [25]
can be used to detect the apps that are vulnerable to SSL/TLS Man-
in-the-Middle attacks. Sebastian et al. analyze unsafe and mali-
cious code loading in Android applications [43]. CHEX [39] de-
tects applications that expose components to other applications in
an insecure way. AppIntent [53] addresses the unintended sensitive
data transmission. AppSealer [54] combines static and dynamic
code analysis to mitigate component hijacking attacks. Karim et
al. [24] present an efficient approach to identify malicious Android
applications through specialized static program analysis. Com-
pared to these studies, our work is the first one to address the code
injection problem in HTML5-based mobile apps.
6.3 Other Related Attacks.
Some other attacks are also related to our work. mXSS [31]
attack can bypass XSS filters by taking advantage of innerHTML’s
mutation. XCS [21] finds some interesting channels to ship the
code, such as printer, router and digital photo frame etc. Once the
code is loaded in the web browser, it will get executed. In our work,
most of the channels are quite unique to mobile platforms.
A work-in-progress version of our work has appeared in a work-
shop paper [35]; however, that paper only focuses on describing
how the attack works, while this submission includes the following
significant contributions that are not covered by the workshop ver-
sion: (1) We have developed a detecting tool, using which we have
conducted a large-scale analysis of over 15,510 HTML5-based (Ph-
oneGap) apps; we have discovered 478 vulnerable apps. The work
in the workshop paper used manual effort, and only found less than
10 vulnerable apps. (2) We have developed a mitigation solution
that can be immediately adopted by PhoneGap app developers or
the PhoneGap framework. (3) We have extended the attacks to in-
clude internal channels, which are different from the external chan-
nels identified by the workshop paper.
Several studies have also analyzed the security of WebView and
PhoneGap [27, 36, 40, 51]. Georgiev et al. [27] and Jin et al. [36]
address the problem caused by the code coming from untrusted ori-
gins. The solutions limit the privilege of the untrusted code by not
allowing it to access local mobile resources. However, these solu-
tions are not suitable to defend our code injection attack, because
in our cases, app developers do not even know that there may be
code inside the data.
7. SUMMARY
In this paper, we study the potential risk imposed by HTML5-
based mobile applications. We have identified a number of unique
channels that can be used to inject code, including Contacts,
SMS, Barcode, etc. To assess the extent of such a vulnerabil-
ity in Android apps, we have implemented a tool to analyze 15,510
PhoneGap apps collected from the Android Market. The tool flagged
478 apps as vulnerable, with only 2.30% false positive. We have
also implemented a prototype called NoInjection as a patch to the
PhoneGap framework in Android. It can successfully filter out the
malicious code from the attack channels identified in this paper.
The tools developed from this work, the demonstration of the at-
tacks, and guidelines to users and developers can be found from
our web site [5]. In our future work, we plan to extend our detec-
tion and mitigation to non-PhoneGap HTML5-based apps.
8. ACKNOWLEDGEMENT
We would like to thank the anonymous reviewers for their valu-
able and encouraging comments. This work was supported in part
by NSF grants 1017771, 1318814, 1018217, 1054605, a Google re-
search award and McAfee Inc. Any opinions, findings, conclusions
or recommendations expressed in this material are those of the au-
thors and do not necessarily reflect the views of funding agencies.
9. REFERENCES
[1] 75% of developers using html5:survey. http:
//eweek.com/c/a/Application-Development/
75-of-Developers-Using-HTML5-Survey-508096.
[2] Appcelerator. http://appcelerator.com.
[3] appmobi. http://www.appmobi.com/.
[4] Caja.
http://code.google.com/p/google-caja/.
10
[5] Code Injection Attacks on HTML5-based Mobile Apps.
http://www.cis.syr.edu/~wedu/android/
JSCodeInjection/index.html.
[6] CVE-2013-4710. http:
//www.exploit-db.com/exploits/31519/.
[7] The future of mobile development: Html5 vs. native apps.
http://www.businessinsider.com/
html5-vs-native-apps-for-mobile-2013-4?
op=1/.
[8] How To Use the Ctemplate (formerly Google Template)
System. http://google-ctemplate.googlecode.
com/svn/trunk/doc/guide.html#auto_escape.
[9] Html5 vs. apps: Where the debate stands now, and why it
matters. http://www.businessinsider.com/
html5-vs-apps-where-the-debate-stands\
-now-and-why-it-matters-2013-4/.
[10] Html5 vs native: The mobile app debate. http://www.
html5rocks.com/en/mobile/nativedebate/.
[11] MooTools-a compact JavaScript framework.
http://mootools.net/.
[12] MoSync:Cross-platform SDK and HTML5 tools for mobile
app development. http://mosync.com.
[13] Owasp. the ten most critical web application security risks.
http://owasptop10.googlecode.com/files/
OWASP%20Top%2010%20-%202013.pdf.
[14] Phonegap. http://phonegap.com.
[15] Prototype javascript framework.
http://prototypejs.org/.
[16] Rhomobile. http://rhomobile.com.
[17] The shared future of html5 and native apps.
http://itbusinessedge.com/blogs/
data-and-telecom/
the-shared-future-of-html5-and-native-apps.
html/.
[18] The T.J. Watson Libraries for Analysis (WALA).
http://wala.sourceforge.net/.
[19] Mobile future in focus 2013. comScore, 2013.
[20] D. Bates, A. Barth, and C. Jackson. Regular expressions
considered harmful in client-side xss filters. In Proceedings
of the 19th international conference on World wide web,
pages 91–100. ACM, 2010.
[21] H. Bojinov, E. Bursztein, and D. 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.
[22] E. Chin and D. Wagner. Bifocals: Analyzing WebView
Vulnerabilities in Android Applications. In Proceedings of
the 14th International Workshop on Information Security
Applications, Ocean Suites Jeju Hotel, Jeju Island, Korea,
August 19 2013.
[23] S. Di Paola. DominatorPro: Securing Next Generation of
Web Applications. [software],.
https://dominator.mindedsecurity.com/,
2012.
[24] K. Elish, D. Yao, B. Ryder, and X. Jiang. A static assurance
analysis of android applications. Virginia Polytechnic
Institute and State University, Tech. Rep, 2013.
[25] S. Fahl, M. Harbach, T. Muders, L. Baumgärtner,
B. Freisleben, and M. Smith. Why eve and mallory love
android: An analysis of android ssl (in) security. In
Proceedings of the 2012 ACM conference on Computer and
Communications Security, pages 50–61. ACM, 2012.
[26] A. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner. Android
permissions demystified. In Proceedings of the 18th ACM
conference on Computer and Communications Security,
pages 627–638. ACM, 2011.
[27] M. Georgiev, S. Jana, and V. Shmatikov. Breaking and fixing
origin-based access control in hybrid web/mobile application
frameworks. In Proceeding of the Network and Distributed
System Security Symposium (NDSS), 2014.
[28] M. Grace, Y. Zhou, Z. Wang, and X. Jiang. Systematic
detection of capability leaks in stock android smartphones. In
Proceedings of the 19th Annual Symposium on Network and
Distributed System Security, 2012.
[29] S. Guarnieri, M. Pistoia, O. Tripp, J. Dolby, S. Teilhet, and
R. Berg. Saving the world wide web from vulnerable
JavaScript. In Proceedings of the 2011 International
Symposium on Software Testing and Analysis, pages
177–187. ACM, 2011.
[30] M. Heiderich, T. Frosch, and T. Holz. Iceshield: detection
and mitigation of malicious websites with a frozen dom. In
Proceedings of International Symposium on Research in
Attacks, Intrusions and Defenses, pages 281–300. Springer,
2011.
[31] M. Heiderich, J. Schwenk, T. Frosch, J. Magazinius, and
E. Yang. mxss attacks: attacking well-secured
web-applications by using innerhtml mutations. In
Proceedings of the 2013 ACM SIGSAC conference on
Computer and Communications Security, CCS ’13. ACM,
2013.
[32] 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.
[33] N. Huy and D. vanThanh. Evaluation of mobile app
paradigms. In Proceedings of the 10th International
Conference on Advances in Mobile Computing and
Multimedia, MoMM ’12, 2012.
[34] K. Jayaraman, W. Du, B. Rajagopalan, and S. J. Chapin.
Escudo: A fine-grained protection model for web browsers.
In Proceeding of the 30th IEEE International Conference on
Distributed Computing Systems (ICDCS), pages 231–240,
2010.
[35] X. Jin, T. Luo, D. G. Tsui, and W. Du. Code Injection
Attacks on HTML5-based Mobile Apps. In Mobile Security
Technologies (MoST) 2014, 2014.
[36] 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.
[37] C. Kolbitsch, B. Livshits, B. Zorn, and C. Seifert. Rozzle:
De-cloaking internet malware. In Proceedings of 2012 IEEE
Symposium on Security and Privacy, pages 443–457. IEEE,
2012.
[38] S. Lekies, B. Stock, and M. Johns. 25 million flows later:
large-scale detection of dom-based xss. In Proceedings of the
2013 ACM conference on Computer and Communications
Security, pages 1193–1204. ACM, 2013.
[39] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. Chex: statically
vetting android apps for component hijacking vulnerabilities.
In Proceedings of the 2012 ACM conference on Computer
and Communications Security, pages 229–240. ACM, 2012.
11
[40] T. Luo, H. Hao, W. Du, Y. Wang, and H. Yin. Attacks on
webview in the android system. In Proceedings of the 27th
Annual Computer Security Applications Conference
(ACSAC), 2011.
[41] M. Madsen, B. Livshits, and M. Fanning. Practical static
analysis of javascript applications in the presence of
frameworks and libraries. In Proceedings of the 2013 9th
Joint Meeting on Foundations of Software Engineering,
pages 499–509. ACM, 2013.
[42] L. A. Meyerovich and B. Livshits. Conscript: Specifying and
enforcing fine-grained security policies for javascript in the
browser. In Proceedings of 2010 IEEE Symposium on
Security and Privacy, pages 481–496. IEEE, 2010.
[43] S. Poeplau, Y. Fratantonio, A. Bianchi, C. Kruegel, and
G. Vigna. Execute this! analyzing unsafe and malicious
dynamic code loading in android applications. In Proceeding
of the Network and Distributed System Security Symposium
(NDSS 2014), 2014.
[44] G. Richards, S. Lebresne, B. Burg, and J. Vitek. An Analysis
of the Dynamic Behavior of JavaScript Programs. In
Proceedings of the 2010 ACM SIGPLAN Conference on
Programming Language Design and Implementation, PLDI
’10, 2010.
[45] M. Samuel, P. Saxena, and D. Song. Context-sensitive
auto-sanitization in web templating languages using type
qualifiers. In Proceedings of the 18th ACM Conference on
Computer and Communications Security (ACM CCS), 2011.
[46] P. Saxena, S. Hanna, P. Poosankam, and D. Song. Flax:
Systematic discovery of client-side validation vulnerabilities
in rich web applications. In Proceeding of the Network and
Distributed System Security Symposium (NDSS 2010), 2010.
[47] P. Saxena, D. Molnar, and B. Livshits. Scriptgard: automatic
context-sensitive sanitization for large-scale legacy web
applications. In 18th ACM Conference on Computer and
Communications Security (ACM CCS), 2011.
[48] D. Sounthiraraj, J. Sahs, G. Greenwood, Z. Lin, and
K. Latifur. Smv-hunter: Large scale, automated detection of
ssl/tls man-in-the-middle vulnerabilities in android apps. In
Proceeding of the Network and Distributed System Security
Symposium (NDSS 2014), 2014.
[49] 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 (WWW), pages
921–930. ACM, 2010.
[50] P. Vogt, 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), 2007.
[51] 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.
[52] J. Weinberger, A. Barth, and D. Song. Towards client-side
html security policies. In Workshop on Hot Topics on
Security (HotSec), 2011.
[53] Z. Yang, M. Yang, Y. Zhang, G. Gu, P. Ning, and X. Wang.
Appintent: Analyzing sensitive data transmission in android
for privacy leakage detection. In Proceedings of the 2013
ACM conference on Computer and Communications
Security, pages 1043–1054. ACM, 2013.
[54] M. Zhang and H. Yin. Appsealer: Automatic generation of
vulnerability-specific patches for preventing component
hijacking attacks in android applications. In Proceedings of
the 21th Annual Network and Distributed System Security
Symposium (NDSS 2014), 2014.
[55] Y. Zhou and X. Jiang. Detecting passive content leaks and
pollution in android applications. In Proceedings of the 20th
Annual Symposium on Network and Distributed System
Security, 2013.
12