A Security Analysis of Emerging Web Standards

HTML5 and Friends, from Speciﬁcation to Implementation

Philippe De Ryck, Lieven Desmet, Frank Piessens and Wouter Joosen

IBBT-DistriNet, KU Leuven, 3001 Leuven, Belgium

Keywords:

HTML5, Web Application Security, Standards, Speciﬁcation.

Abstract:

Over the past few years, a signiﬁcant effort went into the development of a new generation of web standards,

centered around the HTML5 speciﬁcation. Given the importance of the web in our society, it is essential that

these new standards are scrutinized for potential security problems. This paper reports on a systematic analysis

of ten important, recent speciﬁcations with respect to two generic security goals: (1) new web mechanisms

should not break the security of existing web applications, and (2) different newly proposed mechanisms

should interact with each other gracefully. In total, we found 45 issues, of which 12 are violations of the

security goals and 31 issues concern under-speciﬁed features. Additionally, we found that 6 out of 11 expli-

cit security considerations have been overlooked/overruled in major browsers, leaving secure speciﬁcations

vulnerable in the end. All details can be found in an extended version of this paper (De Ryck et al., 2012).

1 INTRODUCTION

The past few years, web applications have known

a signiﬁcant growth in popularity. With billions of

users, applications like Facebook, Twitter, Foursquare

or anything provided by Google are omnipresent in

most internet users’ daily life. One constant in the

evolution of web pages or web applications has al-

ways been the drive towards more and better client-

side functionality, up to the level where web applic-

ations obtain privileges previously only available to

desktop applications, such as client-side storage or

easy access to peripheral devices (webcams, micro-

phones, sensors etc).

The client-side functionality available to early

web applications was limited to dynamic page con-

struction, without any explicit support for features

like client/server communication, interaction between

browsing contexts or local storage of data. The ex-

tension of the client-side platform started with XML-

HttpRequest, an explicit client/server communication

mechanism and continued with the recently proposed

Web Messaging API, which enables communication

between browsing contexts. Currently, the client-side

platform is being developed at a rapid pace, with fea-

tures like media elements, an iframe-based sandbox,

several client-side APIs (storage, system properties,

location, etc.), and many more.

Unfortunately, an extensive set of client-side fea-

tures poses an attractive target for attackers, making

the user into a potential victim. For example, insec-

urities in an API for capturing media in a web applic-

ation can lead to stolen captures. In this paper, we

report on a structured security analysis of a large sub-

set of these emerging web standards, where we not

only analyze each speciﬁcation in isolation, but also

investigate potential interactions between co-existing

features of multiple speciﬁcations.

A key aspect of this security analysis is the

identiﬁcation of potential security violations. Obvi-

ously, different mechanisms will have different secur-

ity goals. For instance, the sandboxing mechanism

speciﬁed in the HTML5 speciﬁcation has the goal of

isolating content in the sandbox, whereas the media

capture speciﬁcation aims to appropriately guard ac-

cess to the API to capture audio or video. It is not

our objective to analyze each mechanism for com-

pliance with these mechanism-speciﬁc security goals.

Instead, we identify two generally applicable security

goals: preservation of security invariants and grace-

ful interaction of co-existing features.

From the security analysis of ten secure-by-design

W3C web standards we conclude that these new

web standards already achieve a high level of secur-

ity. This is most probably due to the fact that the

emerging standards explicitly endorse the secure-by-

design design principle, taking security into account

from the beginning, and not as an afterthought. As

such, the analysis does not reveal major unconditional

security issues, we do however identify several viola-

257

De Ryck P., Desmet L., Piessens F. and Joosen W..

A Security Analysis of Emerging Web Standards - HTML5 and Friends, from Speciﬁcation to Implementation.

DOI: 10.5220/0004049502570262

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 257-262

ISBN: 978-989-8565-24-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

tions of one of the stated security goals under certain

application-speciﬁc circumstances.

In the remainder of this paper, we present the ap-

proach and the process of the security analysis, fol-

lowed by a selection of three security goal violations

(Section 2). We continue to discuss both related work

on web and standardization security (Section 4) and

future improvements (Section 5).

2 OVERVIEW OF THE

SECURITY ANALYSIS

The broad set of new and emerging web standards

covers an wide range of functionality and features,

from detailed HTML parsing to rich JavaScript APIs

and security design guidelines. In the analysis, we fo-

cus on the newly-added core features of HTML5 (e.g.

ofﬂine application caching and sandboxed iframes)

as well as the new features provided by JavaScript

APIs (e.g. client-side storage and cross-origin com-

munication). These JavaScript APIs are available to

any client-side script embedded in a website, either

directly coming from the website owner, or integ-

rated from a (potentially less trusted) third-party ser-

vice provider, as is the case for online advertisements,

web analytic frameworks, mashups compositions and

many more. Concretely, we have studied the fol-

lowing list of ten W3C speciﬁcations: HTML5, Me-

dia Capture API, Web Messaging, XMLHttpRequest

Level 1 and Level 2, Cross-Origin Resource Sharing,

Uniform Messaging Policy, Web Storage, Geoloca-

tion API and System Information API.

The core process of the security analysis is the in-

vestigation of each speciﬁcation in isolation and in co-

existence with other speciﬁcations, based on the dis-

tilled information (fully explained in (De Ryck et al.,

2012)). The goal is to detect and identify weaknesses

in the speciﬁcations leading to an increase of attack

surface, due to a violation of one of the security goals:

preservation of security invariants and graceful inter-

action of co-existing features.

The ﬁrst security goal states that new mechanisms

introduced in the browser should not weaken the se-

curity of existing (legacy) web applications. For ex-

ample, the security of existing web applications might

rely on the enforcement of the same origin policy in

the browser. Introducing new cross-origin commu-

nication mechanisms should not break the security of

these existing applications. Akhawe et al. (Akhawe

et al., 2010) identify the same generic security goal,

and call it the preservation of security invariants.

The second security goal states that separately

speciﬁed mechanisms meant to co-exist and to be

used together should interact gracefully. The intro-

duction of one newly proposed mechanism should not

break or weaken the security of another newly pro-

posed mechanism. We call this second goal the grace-

ful interaction of co-existing features. For example, a

newly proposed mechanism for cross-origin commu-

nication should be able to handle new kinds of origins

(such as the unique origin in sandboxes).

Scope and Attacker Model. The ten studied W3C

speciﬁcations form a representative subset of the

emerging web standards, and are per category depic-

ted in an abstract model of modern web standards.

Central in the abstract model is the window object,

which provides access to the page (via the document),

as well as all JavaScript functionality. Within the win-

dow are event handlers and the DOM tree, which we

do not include explicitly, unless used by other parts of

the model. The window can be restricted by a sand-

box, which is part of HTML5. The building blocks

around the window offer a tremendous amount of

functionality to a web application, such as communic-

ation between components, embedding and capturing

media, requesting information from the device, com-

municating with external services, storing data on the

client-side and caching an entire application or com-

ponent. Note that for “Client-side storage” we fo-

cus on the Web Storage speciﬁcation, which contains

most of the complexity with regard to storage areas

and their access rules, compared to other client-side

storage speciﬁcations.

In order to keep the analysis focused, we con-

sidered the UI to be out of scope (with the exception

of end-user interactions for user consent). Similarly,

we discarded parts of the HTML5 speciﬁcations de-

scribing the HTML parsing and rendering, usability

guidelines and API development guidelines.

We consider both the web attacker and the gad-

get attacker to be valid attacker models (Barth et al.,

2008). The former is a malicious principal who

owns one or more machines on the network where

the user gets and renders content from, whereas the

latter has one additional ability: the integrator em-

beds a gadget of the attacker’s choice. Concretely,

we assume that a user visits honest sites, honest sites

unknowingly incorporating malicious content (gadget

attacker) or malicious sites (web attacker), using an

honest, speciﬁcation-compliant browser.

3 RESULTS OF THE SECURITY

ANALYSIS

Performing the security analysis as described before

SECRYPT2012-InternationalConferenceonSecurityandCryptography

258

has revealed 45 security issues, of which the major-

ity, i.e. 31 issues, relates to under-speciﬁcation and

inconsistencies across the speciﬁcations. A smaller

fraction, i.e. 12 issues, increases the attack surface

by breaking one of our two security goals, namely the

preservation of security invariants or the graceful in-

teraction of co-existing features. These violations are

weaknesses in the speciﬁcations that, depending on

the speciﬁc application, potentially increase the attack

surface. Additionally, we identify several cases where

browsers fail to comply with speciﬁc security consid-

erations stated in the speciﬁcations.

In the remainder of this section, we discuss three

examples of an increased attack surface. The full re-

port (De Ryck et al., 2012) contains more examples,

as well as issues with under-speciﬁcation and non-

compliance with explicit security considerations.

[Example #1] HTML5: Injection of Submission

Controls. The HTML5 speciﬁcation enables the

use of form controls outside of a

form

element, to

overcome the lack of support for nested forms. Such

a form-associated element can appear anywhere, but

is associated with a form within the document. The

associated form is either the nearest ancestor form,

or the form with the ID explicitly referenced by the

control using the

form

attribute (see Listing 1, line

6). Additionally, the speciﬁcation allows submission

controls to provide attributes that change the form be-

havior when this speciﬁc submission control is used.

Examples are

novalidate

that disables form valida-

tion and

formaction

that changes a form’s destination

(see Listing 1, line 4 and 7).

1 <form id =”one ” > ... < /form>

2 <form id =”two ” > ... < / form>

3 <!−− A ss o ci a ted with n e a re s t form ” two ” −−>

4 <in p u t type =” submit ” . . . no v a li d a t e />

5 <!−− A ss o ci a ted with form with id ” one ” −−>

6 <in p u t form=”one ”

7 type =”submit ” . . . f o rma c tio n =” ht t p : / / . . . ” />

Listing 1: Use of the newly introduced form attributes.

The combination of both new features creates a

new attack vector that allows an attacker to inject a

form submission control, associated with an existing

form on the page. By changing the form’s destination

using the

formaction

attribute, an attacker can trick

the user into submitting a form located anywhere on

the page to an attacker-controlled destination. After

having captured the form’s parameters, the attacker

can automatically resubmit the form to the original

destination, making the attack fairly stealthy.

One simple attack scenario is the stealing of an

auto-completed form, such as a login form, for which

the browser automatically enters the appropriate val-

ues, even if the user had no intention of logging in to

the site. If the attacker can trick the user into click-

ing the injected submission control, the form will be

submitted to the attacker’s website. Tricking the user

into clicking an oddly placed button may be difﬁcult,

but submission controls can also be styled with cus-

tom images, allowing full integration into the victim

website. A second, more complex attack scenario in-

volves the stealing of hidden security tokens from a

form. The de facto countermeasure against cross-site

request forgery (CSRF) attacks is the use of a unique

token to authenticate a future request (Zeller and Fel-

ten, 2008). The security model of this countermeas-

ure depends on the attacker not being able to extract

such tokens from the page of the victim site, due to

the same-origin policy separation, an assumption vi-

olated in this attack scenario.

Note that these attack scenarios do not require to

execute any injected JavaScript, but only require the

possibility to inject a previously harmless form con-

trol. This means that sites without cross-site scripting

(XSS) vulnerabilities or sites deploying explicit de-

fenses against injection attacks, such as Content Se-

curity Policy (Sterne and Barth, 2011), can still be

vulnerable. Additionally, traditional form stealing us-

ing HTML injection (Zalewski, 2011) either depends

on the position of the vulnerability within the page

or the capability to inject a form element in front of

another form. The attack presented here is not de-

pendent on script execution nor on a speciﬁc position

of the injection vulnerability.

Web developers can protect their sites by making

sure that input validation ﬁlters prevent the injection

of submission controls. It sufﬁces to prevent the use

of the behavior-changing attributes on user-supplied

form controls, although it is wise to prevent the use of

the form-association attribute as well.

[Example #2] CORS: Arbitrary Body Format.

The Cross-Origin Resource Sharing and XMLHt-

tpRequest Level 2 speciﬁcations enable cross-origin

requests from JavaScript, where previously only

same-origin requests were allowed. The main idea

of CORS is that the client provides the server the ne-

cessary information to make a decision about whether

an origin can fetch a resource or not. The decision

is communicated to the client by means of response

headers, where it is enforced. If an origin is not al-

lowed to fetch the resource, the requesting script will

not have access to the response data.

Technically, the algorithms elaborating on this

idea distinguish between simple requests and actual

requests. Simple requests are requests that could

ASecurityAnalysisofEmergingWebStandards-HTML5andFriends,fromSpecificationtoImplementation

259

previously be sent with other HTML elements, such

as GET requests or POST requests using forms. A

simple CORS request is sent to the server, and based

on the CORS headers in the response, the browser de-

cides whether the script can access the response con-

tents. Actual requests are new types of requests, such

as cross-origin PUT or DELETE requests, and can not

be sent cross-origin with traditional techniques. This

design decision prevents introducing new vulnerabil-

ities in legacy applications.

The treatment of simple CORS requests is based

on the assumption that these cross-origin requests

could previously be made using commonly available

HTML elements. However, one important difference

between a POST request resulting from a form sub-

mission and a scripted POST request is the format of

the request body. A form body is either in the text/-

plain or application/x-www-form-urlencoded format,

which is restricted to key=value data separated by

&, or the multipart/form-data format, which contains

multiple sections separated by a self-deﬁned bound-

ary. The analysis uncovered that a simple cross-origin

POST request sent from JavaScript is still restricted

to these content types in its header, but compliance

of the body format to the speciﬁed content type is

never checked. This means that an attacker is able

to send cross-origin POST requests with an arbitrary

body format, but will most likely be denied access the

response, since the appropriate response headers to

allow access will be missing.

A concrete attack scenario is an application offer-

ing an authenticated API, e.g. using the JSON format.

Where previously only pages within the origin of the

application were able to access the API, CORS en-

ables all origins to make requests to the API. Even

though the API will not add the appropriate headers

to the response, the request will still be processed, po-

tentially resulting in unintended server-side changes.

Traditionally, the body format of cross-origin

POST requests was tightly constrained, but simple

CORS requests, explicitly aimed at not enabling more

features than existing with HTML elements, relax

these constraints. CORS opens up existing applica-

tions to cross-origin requests with an arbitrary body

format, previously only available within the same ori-

gin. This is a violation of the ﬁrst security goal.

Concretely, web developers can protect against

this attack vector by validating the format of incoming

requests against the format speciﬁed in the header.

[Example #3] CORS: Sandboxed Sender. As dis-

cussed with the previous violation, the HTML5 spe-

ciﬁcation offers the possibility to sandbox an iframe

and impose restrictions on the content. One important

restriction is the possibility to have the browser assign

a unique origin to the content of the iframe. This en-

sures that the content of the iframe is separated us-

ing the same origin policy, allowing strict isolation of

content, even within the same origin. An important

nuance of this unique origin is that the serialization to

a string equals null, meaning that the value null will

be used in headers or origin checks.

The effect of a unique origin being serialized to

null can be observed with the use of CORS in a sand-

boxed iframe. A CORS request contains an origin

header deﬁning the origin where the request origin-

ated from. In a sandboxed iframe with a unique ori-

gin, the value of the origin header will be null. Even

though the server has no concrete origin information

about the request, CORS speciﬁcally supports grant-

ing the null origin access to the resource by adding

the appropriate response headers. This behavior en-

ables the use of the value null as a wildcard, since any

document can sandbox itself in an iframe and send

requests with an origin-value of null. The main dif-

ference with the already available wildcard in CORS

(∗) is that the null origin allows the use of credentials,

a feature that is explicitly forbidden for the wildcard.

A concrete scenario where the use of CORS from

a sandbox poses a problem is a legitimate site that

wants to expose an API to a selected set of origins

that use a sandboxed iframe for additional security.

Since the site offering the API no longer receives ori-

gin information, it is unable to enforce access con-

trol restrictions and can either disallow the use of the

API or allow the use of the API from a null origin.

The former prevents the sites using the API from de-

ploying a sandboxed iframe, the latter forces the API

provider to open up its API to all origins. The inter-

action between the sandbox attribute and CORS is a

violation of the second security goal, stating that co-

existing security mechanisms should interact grace-

fully.

Web developers should never allow the use of a

null origin in a CORS request, unless they explicitly

intend to provide wildcard-accessible authenticated

APIs. Explicitly checking for the null value and im-

mediately returning a response is the safest approach.

The wildcard (∗) offered by CORS can be used to

grant any origin (unauthenticated) access to a speciﬁc

part of the application.

4 RELATED WORK

In this section, we brieﬂy discuss relevant subsets of

the vast amount of related work on web application

security. First, we highlight traditional approaches,

SECRYPT2012-InternationalConferenceonSecurityandCryptography

260

focused on patching basic ﬂaws in the classical web

paradigm (either in the code itself, or via client- or

server-side hardening). Next, we describe a recent

and gradual evolution in web security towards patch-

ing standards and sandboxing environments imposing

additional server-driven constraints on the integrated

content. Finally, we discuss previous security assess-

ments on web application standards, and their ability

to address some of the core security problems in web

security in the speciﬁcations themselves.

An inherent problem of web security is the vast

amount of deployed browsers and applications, each

from multiple vendors in multiple versions. Mak-

ing fundamental security improvements while still

maintaining existing functionality is hard, as docu-

mented by the traditional patching of the basic web

paradigm. For most classical web application vulner-

abilities, such as cross-site scripting, SQL injection

and cross-site request forgery, adequate safe-practices

and countermeasures have been proposed (Su and

Wassermann, 2006; Zeller and Felten, 2008), but are

unfortunately not always consistently deployed. This

has in turn led to policy-driven security on the client-

side, such as Content Security Policy (Sterne and

Barth, 2011) or X-Frame-Options (Law, 2010).

Complementary, several techniques offer con-

trolled execution of third-party JavaScript (as is typ-

ically the case in mashup compositions (De Ryck

et al., 2011a) and online advertisements (Ter Louw

et al., 2010)), which is especially relevant because

of the obviously increased set of features available

to JavaScript developers. Common approaches to-

wards ﬁne-grained behavior control are the use of

security wrappers in JavaScript (Phung et al., 2009;

Magazinius et al., 2010), policy-controlled client-side

sandboxes (Ter Louw et al., 2010; Miller et al., 2008)

and the use enhanced browser support (Meyerovich

and Livshits, 2010; Van Acker et al., 2011).

Web standards have been scrutinized for security

before, with positive results. The most relevant re-

lated work, discussed below, typically goes into great

detail on narrowly scoped functionality. Unfortu-

nately, detailed analysis techniques do not scale well

to a set of multiple speciﬁcations and their potential

interactions. Our work is complementary to such de-

tailed analysis because of its broad set of features and

functionality, and the explicit focus on potential con-

sequences of interactions between these features.

Barth et al. investigated the security of frame

communication in browsers (Barth et al., 2008), dis-

covering both weaknesses in fragment identiﬁer mes-

saging, an unintended communication channel, and

postMessage, the designed communication channel.

Their work goes into great detail on a speciﬁc aspect

of client-side functionality, using very speciﬁc secur-

ity goals. Similarly, Akhawe et al., who use formal

modeling to ﬁnd design vulnerabilities in web spe-

ciﬁcations (Akhawe et al., 2010), speciﬁcally focus

on web security mechanisms. The formal model is

also useful to evaluate the security of newly proposed

countermeasures (De Ryck et al., 2011b).

Other related research is by Rydstedt et al. on the

effectiveness of clickjacking defenses (Rydstedt et al.,

2010) and of Aggarwal et al. about the actual security

of private browsing modes (Aggarwal et al., 2010).

In this area, we also consider the work of Doty et

al. about privacy issues in the Geolocation API (Doty

et al., 2010) and the work of Heiderich et al. on cross-

site scripting attack vectors in HTML5 (Heiderich,

2011) to be highly relevant.

5 DISCUSSION

The security analysis shows that the studied web spe-

ciﬁcations already achieve a high level of security,

but still violate the two security goals, preservation

of security invariants and graceful interaction of co-

existing features, on various occasions. These viola-

tions can be ascribed to the fragile balance between

functionality and security, a thin line to walk, es-

pecially in the web application ecosystem, with the

standards simultaneously serving browser vendors,

web developers and users. This analysis focuses on

imbalances at the expense of security, but likewise,

sacriﬁces will have been made in favor of security and

at the expense of functionality.

The violations of the security goals documented

in the analysis should be addressed by the speciﬁca-

tions in the future. Whenever possible, the function-

ality should be updated and adapted to better respect

the balance with security. Whenever there is a case of

favoring functionality over security, these design de-

cisions and their consequences should be included in

the speciﬁcation. This ensures that all invested parties

are informed of potential security risks and can take

appropriate measures.

Even though we rigorously and systematically

performed our security analysis, guided by the two

security goals stated before, it remains an informal

and manual analysis approach. Full completeness can

only be achieved by formal analysis techniques. Ma-

jor disadvantages of formal analysis are the tremend-

ous amount of effort involved, as well as scalabil-

ity to complex models. This work has already star-

ted (Akhawe et al., 2010) with an Alloy model of

web interactions, which is already pushing the limits

of model ﬁnding tools. Continuing this work, pos-

ASecurityAnalysisofEmergingWebStandards-HTML5andFriends,fromSpecificationtoImplementation

261

sibly using other formalisms than Alloy, has a great

potential to further enhance or validate the security of

emerging web technologies and speciﬁcations.

The full report of the security analysis (De Ryck

et al., 2012) does not only cover potential increases

of the attack surface, but also discusses how speciﬁc-

ations suffer from under-speciﬁcation and ambiguity,

leading to inconsistent and potentially insecure imple-

mentations as a consequence. Additionally, the full

report illustrates that mainstream implementationsnot

always comply with explicit security considerations

stated in the speciﬁcations. As a consequence, se-

curely speciﬁed features might in practice still be vul-

nerable due to this mismatch.

6 CONCLUSIONS

In this paper, we aimed to thoroughly scrutinize emer-

ging web standards for potential security problems.

We performed a systematic and repeatable analysis

using two generally applicable security goals: preser-

vation of security invariants and graceful interaction

of co-existing features. From the security analysis, we

can conclude that the overall security of the standards

is quite good. Nonetheless did we identify several vi-

olations of one of the stated security goals under cer-

tain application-speciﬁc circumstances.

ACKNOWLEDGEMENTS

The results presented in this paper build on experience

from an earlier security analysis performed with the

support of ENISA (De Ryck et al., 2011c). This re-

search is partially funded by IBBT, IWT, the Research

Fund K.U. Leuven and the EU-funded FP7-projects

WebSand and NESSoS.

REFERENCES

Aggarwal, G., Bursztein, E., Jackson, C., and Boneh, D.

(2010). An analysis of private browsing modes in

modern browsers. In Proc. of 19th Usenix Security

Symposium.

Akhawe, D., Barth, A., Lam, P. E., Mitchell, J., and Song,

D. (2010). Towards a formal foundation of web se-

curity. Computer Security Foundations Symposium,

IEEE, 0:290–304.

Barth, A., Jackson, C., and Mitchell, J. C. (2008). Securing

frame communication in browsers. In In Proceedings

of the 17th USENIX Security Symposium (USENIX Se-

curity 2008).

De Ryck, P., Decat, M., Desmet, L., Piessens, F., and

Joosen, W. (2011a). Security of web mashups: a sur-

vey. In 15th Nordic Conference in Secure IT Systems

(NordSec 2010).

De Ryck, P., Desmet, L., Joosen, W., and Piessens, F.

(2011b). Automatic and precise client-side protection

against csrf attacks. Computer Security–ESORICS

2011, pages 100–116.

De Ryck, P., Desmet, L., Philippaerts, P., and Piessens, F.

(2011c). A security analysis of next generation web

standards. Technical report, European Network and

Information Security Agency (ENISA).

De Ryck, P., Desmet, L., Piessens, F., and Joosen, W.

(2012). A security analysis of emerging web standards

- extended version. Technical Report CW 622, De-

partment of Computer Science, K.U.Leuven, Leuven,

Belgium.

Doty, N., Mulligan, D. K., and Wilde, E. (2010). Privacy

issues of the w3c geolocation api.

Heiderich, M. (2011). Html5 security cheatsheet. http://

code.google.com/p/html5security/.

Law, E. (2010). Combating clickjacking with x-frame-

options. http://blogs.msdn.com/b/ieinternals/archive/

2010/03/30/ combating- clickjacking- with- x- frame-

options.aspx.

Magazinius, J., Phung, P., and Sands, D. (2010). Safe wrap-

pers and sane policies for self protecting javascript. In

15th Nordic Conference on Secure IT Systems.

Meyerovich, L. and Livshits, B. (2010). Conscript: Spe-

cifying and enforcing ﬁne-grained security policies

for javascript in the browser. In Security and Privacy

(SP), 2010 IEEE Symposium on, pages 481–496.

Miller, M.S., Samuel, M., Laurie, B., Awad, I., and Stay, M.

(2008). Caja: Safe active content in sanitized javas-

cript. http://google-caja. googlecode. com/ﬁles/caja-

spec-2008-01-15.pdf.

Phung, P. H., Sands, D., and Chudnov, A. (2009). Light-

weight self-protecting javascript. In Proc. of the 4th

International Symposium on Information, Computer,

and Communications Security, pages 47–60.

Rydstedt, G., Bursztein, E., Boneh, D., and Jackson, C.

(2010). Busting frame busting: a study of clickjacking

vulnerabilities at popular sites. In in IEEE Oakland

Web 2.0 Security and Privacy (W2SP 2010).

Sterne, B. and Barth, A. (2011). Content security policy.

http://www.w3.org/TR/CSP/.

Su, Z. and Wassermann, G. (2006). The essence of com-

mand injection attacks in web applications. In ACM

SIGPLAN Notices, volume 41, pages 372–382. ACM.

Ter Louw, M., Ganesh, K. T., and Venkatakrishnan, V. N.

(2010). Adjail: Practical enforcement of conﬁdenti-

ality and integrity policies on web advertisements. In

19th USENIX Security Symposium.

Van Acker, S., De Ryck, P., Desmet, L., Piessens, F., and

Joosen, W. (2011). Webjail: Least-privilege integra-

tion of third-party components in web mashups. In

Proceedings of the 27th Annual Computer Security

Applications Conference, pages 307–316. ACM.

Zalewski, M. (2011). Postcards from the post-xss world.

http://lcamtuf.coredump.cx/postxss/.

Zeller, W. and Felten, E. W. (2008). Cross-site request for-

geries: Exploitation and prevention. Technical report,

Princeton University.

SECRYPT2012-InternationalConferenceonSecurityandCryptography

262