The Unexpected Dangers of Dynamic JavaScript

Sebastian Lekies, Ruhr-University Bochum; Ben Stock, Friedrich-Alexander-Universität

Erlangen-Nürnberg; Martin Wentzel and Martin Johns, SAP SE
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies

This paper is included in the Proceedings of the

24th USENIX Security Symposium
August 12–14, 2015 • Washington, D.C.
ISBN 978-1-939133-11-3

Open access to the Proceedings of

the 24th USENIX Security Symposium
is sponsored by USENIX
 The Unexpected Dangers of Dynamic JavaScript

Sebastian Lekies Ben Stock Martin Wentzel

Ruhr-University Bochum FAU Erlangen-Nuremberg SAP SE
[email protected] [email protected] [email protected]
Martin Johns
SAP SE
[email protected]

Abstract the fly. In turn, this enabled the transformation of the

Web’s initial document-centric nature into the versatile
Modern Web sites frequently generate JavaScript on-the- platform that we know today.
fly via server-side scripting, incorporating personalized
2. Browser-driven Web front-ends: Furthermore, the
user data in the process. In general, cross-domain access
Web browser has proven to be a highly capable container
to such sensitive resources is prevented by the Same-
for server-provided user interfaces and application logic.
Origin Policy. The inclusion of remote scripts via the
Thanks to the flexible nature of the underlying HTML
HTML script tag, however, is exempt from this policy.
model and the power of client-side scripting via Java-
This exemption allows an adversary to import and exe-
Script, the server can push arbitrary user interfaces to the
cute dynamically generated scripts while a user visits an
browser that rival their counterparts of desktop applica-
attacker-controlled Web site. By observing the execution
tion. In addition, and unlike monolithic desktop appli-
behavior and the side effects the inclusion of the dynamic
cations, however, browser-based UIs enable easy incor-
script causes, the attacker is able to leak private user data
poration of content from multiple parties using HTML’s
leading to severe consequences ranging from privacy vi-
inherent hypertext capabilities.
olations up to full compromise of user accounts.
Based on this foundation, the recent years have shown
Although this issues has been known for several years
an ongoing shift from Web applications that host the ma-
under the term Cross-Site Script Inclusion, it has not
jority of their application logic on the server side towards
been analyzed in-depth on the Web. Therefore, to sys-
rich client-side applications, which use JavaScript to re-
tematically investigate the issue, we conduct a study on
alize a significant portion of their functionality within the
its prevalence in a set of 150 top-ranked domains. We
user’s browser.
observe that a third of the surveyed sites utilize dynamic
With the increase of the functionality implemented on
JavaScript. After evaluating the effectiveness of the de-
the client side, the necessity for the JavaScript code to
ployed countermeasures, we show that more than 80%
gain access to additional user data rises natrually. In this
of the sites are susceptible to attacks via remote script
paper, we explore a specific technique that is frequently
inclusion. Given the results of our study, we provide a
used to pull such data from the server to the client-side:
secure and functionally equivalent alternative to the use
Dynamic JavaScript generation.
of dynamic scripts.
Similar to HTML, which is often generated dynam-
ically, JavaScript may also be composed on the fly
1 Introduction through server-side code. In this composition process,
user-specific data is often included in the resulting script
Since its beginning in the early nineties, the Web evolved code, e.g., within the value of a variable. After deliv-
from a mechanism to publish and link static documents ering the script to the browser, this data is immediately
into a sophisticated platform for distributed Web applica- available to the client-side logic for further processing
tions. This rapid transformation was driven by two tech- and presentation. This practice is potentially dangerous
nical cornerstones: as the inclusion of script files is exempt from the Same-
1. Server-side generation of code: For one, on the Origin Policy [23]. Therefore, an attacker-controlled
server side, static HTML content was quickly replaced Web page is able to import such a dynamically gener-
by scripting to dynamically compose the Web server’s ated script and observe the side effects of the execu-
HTTP responses and the contained HTML/JavaScript on tion, since all included scripts share the global object

USENIX Association 24th USENIX Security Symposium 723

of the embedding web document. Thus, if the script 2 Technical Background
contains user-specific data, this data might be accessi-
ble to other attacker-controlled JavaScript. Although this In this section, we cover the technical background rele-
attack, dubbed Cross-Site Script Inclusion (XSSI), has vant for this work.
been mentioned within the literature [31], the prevalence
of flaws which allow for this attack vector has not been 2.1 The Same-Origin Policy
studied on real-world Web sites.
In this paper we therefore present the first, systematic The Same-Origin Policy (SOP) is the principal security
analysis of this vulnerability class and provide empirical policy in Web browsers. The SOP strongly separates mu-
evidence on its severeness. First, we outline the general tually distrusting Web content within the Web browser
attack patterns and vectors that can be used to conduct through origin-based compartmentalization [23]. More
such an attack. Furthermore, we present the results of an precisely, the SOP allows a given JavaScript access only
empirical study on several high-profile domains, show- to resources that have the same origin. The origin is de-
ing how these domains incorporate dynamic scripts into fined as the triple consisting of scheme, host, and port
their applications. Thereby, we find evidence that many of the involved resources. Thus, for instance, a script
of these scripts are not or only inadequately protected executed under the origin of attacker.org is not able
against XSSI attacks. We demonstrate the sever conse- to access a user’s personal information rendered under
quences of these data leaks by reporting on real-world webmail.com.
exploitation scenarios ranging from de-anonymization, While JavaScript execution is subject to the SOP, the
to targeted phishing attacks up to complete compromise same does not hold true for cross-domain inclusion of
of a victim’s account. Web content using HTML tags. Following the initial hy-
To summarize, we make the following contributions: pertext vision of the WWW HTML-tags, such as image,
may reference resources from foreign origins and include
• We elaborate on different ways an attacker is capa- them into the current Web document.
ble of leaking sensitive data via dynamically gener- Using this mechanism, the HTML script tag can
ated scripts, enabled by the object scoping and dy- point to external script resources, using the tag’s src at-
namic nature of JavaScript. tribute. When the browser encounters such a tag, it issues
• We report on the results of an empirical study a request to the foreign domain to retrieve the referenced
on several high-ranked domains to investigate the script. Important to note in this instance is the fact that
prevalence of dynamic scripts. the request also carries authentication credentials in the
form of cookies which the browser might have stored for
• Using the data collected during our empirical study, the remote host. When the response arrives, the script
we show that many dynamic scripts are not properly code inherits the origin of the including document and is
protected against XSSI attacks. To demonstrate the executed in the context of the hosting page. This mecha-
severity of the outlined vulnerabilities, we present nism is used widely in the Web, for instance to consume
different exploitation scenarios ranging from de- third party JavaScript services, such as traffic analysis or
anonymization to complete hijacking of a victim’s advertisement reselling [24].
account.

• Based on the observed purposes of the dynamic 2.2 JavaScript Language Features
scripts encountered in our study, we discuss secure In the following, we cover the most important JavaScript
ways of utilizing such data without the use of dy- concepts necessary for the rest of the paper.
namically generated scripts.

The remainder of the paper is structured as follows: In Scoping In JavaScript, a scope is “a lexical environ-
Section 2, we explain the technical foundations needed ment in which a function object is executed” [6]. From a
for rest of the paper. Section 3 then covers the general at- developer’s point of view, a scope is the region in which
tack patterns and techniques to exploit cross-domain data an identifier is defined. While C++ or Java make use
leakage vulnerabilities. In Section 4, we report on the re- of block scoping, JavaScript utilizes so-called function
sults of our empirical study and analyze the underlying scoping. This means that the JavaScript engine creates
purposes of dynamic scripts. Furthermore, in Section 5, a new scope for each new function it encounters. As a
we provide a scheme that is functionally equivalent, but consequence, an identifier that is locally defined in such
is not prone to the attacks described in this paper. Sec- a function is associated with the corresponding scope.
tion 6 covers related work, Section 7 gives an outlook Only code that is defined within the same function is thus
and Section 8 concludes the paper. able to access such a variable residing in the local scope,

724 24th USENIX Security Symposium USENIX Association

whereas global variables are associated with the global 3 Cross-Domain Data Leakages
scope.
Listing 1 shows an example for local and global vari- In this section, we show how an adversary can utilize
ables. A local variable in JavaScript can be created by an external JavaScript file, which is dynamically gener-
utilizing the var keyword. All variables defined out- ated at runtime, to leak security sensitive data. After first
side of a function are associated with the global scope, covering the different types of these dynamic scripts, we
whereas code within a function can define variables in elaborate on the attacker model and then demonstrate dif-
the global scope by either omitting the var keyword or ferent attack vectors that can be leveraged to leak sensi-
explicitly assigning to window.varname. tive data from such a script.

Listing 1 Example for global and local variables 3.1 Dynamic Scripts
// A global variable
var globalVariable1 = 5; As discussed in Section 2.1, Web pages can utilize
script-tags to import further JavaScript resources. For
function globalFunction(){ the remainder of this paper, we define the term dynamic
// A local variable
var localVariable = 2;
script to describe such a JavaScript resource in case it
is generated by the Web server on the fly via server-side
// Another global variable code.
globalVariable2 = 3; As opposed to static scripts, the contents of dynamic
// Yet another global variable scripts may vary depending on factors such as input pa-
window.globalVariable3 = 4; rameters or session state. In the context of this paper, the
} latter type is of special interest: If a dynamic JavaScript
is generated within a user’s authenticated Web session,
the contents of this script may contain privacy or secu-
rity sensitive data that is bound to the user’s session data.
Thus, an execution of the script can potentially lead to
The Prototype Chain As opposed to classical pro- side effects which leak information about this data.
gramming languages such as C++ or Java, JavaScript is a
prototype-based language. This means that JavaScript’s
inheritance is not based on classes but directly on other 3.2 Attack Method
objects, whereas “each object has a link to another ob- HTML script tags are not subject to the Same-Origin
ject called its prototype” [21]. On creation of an object, Policy (see Section 2.1). Hence, script resources can be
it either automatically inherits from Object.prototype embedded into cross-domain Web pages. Although such
or if a prototype object is explicitly provided, the proto- cross-domain Web pages cannot access the source code
type property will point to this object. On access to an of the script directly, this inclusion process causes the
object’s property, the JavaScript runtime checks whether browser to load and execute the script code in the context
the current object contains a so-called own property with of the cross-domain Web page, allowing the importing
the corresponding name. page to observe the script’s behavior. If a dynamic script
If no such property exists, the object’s prototype is exposes side effects dependent on sensitive data in the
queried for the same property and if lookup fails again, script code, the execution of such a script may leak the
the process is recursively repeated for the object’s pro- secret data.
totypes. Hence, objects in JavaScript form a so-called Figure 1 depicts an example attack. A user is au-
prototype chain. Listing 2 gives a commented example thenticated to his mail provider at webmail.com, thus
for this behavior. his browser automatically attaches the corresponding
session cookies to all requests targeting webmail.com,
Listing 2 The prototype chain which utilizes session-state dependent dynamic scripts.
var object1 = {a: 1}; Thus, whenever a user is logged in, the script at
// object1 ---> Object.prototype ---> null webmail.com/script.js creates a global variable
var object2 = Object.create(object1);
containing the current user’s email address. In the
// object2 ---> object1 same browser, the user now navigates to an attacker-
// ---> Object.prototype ---> null controlled Web site at attacker.org. The attacker in-
console.log(object2.a); // 1 (inherited) cludes the dynamic script in his own Web page and sub-
sequently, the browser requests the script with attached
authentication cookies. Although the script originates

USENIX Association 24th USENIX Security Symposium 725

 h"p://a"acker.org   may overwrite it beforehand and hence retrieve the se-
cret value. Listing 3 demonstrates how an attacker can,
for example, change the behavior of the global function
JSON.stringify. In order to conduct an attack, the at-
tacker overrides the function first and then includes a dy-
Browser   namic script which passes a sensitive data value to the
h"p://a"acker.org  
function. When the user visits the attacker’s Web site,
his browser retrieves and executes the dynamic script.
h"p://webmail.com   Rather than invoking the native JSON.stringify func-
tion, the contained code invokes the attacker-controlled
function. In this case, instead of serializing the object,
the function sends the user’s data back to the attacker’s
JavaScript   server.

Listing 3 Passing a variable to a global function

Figure 1: Attacker Model // Attacker’s script overwriting a global function
JSON.stringify = function(data){
sendToAttackerBackend(data);
}
from webmail.com, it is now executed in the context
of attacker.org, creating the global variable with the ---------------------------------------------------
user’s email in the corresponding context. The global //Within the dynamic script
variable is now accessible to any other script executed function myFunction() {
var myVar = { secret: "secret value"};
by attacker.org. Hence, the attacker can simply ac-
cess the value of this global variable, effectively leaking // Calling a predefined global function
the user’s email address. return JSON.stringify(myVar);
}

3.3 Attack Vectors

As previously explained, an attacker is able to leak sen-
sitive user data by including a script from a different do- 3.3.3 Prototype Tampering
main and observing the results of the execution. In this As outlined in the previous section, variables are avail-
section we outline different situations in which sensitive able in the scope in which they were defined unless the
data is accessible to an attacker after the included script var keyword is omitted. Listing 4 shows an example of
has been executed. code making use of this paradigm. The function allocates
an array with three secret values using the var keyword
3.3.1 Global Variables and therefore, as it seems, protects the array from access
by outside code. As discussed in Section 2.2, JavaScript
As noted in the previous section, global variables created is a prototype-based language. Hence, when requesting
by a dynamic script can be accessed by any other script a property of an object, the JavaScript interpreter walks
executed on the same Web document. Hence, whenever up the prototype chain until it finds a matching property.
sensitive user data is assigned to such a global variable In our example shown in Listing 4, the function slice
inside a script, an attacker can gain access to the corre- is called on the array named arr. By default, an array
sponding data. In order to do so, he simply includes the object does not provide the slice function itself. There-
script and waits for the global variable to be created. As fore, the call is made to the function in the array’s proto-
soon as the value assignment has occurred, the attacker’s type, which points to the object Array.prototype. In
code can read the sensitive data and leak it back to his a scenario where the script is included without any ma-
backend. licious intent, the programmer may assume that the call
will eventually trigger invocation of the slice method
3.3.2 Redefinition of Global APIs for arrays.
This behavior may, however, be changed by an at-
Due to JavaScript’s dynamic nature, (almost) any func- tacker. Listing 5 depicts a small snippet of code that is
tion can be overwritten by an attacker, including a num- provided by the attacker. Similar to what we discussed
ber of globally available APIs. If a dynamic script passes earlier with respect to overwriting global functions, the
a security-sensitive value to such a function, the attacker snippet overwrites the slice method in the array’s pro-

726 24th USENIX Security Symposium USENIX Association

Listing 4 Variable protected in a closure 4 Empirical Study
(function(){
var arr = ["secret1","secret2","secret3"]; In this section we report on the results of an empirical
// intents to slice out first entry study designed to gain insights into the prevalence and
var x = arr.slice(1);
... exploitability of data leakages due to the use of dynamic
})(); script generation on the server side. We first discuss
the methodology of our study and report on the general
prevalence of dynamically generated JavaScript files in
the wild. Based on the gathered data, we analyze the un-
totype. Since by default all arrays in JavaScript share the derlying purposes of these scripts, discuss the types of
same prototype, the call to slice in Listing 4 is passed security-sensitive data contained in the scripts and high-
to the attacker-provided function. Since the function is light who these can be leaked, allowing us specific ex-
called on the arr object, the attacker can use the this ploits against a number of sites. We end the section with
keyword to gain a reference to the object. Therefore, a discussion of situations in which we could not exploit
rather than exhibiting the intended behavior of slicing a dynamic script due to the use of adequate protection
out a part of the array, the attacker’s code now sends the measures.
otherwise properly protected information back to the at-
tacker. This attack works for any object that has a glob-
ally accessible prototype, i.e., it is feasible on any built-in 4.1 Methodology
objects such as Strings or Functions. In the following, we cover our research questions, ex-
plain our detection methodology and describe our data
Listing 5 Leaking data via the this keyword set.
Array.prototype.slice = function(){
//leaks ["secret1","secret2","secret3"]
sendToAttackerBackend(this); 4.1.1 Research Questions
};
This study provides an in-depth analysis of dynamic
script includes. Before diving into the security aspects of
these scripts, we aim at collecting data on this technique
in general. Hence, we are first interested in the gen-
3.4 Distinction towards CSRF eral prevalence of dynamically generate scripts. More
specifically, the goal is to find out how common dynamic
On first view, the described attack method is related to script generation is in today’s Web and how often these
Cross-site Request Forgery (CSRF) [1], as it follows a dynamic scripts are dependent on a user’s session state.
similar attack pattern. The study sheds light on the purpose of these scripts and
In fact, leaking sensitive information via cross-domain the contained data. Finally, we investigate the security
script includes belongs to a larger class of Web attacks aspects by investigating the exploitability and discussing
which function via creating authenticated requests in the potential countermeasures.
context of an authenticated Web user (including CSRF,
ClickJacking [12] and reflected Cross-site Scripting [2]). 4.1.2 Detecting State-dependent Scripts
However, the goal and consequences of the attack dif-
fer significantly from other attack variants: CSRF is an As a basis for our empirical study, we needed a means to
attack in which an attacker generates requests to cause easily detect state-dependent dynamic scripts. Therefore,
state-changing actions in the name of the user. Thereby we implemented a Chrome browser extension that fulfills
the attacker is by no means able to read content from a two separate tasks:
response to a CSRF request. To prevent CSRF devel-
1. Collecting scripts: The first step towards analyz-
opers are advised to conduct state-changing actions only
ing Web pages for dynamic scripts is the collection
via HTTP POST requests and to protect all these post
of all external script resources included by the Web
requests with CSRF tokens.
page. For this purpose, we created a browser ex-
As opposed to this, dynamic scripts are neither de-
tension that collects all included scripts of a page
signed to conduct state-changing actions on the server-
by using a so-called Mutation Observer [22]. As
side nor are these scripts ever fetched via POST requests.
soon as a new script node is found, it is immediately
Those scripts are stateless and are fetched via GET re-
passed on to our analysis module.
quests through script tags and, hence, are not classified
as a critical endpoint in the context of CSRF, i.e., not 2. Detecting dynamic code generation based on au-
contained in the application’s CSRF protection surface. thentication credentials: Whenever the analysis is

USENIX Association 24th USENIX Security Symposium 727

 invoked, our extension requests the script file twice: methodology, we gathered a total of 9,059 script files
once with authentication credentials attached to the spread across 334 domains and their subdomains. Al-
request, and once without authentication creden- though our data set only consists of 150 different do-
tials. After the responses have been received, the mains, we gathered scripts from such a large number of
extension compares both and if they differ, stores domains due to the fact that the investigated Web sites in-
them in a central database for later analysis. clude third-party frames pointing to, e.g., advertisement
In order to allow for valid credentials to be sent providers. In a first step, we therefore filtered out scripts
along with the request, a necessary prerequisite are from all sites not directly related to the domains under
valid session cookies. To obtain these, the user investigation.
needs to manually log in to the application under Out of these, we found that over half of the sites—81
investigation beforehand. out of the 150 analyzed domains—utilized some form of
dynamic script generation. In a subsequent manual ex-
The final step in this phase is the manual analysis
amination step we removed dynamic scripts which only
of the gathered data to precisely determine which
exposed changes in apparently random token values (see
scripts have a dynamic nature depending on the
below for details), resulting in 209 unique scripts on 49
user’s session state rather than randomness (such as
domains, that were dependent on a user’s session state.
banner rotation scripts).
In relation to our initial data set of 150 domains, this
shows that the usage of state-dependent dynamic scripts
4.1.3 Data Set is widespread, namely one third of the investigated do-
Unlike general vulnerabilities, the detection of potential mains.
data leakages through dynamic JavaScript generation re-
quires an active user account (or a similar stateful rela-
tionship) at the tested site, so that the scripts are gener- 4.3 Purposes of Dynamic Scripts
ated in the context of an authenticated Web session.
Since this requires initial manual registration and ac- We analyzed the applications to ascertain the underlying
count set up on sites we want to test, the size and the na- purpose motivating the utilization of the dynamic scripts.
ture of our data set is limited. We therefore chose the 150 In doing so, we found three categories of use cases as
highest ranking (according to Alexa) Web pages match- well as a few purposes which could not be categorized.
ing the following criteria: Since these were only single use cases specific to one
application, we do not outline these any further but in-
1. Account registration and login is freely available for stead put them in the Others category. The results of our
anyone. This excludes, services that have only paid categorization are depicted in Table 1, showing the total
subscription models or require country-dependent amount of domains per category as well as the highest
prerequisites (such as a mobile phone number). Alexa rank.
The most commonly applied use case was retrieval
2. Available in either German, English or a Web site of user-specific data, such as the name, email address
which can be translated using Google Translate. If or preferences for the logged-in user. This information
this is not given, the set up of meaningful user ac- was used both to greet users on the start page as well as
counts was not feasible. to retrieve user-provided settings and profile data on the
3. Not a duplicate or localized variant of an already corresponding edit pages. We observed that a number
investigated site (e.g. google.com vs. google.co.in) of Web applications utilized modal dialogs to present the
profile data forms to the user, whereas the HTML code of
After manually registering accounts on these sites, said form was embedded into the document already and
we investigated the site employing the methodology and all currently stored values were retrieved by including a
techniques previously explained, thoroughly interacting dynamic script.
with the complete functionality of the sites by adding, The second category of scripts we found was service
processing and viewing plausible data within the differ- bootstrapping, i.e., setting up variables necessary for a
ent Web applications. rich client-side application to work. One example of such
a bootstrapping process was observed in a popular free-
mail service’s file storage system in which the UI was
4.2 Prevalence of Dynamic Scripts
implemented completely in JavaScript. When initially
The first goal of our study was to count the number of loading the page, the dynamic script we found provided
Web sites that make use of dynamic script generation. a secret token which was later used by the application to
In the course of this study, using our aforementioned interact with the server using XMLHttpRequests.

728 24th USENIX Security Symposium USENIX Association

 Category # domains Highest rank Data domains exploitable highest rank

Retrieval of user-specific data 16 7 Login state 49 40 1

Unique Identifiers 34 28 5
Service bootstrapping 15 5
Personal data 15 11 11
Cross-service data sharing 5 8 Tokens & Session IDs 7 4 107
Others 13 1
Table 2: Sensitive data contained in dynamic scripts
Table 1: Amounts and highest Alexa rank of domains
with respect to their use case

domain may carry more than one script containing secu-

rity sensitive information and that a given script may fit
The third widely witnessed use case was cross-service into more than one of the four categories.
data sharing, which was often applied to allow for sin- The following sections give a more detailed insight
gle sign-on solutions across multiple services of the same into these numbers. The final column shows the high-
provider or for tracking of users on different domains est rank of any domain on which we could successfully
through a single tracking service. The latter was evi- extract the corresponding data, i.e., on which we could
denced by the same script being included across a multi- bypass encountered protection mechanisms.
tude of domains from different service providers.

4.5 Exploitation
4.4 Types of Security Sensitive Data
In the following, we discuss several attacks which lever-
In a next step, we conducted a manual analysis of the age the leakage of sensitive user information. After
scripts’ data that changed its value, depending on the outlining potential attack scenarios, we discuss several
authentication state of the script request. Within our concrete examples of attacks we successfully conducted
data, we identified four categories of potentially security- against our own test accounts.
critical data:

• Login state: The first type of data that could be 4.5.1 Utilizing Login Oracles
extracted from dynamic scripts was a user’s login In the previous section, we discussed that 49 domains
state to a certain application. We found that this had scripts which returned somewhat different content
happened either explicitly, i.e., assign a variable dif- if the cookies for the logged in user were removed. In
ferently if a user is logged in – or implicitly, e.g. in our notion, we call these scripts login oracles since they
cases where a script did not contain any code if a provide an attacker with either explicit or implicit infor-
user was not logged in. mation on whether a user is currently logged into an ac-
count on a given website or not. However, out of these
• Unique identifiers: The second category we dis-
domains, nine domains had scripts with unguessable to-
covered was the leakage of data that uniquely iden-
kens in the URL, therefore these cannot be utilized as
tified the user. Among these values are customer or
login oracles unless the tokens are known, leaving 40 do-
user IDs as well as email addresses with which a
mains with login oracles.
user was registered to a specific application.
The most prominent script we found to show such
• Personal data: In this category we classified all a behavior is hosted by Google and is part of the
those pieces of data which do not necessarily API for Google Plus. This script, which has a seem-
uniquely identify a user, but provide additional in- ingly static address, shows differences in three differ-
formation on him, such as his real name, his loca- ent variables, namely isLoggedIn, isPlusUser and
tion or his date of birth. useFirstPartyAuthV2 and hence enables an attacker
to ascertain a user’s login status with Google.
• Tokens & Session IDs: The last category we en- The information obtained from the oracles can be
countered were tokens and session identifiers for an utilized to provide additional bits to fingerprinting ap-
authenticated user. These tokens potentially provide proaches [7]. It may however also be used by an attacker
an attacker with the necessary information to inter- to perform a service-specific phishing attack against his
act with the application in the name of the user. victim. Oftentimes, spam emails try to phish user cre-
dentials from banks or services the receiving user does
Table 2 depicts our study’s results with respect to the not even have an account on. If, however, the attacker
occurrences of each category. Please note, that a given knows with certainty that the user currently visiting his

USENIX Association 24th USENIX Security Symposium 729

website is logged in to, e.g., google.com, he can display We found that two online shopping platforms utilize a
a phishing form specifically aimed at users of Google. dynamic script which provides the application with the
This attack can also be improved if additional informa- user’s wish list. This information can be leveraged by an
tion about the user is known – we will discuss this attack attacker to either provide targeted advertisements aimed
later in this section. at profiting (e.g. linking to the products on Amazon, us-
ing the attacker’s affiliate ID) or to sell fake products
matching the user’s wishes.
4.5.2 Tracking Users
Out of the 40 domains which provided a login oracle, 28
also provided some pieces of data which uniquely iden- Application-Specific Attacks Alongside the theoreti-
tify a user. Among these features, the most common cal attack scenarios we discussed so far, we found multi-
identifier was the email address used to register for the ple applications with issues related to the analyzed leak-
corresponding service, followed by some form of user ID ing scripts as well as several domains with CSRF flaws.
(such as login name or customer ID). These features can In the following, we discuss these attacks briefly.
be used to track users even across device platforms, given Extracting Calendar Entries: One of the most promi-
that they log in to a service leaking this information. The nent Web sites we could successfully exploit was a mail
highest-rated service leaking this kind of unique identi- service which offers a multitude of additional functional-
fier was a top-ranked Chinese search engine. Following ity such as management of contacts and a calendar. The
that, we found that a highly-frequented page which fea- latter is implemented mostly in JavaScript and retrieves
tures a calendar function also contained a script leaking the necessary bootstrap information when the calendar is
the email address of the currently logged in user. Since loaded. This script, in the form a function call to a cus-
the owning company also owns other domains which all tom JavaScript API, provides the application with all of
use a single sign-on, logging in to any of these sites also the user’s calendars as well as the corresponding entries.
enabled the attack. This script was not protected against inclusion by third-
party hosts and hence, leaks this sensitive information
4.5.3 Personalized Social Engineering to an attacker. Alongside the calendar’s and entries, the
script also leaks the e-mail address of the victim, there-
In many applications, we found that email addresses fore allowing the attacker to associate the appointments
were being leaked to an attacker. This information can to their owner.
be leveraged to construct highly-personalized phishing
attacks against users. As Downs et al. [5] discovered, Reading Email Senders and Subjects: When logging
users tend to react on phishing emails in more of the in to the portal for a big Chinese Web service provider,
cases if they have a standing business relationship with we found that the main page shows the last five emails
the sending entity, i.e. have an account on a given site, or for the currently logged in user. Our browser exten-
the email appears to be for them personally. sion determined that this information was provided by
an external script, solely using cookies to authenticate
Hence, gathering information on sites a user has an
the user. The script contained the username, amount of
account on as well as retrieving additional information
unread emails and additionally the senders and subjects
such as his name can aid an attacker in a personalized at-
as well as the received dates for the last five emails of
tack. An attacker may choose to abuse this in two ways –
the victim. An abbreviated excerpt is shown in Listing 6.
first and foremost, trying to send phishing mails to users
Although this attack does not allow for an actual extrac-
based on the services they have accounts. However, by
tion of the content of an email, at the very least contacts
learning the email address and hence email provider of
and topics of current discussions of the victim are leaked
the user, an attacker may also try to phish the user’s mail
which we believe to be a major privacy issue.
account. In our study, we found that 14 different domains
leak email addresses and out of these, ten domains also
revealed (at least) the first name of the logged in user. Listing 6 Excerpt of the script leaking mail information
In addition, two domains leaked the date of birth and var mailinfo = {
"email": "[email protected]",
one script, hosted on a Chinese Web site, even contained ...,
the (verified) mobile phone number of the victim. We "maillist": [{
believe that, especially considering the discoveries by "mid": "0253FE71.....001",
Downs et al., all this information can be leveraged to- "mailfrom":"First Last <[email protected]>",
"subject":"Top secret insider information",
wards creating highly-personalized phishing attacks. "ctime": "2014-05-02 21:11:46"}]
Another form of personalized social engineering at- ..}
tacks enabled by our findings is targeted advertisement.

730 24th USENIX Security Symposium USENIX Association

Session Hijacking Vulnerabilities: During the course user, accessing profile information and even make posts
of our study, we found that two German file storage ser- in the name of the user.
vices contained session hijacking vulnerabilitie. Both Similar to the first finding, we found an issue on the
these services are implemented as a JavaScript applica- highly-ranked domain of a weather service. The appli-
tion, which utilizes XMLHttpRequest to retrieve direc- cation provides an API for changing a user’s profile as
tory listings and manage files in the storage. To avoid well as the password, whereas the old password does not
unauthorized access to the system, both applications re- need to be entered to set a new one. Nevertheless, the
quire a session key to be present within a cookie as well API requires knowledge of the email address of the cur-
as in an additional HTTP header. When first visiting rently logged in user, thereby employing at least a vari-
the file storage service, the application loads an external ant of a CSRF token. Similar to the previously outlined
script called userdata.js which contains the two nec- flaw, we found a script that provides information on the
essary secrets to access the service: the username and the user – among which also the email address is contained.
aforementioned session key. We found that this script is Hence, we could successfully automate the attack by first
not properly protected against cross-domain data leak- retrieving the necessary token (email) from the leaking
age, allowing an attacker to leak the secret information. script and subsequently sending a password change re-
With this information at hand, we were able to list and quest to the API. Afterwards, we sent both the email ad-
access any file in the victim’s file storage. Furthermore, dress (which is also used as the login name) and the new
it enabled us to invoke arbitrary actions in the name of password back to our servers, essentially taking over the
the user such as creating new files or deleting existing user’s account in a fully automated manner.
ones.
One minor drawback in this attack is the need for the
4.5.4 Notification of Vulnerable Sites
attacker to know the victim’s username in advance, since
the dynamic script requires a GET parameter with the In order to allow affected pages to fix the vulnerabili-
username. Regardless, we believe that by either targeted ties before they can be exploited, we notified the security
phishing emails or retrieving the email address through teams of all domains for which we could successfully
another service (as discussed earlier) this attack is still craft exploits. To allow for a better understanding of the
quite feasible. general vulnerability as well as the specifics of each do-
Circumventing CSRF Protection: One way of pre- main, we created a Web site detailing the problem asso-
venting cross-domain attacks is the use of CSRF tokens, ciated with cross-domain includes of JavaScript and the
namely secrets that are either part of the URL (as a GET attack pattern. In addition, we created proof-of-concept
parameter) or need to be posted in a form and can then exploits for each flaw and shared this information, aug-
be verified by the server. Although CSRF tokens are a mented by a description of the problem and its impact,
well-understood means of preventing these attacks and e.g., the potential to hijack a user’s session, with the do-
provide adequate security, the proper implementation is mains owners.
a key factor. In our analysis, we found that two domains As of this writing, we received only three replies stat-
contained scripts which leaked just these critical tokens. ing that the flaw was either being dealt with or had
The first one was present on a new domain, which re- been fixed already. However, none of the affected sites
quired the knowledge of two secrets in order to change agreed to be mentioned in the paper, therefore we opted
profile data of the user – a 25 byte long token as well as to anonymize all the vulnerable services we discovered.
the numerical user ID. While browsing the Web site, our
extension detected a state-dependent dynamic script that 4.5.5 Summary of Our Findings
exactly contained these two values. As a consequence,
we were able to leak this data and use it to send a properly In total, we found that out of the 49 domains which are
authenticated profile change request to the correspond- dependent on the user’s login state, 40 lack adequate pro-
ing API. As a consequence, we were able to arbitrarily tection and can therefore be used to deduce if a user is
change a user’s profile data. Interestingly, one field that logged into a certain application. On 28 of these do-
was only visible to the user himself contained a stored mains, dynamic scripts allowed for unique identification
XSS vulnerability. Hence, we were able to send a Cross- of the current user through various means like customer
Site Scripting payload within this field to exploit the, oth- IDs or email addresses.
erwise unexploitable, XSS flaw. Additionally and partly overlapping with the afore-
Apart from the obvious issues an XSS attack could mentioned scripts, we found that personal data (such as
cause, for a user logged in via the Facebook Social Lo- the name or location) was contained in scripts on 13 do-
gin, we could retrieve the Facebook API access token and mains. Last but not least, we encountered four domains
hence interact with the Facebook API in the name of the which allow for extraction of tokens that could in turn be

USENIX Association 24th USENIX Security Symposium 731

used to control the target application in the name of the a request for a dynamic script that does not provide a
victimized user. An overview of these results is depicted Referer header, it needs to decide whether to allow the
in Table 2. request or whether to block it. If the request is allowed,
the attacker may force the removal of the referrer as dis-
4.6 Non-exploitable Situations cussed before. On the other hand, if the server blocks
the request (strict referrer checking), it might break the
As shown in Table 2, we were not able to leak data from application for users behind privacy-aware proxies.
all of the dynamic scripts we found. In general, we iden- We found several domains that implemented referrer
tified two different reasons for this: Either the URL of checking. However, of seven pages that conducted such
the script was not guessable by an attacker or the Web a check, only two conducted strict referrer checking. As
site utilized referrer checking to avoid the inclusion of a consequence, the other five Web sites were still ex-
resources by third parties. While these mechanisms pro- ploitable by intentionally removing the Referer header.
tected some Web sites from being exploitable, we believe Listing 7 shows the attack we utilized aiming at stripping
that the corresponding countermeasures were not placed the Referer header. In this example, we use a data URI
intentionally against the described attack, but were rather assigned to an iframe to embed the leaking script.
in place because of the used application framework (Re-
ferrer checking) or because of the application’s design Listing 7 Using a data URL within a frame to send a
(unguessable URLs). In this section, we briefly discuss request without a Referer header
and analyze these situations. var url = "data:text/html,"
+ "<script src=’"
+ "http://example.org/dynamic_script.js"
4.6.1 Unguessable URLs + "’></script>"
A prerequisite for the attack described in this paper is + "<script>"
that an attacker is able to include a certain script file into + "function leakData(){ ... }; "
his page during a user’s visit. For this, the attacker needs + "leakData();"
to know the exact URL under which a certain dynamic + "</script>";
script is available. // create a new iframe
Some of the scripts we found required a session ID or var frame = document.createElement(’iframe’);
another unguessable token to be present in a GET param- // assign the previously created data url
eter of the URL. As the attacker is in general not able to frame.src = url;
body.appendChild(frame);
obtain such a session ID, the script cannot be included by
the attacker and hence sensitive data cannot be leaked.

4.6.2 Referrer Checking

5 Protection Approach
Another technique that prevented us from exploiting a
script leakage vulnerability was referrer checking. When In our study, we observed a surprisingly high number
a browser generates an HTTP request for an embedded of popular Web sites utilizing the dangerous pattern of
script, it adds the Referer header containing the URL using external, dynamically-generated scripts to provide
of the embedding site. Many Web pages tend to misuse user-specific data to an application. It seems that de-
this header as a security feature [31]. By checking the velopers are not aware of the severe consequences this
domain of the referrer, a Web site is in theory able to practice has. In order to improve this situation, we pro-
ascertain the origin of the page requesting a resource. vide a secure and functionally-equivalent solution. The
In 2006, however, Johns showed that referrer check- main problem of dynamically generated script includes is
ing has several pitfalls [17]. As the Referer header was the incorporation of sensitive user data into files that are
never intended to serve as a security feature, it should not completely protected by the Same-Origin Policy. We
not be used as a reliable source of information. So, for discourage this practice and advise developers to strictly
example, many proxies and middle boxes remove the separate JavaScript code from sensitive user data.
Referer header due to privacy concerns. Furthermore, Figure 2 depicts our design proposal. In this pro-
several situations exist in which a browser does not attach posal script code is never generated on the fly, but al-
a Referer header to a request and as discussed by Ko- ways pulled from a static file. Sensitive and dynamic
towicz, an attacker can intentionally remove the header data values should be kept in a separate file, which cannot
from requests [19]. be interpreted by the browser as JavaScript. When the
As a consequence, servers should not rely on the pres- static JavaScript gets executed, it sends an XMLHttpRe-
ence of the Referer header. Hence, if a server receives quest to the file containing the data. By default access

732 24th USENIX Security Symposium USENIX Association

 address book. Grossman reported the issue to Google,
!%%  " % "
!%%  " % "

where the term Cross-Site Script Inclusion (XSSI) was
  
 
)
coined by Christoph Kern. Kern later mentioned the term
&



#  #!
#  #
publicly for the first time in his book from 2007 [18].


#  $!
# (  " $

'
Several other authors later on picked up this term to refer
to slight variations of the attack [27, 31].
 

!%%  "

At the same time Chess et al. [3] picked up Gross-
man’s technique, slightly generalized it and coined the
 
term JavaScript Hijacking. Unlike the vulnerabilities in
this paper, these attacks do not target dynamic JavaScript

 

resources. Instead they use script-tags in combination
with a non-standard JavaScript quirk (that has been re-
moved from all major browsers in the meantime) to leak
data that is encoded in the JSON-array format.
Furthermore, in 2013, Grossman [11] discussed the
Figure 2: Protection scheme
idea of utilizing resources which are only accessible by
users that are logged in to determine the logon status of
to the response of an XMLHttpRequest is governed by a user. He also proposed to employ click-jacking attacks
the Same-Origin Policy. Hence, third-party sites cannot on the user to force him to like the attacker’s Facebook
request the file within the user’s authentication context. or Google+ site. In doing so and in comparing the latest
As a consequence, attackers cannot access the data con- addition to his followers, an attacker could thereby de-
tained within this file. By using Cross-Origin Resource duce the identity of the user currently visiting his web-
Sharing (CORS) [28], Web developers are able to selec- site. The idea of determining a user logon status was
tively grant access to the file to any third party service picked up by Evans [8], who demonstrated a login or-
that requires access. acle on myspace.com by including a Cascading Style
While the attacker is able to include and execute the Sheet file from the service which changed certain prop-
static JavaScript file within his page, the corresponding erties based on whether the user was logged in or not.
code will be executed in the origin of the attacker’s Web In 2015, Takeshi Terada presented another variation of
site. Hence, when the script code requests the data file, the attack that he called Identifier-based XSSI [27]. Ter-
which resides in the origin of the legitimate Web site, the ada used script tags to reference CSV files from third-
two origins do not match and hence the Same-Origin Pol- party domains. A CSV file usually consists of a comma
icy protects the file’s content from being accessed by the separated list of alphanumeric words. Under certain cir-
attacker. If, however, the legitimate site requests the data cumstances this list also represents a syntactically correct
files, the two origins match and thus access is granted. list of JavaScript variable declarations. Hence, by refer-
As the data file does not contain valid JavaScript code, encing such a file the JavaScript engine will create a set
it cannot be included and executed by the attacker via the of global variables named like the values in the CSV file.
HTML script tag. To completely avoid this risk, Web By enumerating all globally accessible variables, Terada
developers can either include a so-called unparseable was able leak the contents of the file.
cruft to the beginning of file which causes a compile time Other related work has focused on CSS-based history
failure or add valid JavaScript that effectively stops exe- leakage [13, 10, 14]. Analogously to login state leakage,
cution during run time, such as an uncatchable exception retrieval of a user’s history allows an attacker to deduce
(cp. Figure 2) [31]. that a victim has an account on a given site, hence en-
abling him to start target phishing attacks similar to the
6 Related Work ones we outlined in Section 4.5.3.
Another means of utilizing history leakage was dis-
Conceptually closest to the attacks presented in Sec- cussed in 2010 by Wondracek et al. [30], who proposed
tion 4.5 is JSON Hijacking, an exploitation technique a scheme capable of de-anonymizing users based on their
initially presented by Grossman in 2006 [9]. In his at- group membership in OSNs. To do so, they utilized the
tack he utilized a cross-domain script include pointing stolen history of a user to determine the group sites the
to a JSON-array resource, which originally was intended user had previously visited. Comparing these to a list
as an end-point for an XMLHttpRequest. Via using a of the members of the corresponding groups allowed the
non-standard redefinition of JavaScript’s object construc- authors to determine the user’s identity. Recently, for
tor, he was able obtain the content of the user’s GMail a poster, Jia et al. [16] discussed the notion of utilizing

USENIX Association 24th USENIX Security Symposium 733

timing side-channels on the browser cache to ascertain a highly likely that the attack surface of this paper’s attacks
user’s geo location. will grow considerably.
In 2012, Nikiforakis et al [24] conducted a large-scale For instance, Doupé et al. [4] developed a tool called
analysis of remote JavaScript, focusing mainly on the po- deDacota which automatically rewrites applications to
tential security issues from including third-party code. adhere to the CSP paradigms by moving all inline script
For W2SP 2011, two groups [20, 15] conducted an anal- code to external scripts. As our work has shown, these
ysis of cross-domain policies for Flash, aiming specifi- external scripts – if not protected properly – may be in-
cally at determining those domains which allow access cluded by any third-party application and hence might
from any domain. Since Flash attaches the cookies for leak secret data. Therefore, we believe that it is imper-
the target domain to said requests, they discussed attack ative that measures are taken to ensure the secure, yet
scenarios in which a malicious Flash applet is used to flexible client-side access to sensitive data and that the
retrieve proprietary information. changing application landscape caused by CSP adoption
In addition to these attacks, Paul Stone demonstrated is closely monitored. As discussed by Weissbacher et al.,
another means of stealing sensitive information across however, CSP is not yet widely deployed and signifi-
origin boundaries. To do so, he leveraged a timing side cantly lags behind other security measures [29].
channel, allowing him to leak a framed document pixel Furthermore, in this paper, we exclusively focused on
by pixel [26]. dynamic JavaScript that is pulled into the browser via
script-tags. This is not necessarily the only method,
how server generated script content is communicated.
7 Outlook
An alternative to script tags is to transport the code
The goal of this paper was to conduct an initial study via XMLHttpRequests bodies, which are subsequently
into the usage and potential pitfalls of dynamic scripts passed to the eval() API. In future work, we plan to
in real world applications. Our data set of 150 highly investigate such XMLHttpRequests endpoints in respect
ranked domains gives a good glimpse into the problems to their susceptibility to attack variants related to this pa-
caused by such scripts. Nevertheless, we believe that a per’s topic.
large-scale study could provide additional key insights Finally, as related work has indicated, internal appli-
into the severity of the issue. To enable such a study, cation information, such as the login state of a user, may
an important problem to solve is the automation of the also be leaked via images or style sheets. In this case,
analysis—starting from fully automated account regis- the observed effects of a cross-domain element inclusion
tration and ranging to meaningful interaction with the manifest themselves through side effects on the DOM
application. Therefore, implementing such a generic, yet level, as opposed to a footprint in the global script object.
intelligent crawler and investigating how well it can im- Hence, a systematical further analysis on other classes of
itate user interaction is a challenging task we leave for server-side content generation that might enable related
future work. Along with such a broader study, enhance- attacks would be a coherent extension of our work.
ments have to be made to cope with the increased amount
of data. As an example, our Chrome extension could use 8 Summary & Conclusion
advanced comparisons based on syntactical and seman-
tical differences of the JavaScript code rather than based In this paper, we conducted a study into the prevalence
on content. Since our data set was limited by the fact that of a class of vulnerabilities dubbed Cross-Site Script In-
our analysis required manual interaction with the inves- clusion. Whenever a script is generated on the fly and
tigated applications, the need to automate the secondary incorporates user-specific data in the process, an attacker
analysis steps, i.e., examination of the differences and is able to include the script to observe its execution be-
verification of a vulnerability, did not arise. havior. By doing so, the attacker can potentially extract
Recently, the W3C has proposed a new security mech- the user-specific data to learn information which he oth-
anism called Content Security Policy (CSP), which is a erwise wouldn’t be able to know.
“declarative policy that lets authors of a web application To investigate this class of security vulnerabilities, we
inform the client from where the application expects to developed a browser extension capable of detecting such
load resources” [25]. In its default setting, CSP forbids scripts. Utilizing this extension, we conducted an empir-
the usage of inline scripts and hence, programmers are ical study of 150 domains in the Alexa Top 500, aimed
compelled to put the code into external scripts. During at gaining insights into prevalence and purpose of these
our study we noticed that many of these inline scripts scripts as well as security issues related to the contained
are also generated dynamically and incorporate sensitive sensitive information.
user data. If all these current inline scripts are naively Our analysis showed that out of these 150 domains, 49
transformed into dynamic, external script resources, it is domains utilize server-side JavaScript generation. On 40

734 24th USENIX Security Symposium USENIX Association

domains we were able to leak user-specific data leading [13] JACKSON , C., B ORTZ , A., B ONEH , D., AND M ITCHELL , J. C.
to attacks such as deanonymizing up to full account hi- Protecting Browser State from Web Privacy Attacks. In Proceed-
ings of the 15th ACM World Wide Web Conference (WWW 2006)
jacking. Our practical experiments show that even high- (2006).
profile sites are vulnerable to this kind of attacks.
[14] JAKOBSSON , M., AND S TAMM , S. Invasive Browser Sniffing
After having demonstrated the severe impact these and Countermeasures. In Proceedings of The 15th annual World
flaws can incur, we proposed a secure alternative using Wide Web Conference (WWW2006) (2006).
well-known security concepts, namely the Same-Origin [15] JANG , D., V ENKATARAMAN , A., S AWKA , G. M., AND
Policy and Cross-Origin Resource Sharing, to thwart the S HACHAM , H. Analyzing the cross-domain policies of flash ap-
identified security issues. plications. In Proceedings of the 5th Workshop on Web (2011),
vol. 2.
[16] J IA , Y., D ONGY, X., L IANG , Z., AND S AXENA , P. I
Acknowledgements know where you’ve been: Geo-inference attacks via the
browser cache. IEEE Security&Privacy 2014, http://www.
The authors would like to thank the anonymous review- ieee-security.org/TC/SP2014/posters/JIAYA.pdf, last
ers for their valued feedback. More over, we want to accessed 2014/05/17.
thank our shepherd Joseph Bonneau for the support in [17] J OHNS , M., AND W INTER , J. Requestrodeo: Client side protec-
getting our paper ready for publication. This work was tion against session riding. Proceedings of the OWASP Europe
2006 Conference (2006).
in parts supported by the EU Project STREWS (FP7-
318097). The support is gratefully acknowledged. [18] K ERN , C., K ESAVAN , A., AND DASWANI , N. Foundations of
security: what every programmer needs to know. Apress, 2007.
[19] KOTOWICZ , K. Stripping the referrer for fun and
References profit. online, http://blog.kotowicz.net/2011/10/
stripping-referrer-for-fun-and-profit.html, last ac-
[1] BARTH , A., JACKSON , C., AND M ITCHELL , J. C. Robust
cessed 2014/05/10.
defenses for cross-site request forgery. In Proceedings of the
15th ACM conference on Computer and communications secu- [20] L EKIES , S., J OHNS , M., AND T IGHZERT, W. The state of the
rity (2008), ACM, pp. 75–88. cross-domain nation. In Proceedings of the 5th Workshop on Web
(2011), vol. 2.
[2] CERT. Advisory ca-2000-02 malicious html tags embedded in
client web requests, February 2000. [21] M OZILLA. Inheritance and the prototype chain. online,
https://developer.mozilla.org/en-US/docs/Web/
[3] C HESS , B., O’N EIL , Y. T., AND W EST, J. Java-
JavaScript/Guide/Inheritance_and_the_prototype_
Script Hijacking. [whitepaper], Fortify Software, http:
chain, last accessed 2014/05/10.
//www.fortifysoftware.com/servlet/downloads/
public/JavaScript_Hijacking.pdf, March 2007. [22] M OZILLA. Mutationobserver. online, https://developer.
mozilla.org/en-US/docs/Web/API/MutationObserver,
[4] D OUP É , A., C UI , W., JAKUBOWSKI , M. H., P EINADO , M.,
last accessed 2014/05/10.
K RUEGEL , C., AND V IGNA , G. dedacota: toward preventing
server-side xss via automatic code and data separation. In Pro- [23] M OZILLA D EVELOPER N ETWORK , AND RUDERMAN , J. Same-
ceedings of the 2013 ACM SIGSAC conference on Computer & origin policy. online, https://developer.mozilla.org/
communications security (2013), ACM, pp. 1205–1216. en-US/docs/Web/Security/Same-origin_policy.
[5] D OWNS , J. S., H OLBROOK , M. B., AND C RANOR , L. F. De- [24] N IKIFORAKIS , N., I NVERNIZZI , L., K APRAVELOS , A.,
cision strategies and susceptibility to phishing. In Proceedings ACKER , S. V., J OOSEN , W., K RUEGEL , C., P IESSENS , F., AND
of the second symposium on Usable privacy and security (2006), V IGNA , G. You Are What You Include: Large-scale Evaluation
ACM, pp. 79–90. of Remote JavaScript Inclusions. In 19th ACM Conference on
[6] ECMAS CRIPT, E., A SSOCIATION , E. C. M., ET AL . Ec- Computer and Communications Security (CCS 2012) (2012).
mascript language specification, 2011. [25] S TERNE , B., AND BARTH , A. Content security policy 1.0.
[7] E LECTRONIC F RONTIER F OUNDATION. Panopticlick – how online, http://www.w3.org/TR/2012/CR-CSP-20121115/.
unique – and trackable – is your browser? online, last accessed 2014/05/10.
https://panopticlick.eff.org/about.php, last accessed [26] S TONE , P. Pixel perfect timing attacks with html5.
2014/05/10.
[27] T ERADA , T. Identifier based xssi attacks, 2015.
[8] E VANS , C. Cross-domain leaks of site logins. online, http:
[28] VAN K ESTEREN , A., ET AL . Cross-origin resource sharing.
//bit.ly/1lz1HPl, last accessed 2014/05/10.
W3C Working Draft WD-cors-20100727 (2010).
[9] G ROSSMAN , J. Advanced Web Attack Techniques using GMail.
[29] W EISSBACHER , M., L AUINGER , T., AND ROBERTSON , W.
[online], http://jeremiahgrossman.blogspot.de/2006/
Why is csp failing? trends and challenges in csp adoption. In
01/advanced-web-attack-techniques-using.html, Jan-
Research in Attacks, Intrusions and Defenses. Springer, 2014,
uary 2006.
pp. 212–233.
[10] G ROSSMAN , J. I know where you’ve been. [online],
[30] W ONDRACEK , G., H OLZ , T., K IRDA , E., AND K RUEGEL , C.
http://jeremiahgrossman.blogspot.com/2006/08/
A practical attack to de-anonymize social network users. In Secu-
i-know-where-youve-been.html, August 2006.
rity and Privacy (SP), 2010 IEEE Symposium on (2010), IEEE,
[11] G ROSSMAN , J. The web won’t be safe or secure until we break pp. 223–238.
it. Communications of the ACM 56, 1 (January 2013), 68–72.
[31] Z ALEWSKI , M. The Tangled Web: A Guide to Securing Modern
[12] H ANSEN , R., AND G ROSSMAN , J. Clickjacking. Sec Theory, Web Applications. No Starch Press, 2012.
Internet Security (2008).

USENIX Association 24th USENIX Security Symposium 735