1

Web-platform security guide:

Security assessment of the Web ecosystem
Philippe De Ryck, Lieven Desmet, Martin Johns and Frank Piessens

Abstract—In this document, we report on the Web-platform PART I: F OUNDATIONS OF THE W EB PLATFORM
security guide, which has been developed within the EC-FP7
In the first part of the guide, we briefly recap and discuss
project STREWS. Based on their research, the STREWS con-
sortium argues that in order to strengthening the Internet (e.g. the foundations of the Web ecosystem. The goal of this first
against pervasive monitoring), it is crucial to also strengthen part is to provide the reader with a basic understanding of the
the web application ecosystem, the de-facto Internet application Web ecosystem, needed to understand the security assessment.
platform. Over the last 25 years, the Web ecosystem went through
The Web security guide is the result of a broad security a series of technological waves (as depicted in Figure 1),
assessment of the current situation on the Web1 . It looks at enriching the platform to the current level where it provides
the Web ecosystem and provides a timely and comprehensive an attractive alternative to stand-alone applications (or even
web security overview. It was written by the STREWS replacing the operating system itself). Evolutions in the Web
Consortium, that brings together a unique set of expertise in platform include richer presentation capabilities (e.g., graph-
Europe to grasp the complexity of the Web platform and its ics, style sheets and multimedia tags), client-side state (cookies
security characteristics. It is unique because it brings together and storage), client-side interactivity (JavaScript, the DOM
strong peers in academic web security research in Europe, and a rich set of JavaScript APIs), as well as rich Internet
a large European software vendor, and principal actors in Applications (such as Flash, ActiveX and Silverlight).
standardisation activities in W3C and IETF, the predominant
User (Browser) Web Server
specification developing organisations for the Web. HTTP Transfer protocol

The Web platform security guide consists of four parts, and URIs
looks as follows: HTML
1) The first part gives a comprehensive overview of the HTTPS Transfer protocol
current Web and the expected developments in the near
future. Richer presentation: JavaScript APIs:
Graphics, Stylesheets, … Web Messaging, XHR, CORS, Web Storage, 
2) Based on the understanding of the Web ecosystem in the IndexedDB, Web SQL database, File API, WebRTC, 
first part, the second part captures the breadth and com- Client‐side interactivity: Sysinfo API, Geolocation API, Media Capture API
plexity of the Web security vulnerability landscape. DOM, JavaScript, …
HTML5 elements:
It describes the Web assets that are worth attacking Client‐side state: Audio, video, canvas 
and lists the capabilities attackers may have at their HTTP Cookies wave 1
Rich Internet Applications:
disposition and discusses the commonly-used attacker Flash, Active X, Java, Silverlight 
wave 2
models.
3) In the third part, the twenty most representative at- Fig. 1: The Web ecosystem went through a series of techno-
tack techniques are discussed and analyzed, grouped logical waves.
in seven high-level threat categories.
The guide presents and discusses the latest state-of-the- The resulting ecosystem is represented in Figure 2, and
art, both from a research perspective as well as from is discussed in more detail in part I of this security guide.
a standardization perspective. Important in this context is that, although the Web ecosystem
Moreover, the guide provides a catalogue of best prac- has grown substantially over the last two decades, the basic
tices designed to mitigate the threats discussed, and to security model of the Web still strongly relies on the Same-
gradually improve the trustworthiness of web-enabled Origin Policy (SOP) from the mid 1990s. Major changes
services. to this model face prohibitive deployment obstacles, as the
4) Part four gives the full Web security threat landscape currently-deployed legacy of web applications relies on the
as an overview, indicates upcoming challenges resulting legacy model’s properties.
from the change of the web ecosystem and hints at some This tension between ever-increasing complexity and lim-
interesting opportunities for future research. ited built-in security fuels a continuous arms race between
In the following paragraphs, we briefly highlight the most attackers and defenders, as will be illustrated by the wide
important contributions and key takeaways for each part. variety of attacks discussed later in this document.
1 The Web-platform security guide can freely be downloaded at http://www. After reading part I, we expect all readers to share a
strews.eu/results/5-web-platform-security-guide common level of understanding of the Web platform. To
 2

(a) Client Side (b) Network (c) Server Side

Fig. 2: Perspectives on the contemporary Web platform

serve the different audiences of the guide, the basic Web For instance, if an attacker wants to tamper with an Ap-
building blocks in part I are interleaved with some more plication Transaction (e.g. forge a new wire transfer in an
advanced insights and additional pointers to aspects of the Web online bank application), the attacker can do this by first com-
ecosystem, targeted to more advanced readers from industry promising the Client-side Application Code asset, as depicted
and academia. For novice readers, the appendix discusses in in Figure 4. Similarly, there are various ways to compromise
more detail the underlying technologies of the Web, such as the client-side code, and an attacker might choose to intercept
HTML, CSS, JavaScript and HTTP. and manipulate the network traffic in order to control the
client-side application code.
PART II: T HREATS TO THE W EB PLATFORM
In part II, we identify the assets of the Web ecosystem, Application asset:
1

based on the model and concepts developed in part I, and

enumerate the set of capabilities an attacker might have.
Application transaction 2
The assets are approached from an application-agnostic,
technical point-of-view, but they can easily be correlated to
actual business values once enriched with concrete application
context. For instance, during the risk analysis of an E-Health
3
web application, the Server-side Content Storage asset can be
instantiated with electronic health records of the patients, and
use their business value in the risk calculations. 4
The Web security platform guide identifies assets in the web
infrastructure (i.e., the client and server machines), assets in
the application (such as client-side application code and server-
side application storage) and user-related assets (such as au- 5
thentication credentials and personal information) (Figure 3).
6

Web Assets
Fig. 4: Walking the asset tree.

Infrastructure  Application  User To be able to define an attacker’s power in an unambiguous

assets assets assets way, the platform guide enumerates the set of primitive and
disjoint attacker capabilities. Essentially, attacker capabilities
Fig. 3: Assets in the web infrastructure, assets in the applica- are the lowest level of capabilities available to an attacker.
tion, and user-related assets Examples of such fine-grained attacker capabilities are Host
content under a registered domain or Send a well-formed
For each asset, we discuss its importance and the attacker’s request to the application.
incentives for compromising this asset, and analyze how an The attacker capabilities can be composed to give a specific
asset can be compromised. In order to structure the variety threat model, if desired. Within the security guide, we discuss
of ways available to compromise an asset, we use trees to threat models used in academic web security literature since
explicitly define high-level threats against an asset. These 2008 (such as the web attacker, the related-domain attacker
threats are intermediate steps that an attacker has to take and the passive network attacker). We explicitly decompose
in order to compromise an asset, and are typically common the threat models into attacker capabilities, and compare them
across different assets. against each other (as illustrated in Table I).
 3

er

er
er

ack

ack
ack

Att

Att
Att

ork
ker

ork
ain
ker
er

etw
ttac

om

etw
st

ttac
Po

eN
tA

d- d

eN
bA
m

dge

late

siv

tiv
ru

Pas
We

Ga

Ac
Re
Fo
Register Available Domain ? ? ? ? ?
Host Content under Registered Domain ? ? ? ? ?
Host Content under Existing Domain ?
Register Valid Certificate for Domain Name ? ? ? ? ?
Respond to Legitimate Client Request ? ? ? ? ?
Send Well-formed Request to Application ? ? ? ? ? ?
Send Arbitrary Network Request to Server ? ? ? ? ?
Eavesdrop on Network Traffic ? ?
Generate Network Traffic ?
Intercept and Manipulate Network Traffic ?
TABLE I: An overview of academic threat models, decomposed into fine-grained attacker capabilities.

The main advantages of using attacker capabilities over complex attack scenarios, an attack tree is provided to
threat models are that (1) they precisely define what technical guide the reader through the different steps of the attack.
capabilities an attacker has, and that (2) they can be more Mitigation techniques The most common mitigation tech-
dynamically composed into new threat models that list the niques for the attack are presented and discussed. In
minimal set of capabilities needed to perform an attack. this section, the reader gets an understanding of how
the mitigation technique works, and insights in their
PART III: ATTACKS ON THE W EB PLATFORM effectiveness (or ineffectiveness).
State-of-practice In the state-of-practice section, insights and
In the third part, the web security vulnerability landscape statistics on the prevalence of the attack, or the level
is constructed, by investigating how an attacker can execute the of deployment of mitigation techniques are presented.
threats to compromise an asset. To do so, the threats identified This provides researchers and industry players a good
in part II are grouped together in seven high-level threat understanding of the current security state of the web
categories: ecosystem: Are available best practices being deployed?
1) Impersonating users How widespread are known vulnerabilities? How often
2) Forging requests are these vulnerabilities being attacked?
3) Attacking through the network Unfortunately, this highly-relevant material is not always
4) Controlling the client-side context available, or difficult to acquire. This platform guide
5) Attacking the client-side infrastructure aimed to include the publicly available statistics, which
6) Directly attacking the web application was possible for about half of the attack techniques
7) Violating the user’s privacy presented.
For each of the seven high-level threats, the most represen- Research and standardization activities The security guide
tative attack techniques have been selected, and are reported summarizes the most important recent and ongoing re-
in more detail. Selection of the representative subset of attack search and standardization activities concerning this type
techniques is mainly driven by their prevalence, associated risk of attack. This collection of key reference material cap-
and potential impact, as indicated by the OWASP top 10, the tures most relevant evolutions and trends in academia
CWE/SANS Top 25 most dangerous programming errors and (mainly geared towards an academic audience), and on-
relevant academic work, as presented in important security- going activities and new initiatives in standardization.
related journals and conference proceedings. The guide aims Best practices The guide provides a set of best practices
to achieve completeness for the set of threats in part II, and to to tackle this attack, now and in the near future. This
achieve a good coverage on the variety of attack techniques catalogue of best practices should guide industry actors
in part III. to gradually improve the security of their web-enabled
services.
Each of the 20 attack techniques in the Web security
platform guide is documented according to the following PART IV: C ONCLUSION
structure: In the conclusion of the Web platform security guide, we
Problem description The problem description explains in link together the assets from part II and the corresponding
detail the problem setting, the goal of the attack, the attacks from part III. This overview of the Web security threat
necessary attacker capabilities and how the assets get landscape is depicted in Table II, and can be interpreted in
attacked. If multiple variations of the attack technique two ways:
exist, the differences are briefly discussed. For more • On the one hand, Table II illustrates the impact of a
 4

ode
e

e
rag

rag

s
nC

tial
ns
Sto

Sto

ctio

den
n
tio

n
sio

atio
ent

ent

ica

nsa

Cre
t

Ses
nsi
ont

ppl
ont

orm
ine

Tra
ine

Tra

ion
ed
eC

eA
eC
ch

ch

Inf
ion
cat

cat
in
Ma

Ma

-sid

-sid

-sid

nti

nti
cat

al
nt

s on
ver

ver
ent

ent

ent

the

the
nte

pl i
Ser

Ser

Per
Cli

Cli

Cli

Au

Ap

Au
Co
Session Hijacking ?
Session Fixation ?
Brute Force ?
Stealing Authentication Credentials ?
Cross-site Request Forgery ?
Login Cross-site Request Forgery ?
Clickjacking ?
Eavesdrop on Network Traffic ? ? ? ? ? ? ?
SSL Stripping ? ? ? ? ? ? ?
Man-in-the-Middle Attack ? ? ? ? ? ? ?
Internal Attacks on TLS ? ? ? ? ? ? ?
Cross-site Scripting ? ? ? ? ? ?
Compromising JavaScript Inclusions ? ? ? ? ? ?
Malicious Browser Extensions ? ? ? ? ? ? ?
Drive-By Download ? ? ? ? ? ? ?
Attacking Local Infrastructure ? ? ? ? ? ? ?
Injection Attacks ? ? ? ? ? ? ? ?
Break Access Control ? ? ? ? ? ? ? ?
User Tracking/Fingerprinting ? ? ? ?
History Sniffing ? ? ? ?
TABLE II: Overview of the Web security threat landscape: mapping assets from part II to attacks from part III.

particular Web attack on the various assets of the Web in research and standardization) follow the same pattern:
platform. For instance, a successful injection attack can The server issues a security policy, the policy is pushed
potentially impact 8 of 10 assets of the Web platform. towards the client as part of the web application, and the
• On the other hand, Table II enumerates the list of attacks client is responsible for enforcing the policy correctly.
that need to be mitigated in a particular Web application Well-known examples in recent specifications are CSP,
in order to protect an asset. For instance, in order to fully X-Frame-Options, HSTS, and Certificate Pinning.
protect application transactions, at least 17 attacks need In this context, the Content Security Policy (CSP) seems
to be mitigated. to be a very promising additional layer of defense,
The overview of the Web security threat landscape clearly protecting against cross-site scripting and UI redressing.
illustrates the complexity of the Web ecosystem. To improve Legacy building block as weak links. We clearly see the
the end-to-end security, it is necessary to raise the bar on urge to fix some of the legacy building blocks of the
several (if not all) topics in parallel. Web model. For instance, passwords are still the primary
authentication technique on the Web, and are almost
Finally, this document expresses the insights of the always used in combination with bearer tokens (e.g.,
STREWS consortium on the way forward for web application session management cookies and OAuth tokens).
security. We point out a set of interesting challenges for se- Major changes to legacy building blocks of the Web
curing the Web platform, opportunities for future research and model face prohibitive deployment obstacles, as the
trends in improving Web security. Some important examples currently-deployed legacy of web applications relies on
include: the legacy model’s properties, and the adoption of best
practices is rather slow.
Limited adoption of the best practices. There exists a re-
Increasing need to compartmentalize web applications.
markable mismatch between state-of-the-art mitigation
As web applications are becoming larger, and contain
techniques and best practices being available for almost
more third-party components (e.g., third-party JavaScript
all vulnerabilities, and we measured only a limited adop-
inclusions), the secure containment or sandboxing of
tion of the best practices in the state-of-practice.
untrusted parts of the web application becomes crucial.
The question remains as to how web site owners can
Current state-of-the-art containment techniques still need
be incentivized to actually deploy best practices on their
to mature, both in terms of policy specification as well
sites? Similarly, to track the adoption rate over time, it
as enforcement techniques.
is important to have good metrics and measurements in
Shift from purely technical to user-centered. Web security
place to be able to assess the state-of-practice of the Web
is partially shifting from a purely technical topic to a
ecosystem.
user-centered topic. This is illustrated with the numerous
Trend towards server-driven browser enforcement.
phishing and social engineering attacks, and the web
Significant areas of novel web security technology (both
 5

permission model relying more and more on decisions of

the end-user. For sure, attackers will more and more target
the user as the weakest link of the web infrastructure.
Moreover, UI security becomes a key factor in delivering
a secure web ecosystem, especially with the rise of new
web-capable devices, such as smartphones, tablets, etc.
The web permissions model is extraordinarily complex,
and hard to understand for the end-user. Key questions are
how to involve (or not involve) users in security-related
web decisions and how to communicate back security
results to the user.
These topics have been identified during the assessment,
and a representative selection will be tackled in more detail
in the upcoming case study and the roadmapping activities of
the STREWS project.

ACKNOWLEDGEMENTS
The research of this Web-platform security guide is research
project STREWS (Strategic Research Roadmap for European
Web Security), which is funded by the European Union’s 7th
Framework Programme.
The Web-platform security guide is freely available at http:
//www.strews.eu/results/5-web-platform-security-guide.
The security guide incorporates contributions from Bert
Bos, Elwyn Davies, Philippe De Ryck, Lieven Desmet,
Stephen Farrell, Martin Johns, Wouter Joosen, Sebastian
Lekies, Jan Tobias Mühlberg, Frank Piessens, Thomas
Roessler, and Steven Van Acker.