DOM-based XSS Attacks Taxonomy and Case Studies

DOM-based XSS Attacks

M.Sc. Project thesis

Zdravko Danailov Krassen Deltchev

zdravko.danailov@rub.de krassen.deltchev@rub.de

Ruhr-University of Bochum

Faculty Of Electrical Engineering And Information Technology

Chair for Network and Data Security
Horst-Görtz Institute

Prof. Dr. Jörg Schwenk

First examiner: Prof. Dr. Jörg Schwenk
Adviser and Second examiner: Dipl.-Ing. Mario Heiderich

16. April 2012

Abstract
Concerning the matter of modern Internet Security, we are obliged to understand the meaning and
proper utilization of Web Application Security and Web Services Security. In this paper, we discuss
one of the recent and misunderstood problems, related to Web Application Security.
In distinction to the standard Web Application Cross-Site Scripting Attack Vector, DOM-based XSS
conveys a way to inject malicious payload on Layer 7 ISO/OSI Model on the client-side
implementation of the Web-Application logic. Precisely, DOMXSS represents a subclass of this
dominant Web Application Attack Vector – XSS.
Therefore, we observe the comprehensive environmental aspects of DOMXSS; we divide them in
two layers – Programming environment, which concerns the DOM Abstraction Model, Web-
Application coding language and the rendering engine of the Web client (Web-Browser); and
Implementation environment – the Web Application programming logic and source code.
Because of the fact, that this subclass, should be still considered as misapprehended and
consequentially – systematically avoided by the security and scientific communities, the main
objectives of this project thesis are: proposing and evaluating of related categorizations and meta-
model, demonstration of case studies and sanitization best practices, and further propositions across
the problem – DOM-based XSS attacks.

Keywords
XSS, DOM-based XSS, DOMXSS, DOM-based XSS taxonomy, Web Application Security, Mobile
Security, Web Application Attack Vector, Application Flow Analysis, Function Flow Analysis, Data
Flow Analysis, Static Model Checkers, Dynamic Model Checkers, JSLint, Web Application
scanners, DOMinator, Security patterns, JavaScript/AJAX Coding Patterns, JavaScript/AJAX
Design Patterns, Anti-Patterns, DOM and Web-Browser Patterns, HTML5, Filters, ESAPI4JS,
ECMAScript conventions, Secure ECMAScript, Direct Proxies

Contents
Abstract ..................................................................................................................................................
List of Tables......................................................................................................................................IV
List of Figures......................................................................................................................................V
List of Abbreviations.........................................................................................................................VII
1 Introduction .....................................................................................................................................1
1.1 Limitations of the paper............................................................................................................3
2 General approach to DOMXSS and limitations of the paper ..........................................................4
2.1 What is DOM? .........................................................................................................................4
2.2 Types of XSS Attacks...............................................................................................................4
2.2.1 Non-persistent XSS Attacks..............................................................................................5
2.2.2 Persistent XSS Attacks......................................................................................................6
3 DOMXSS Attacks............................................................................................................................9
3.1 Historical reference work..........................................................................................................9
3.2 Explanation of the technical background................................................................................11
3.2.1 Environment and Threat Model......................................................................................11
3.2.2 Classifications.................................................................................................................16
3.2.3 Sources and Sinks...........................................................................................................16
3.2.4 URL obfuscation – Encoding/Decoding.........................................................................21
3.2.5 Attack scenarios..............................................................................................................23
3.2.5.1 Case study: Testing environment and educational scenario....................................23
3.2.5.2 Case study: Real time scenario – AOL....................................................................26
3.2.5.3 Example: Stored DOMXSS.....................................................................................30
3.2.5.4 Example: JavaScript private functions ...................................................................31
4 Prevention and defense...................................................................................................................35
4.1 Lack of sufficient collaboration between the teams, involved in the Defensive STO Model 37
4.2 Function Flow and Data Flow Analysis..................................................................................41
4.3 JavaScript/AJAX patterns – false usage of patterns and conventions ...................................43
4.4 False usage of filters...............................................................................................................48
4.5 Related tools...........................................................................................................................58
4.5.1 Tools' Requirements Rules (TRRs).................................................................................58
4.5.2 Penetration Testing Tools................................................................................................61
4.5.2.1 Static Code Checkers: DOM XSS Scanner.............................................................63
4.5.2.2 Educational Tools: Web Goat (IDE/Framework)....................................................64
4.5.2.3 Dynamic Web-App Scanners: DOMScan...............................................................66
4.5.2.4 Dynamic Web-App Scanners: DOM Tracer (Mozilla Firefox)...............................66
4.5.2.5 Dynamic Web-App Scanners: Web Scarab and Web Scarab-NG...........................67
4.5.2.6 Mixed tools: DOM Snitch.......................................................................................68
4.5.2.7 Mixed tools: DOMinator Project (Mozilla Firefox)................................................69
4.6 Synopsis..................................................................................................................................73
5 Future work....................................................................................................................................75
6 Conclusion......................................................................................................................................77
Affirmation.........................................................................................................................................IX
Bibliography.......................................................................................................................................XI
List of Links.....................................................................................................................................XIII
Appendix.........................................................................................................................................XVI

III

List of Tables
Table 1: Classification of sources.......................................................................................................19
Table 2: Classification of sinks [L7]...................................................................................................20
Table 3: Encoding Differences, derived from [L13]..........................................................................22
Table 4: Address bar double encoded XSS.........................................................................................22
Table 5: Decoding differences, derived from [L13]...........................................................................23
Table 6: Scenario types.......................................................................................................................23
Table 7: Code fragment of vulnerable to P-DOMXSS Web-Application [L10]................................31
Table 8: DOMXSS on private JavaScript function [L25]..................................................................32
Table 9: DOMXSS S3MM database proposal....................................................................................33
Table 10: Defensive STO Model........................................................................................................36
Table 11: A general classification of patterns.....................................................................................44
Table 12: Example 1 for an Anti-pattern, a well-known DOMXSS Sink [S10]................................46
Table 13: Example 2 for an Anti-pattern, a well-known DOMXSS Sink [S10]................................47
Table 14: DOM and Browser patterns [S10]......................................................................................47
Table 15: Browser dependent cssText Attack Vector [L7].................................................................49
Table 16: Listing 2, example of JavaScript filtering code for e-mail.................................................51
Table 17: Integrated XSS user agent filters........................................................................................55
Table 18: Evaluation of OP2 secure Browser.....................................................................................58
Table 19: TRRs...................................................................................................................................59
Table 20: TRRs matrix according to the particular tools....................................................................60
Table 21: DOMXSS Tools list............................................................................................................62
Table 22: WebGoat topics...................................................................................................................64
Table 23: innerHTML examples, html5.org.......................................................................................65
Table 24: Web Scarab-NG Plug-ins....................................................................................................68
Table 25: B. Kochher, sample #7, [L36]...........................................................................................72
Table 26: 2010 at a glance – Sorted by industry sectors [WHW11].............................................XVIII
Table 27: JavaScript Coding patterns [S10].....................................................................................XLI
Table 28: Representatives of JavaScript Design patterns [S10]......................................................XLI
Table 29: List of Security patterns [S06]........................................................................................XLII
Table 30: Listing 1, example of HTML input form, e-mail filtering via JavaScript.....................XLIII
Table 31: Google search input filter escaping in 4 stages..............................................................XLV
Table 32: Microsoft Bing input filter escaping in 5 stages..........................................................XLVII
Table 33: Functional vs. Security testing [RL10]............................................................................LIII
Table 34: Standards & Specifications of EFBs [RL10]...................................................................LIII
Table 35: Basic EFD Concepts [RL10]............................................................................................LIII
Table 36: Definition of Execution Flow Action and Action Types [RL10].....................................LIII
Table 37: 0day DOM XSS Scanner vulnerable code fragment at flattr.com module....................LXV

IV

List of Figures
Figure 1: XSS basic classification, derived from A.Klein [L3]..........................................................9
Figure 2: XSS classification, 2007, R. Hansen et al...........................................................................10
Figure 3: General attack strategy for Web-Applications....................................................................12
Figure 4: DOMXSS Threat Model [L13]...........................................................................................16
Figure 5: Client-side implementation of the Web-App Business logic Model...................................17
Figure 6: Processing of Source and Sink ...........................................................................................18
Figure 7: DOM-based cross-site scripting after stage 4.....................................................................25
Figure 8: Application Flow walk-trough of real time scenario-AOL.................................................27
Figure 9: AOL scenario stage 2 – using cURL (step 1)......................................................................28
Figure 10: AOL scenario stage 2 – using cURL (step 2)....................................................................28
Figure 11: AOL scenario stage 3........................................................................................................29
Figure 12: Security-concerned Software Development deterministic state machine (DFA*)...........37
Figure 13: Sanitization components, applied to the victim environment...........................................38
Figure 14: Involved teams in the Web-Application production.........................................................39
Figure 15: Structure of a security team..............................................................................................40
Figure 16: Sanitization workflow.......................................................................................................41
Figure 17: JavaScript Design Patterns, derived from [S10]...............................................................45
Figure 18: Client-side Web-Application filtering...............................................................................49
Figure 19: DOMXSS Tools................................................................................................................61
Figure 20: DOMinator Architecture, Stefano Di Paola, [L12]...........................................................71
Figure 21: Secured Web-Application, considering DOMXSS...........................................................74
Figure 22: The Web Hacking Incidents DB '09 [BS09] .................................................................XVI
Figure 23: Attack Pathways, 2011 [AE11]......................................................................................XVI
Figure 24: Whitehat Security Top 10 [L6].....................................................................................XVII
Figure 25: Percentages of vulnerabilities resolved ( compared by extensions) [WHS10]............XVII
Figure 26: Top Ten Vulnerability Classes (compared by extension) [WHS10]............................XVIII
Figure 27: Basic architecture of DOM objects in HTML, derived from [L1]................................XIX
Figure 28: ERM attack Model, NP-XSS..........................................................................................XX
Figure 29: ERM attack Model, P-XSS............................................................................................XXI
Figure 30: DOM Visualizer, DOM Tree for AOL.de.....................................................................XXII
Figure 31: DOM Visualizer, DOM Tree for RUB.de...................................................................XXIII
Figure 32: 3-Tier architecture [L16].............................................................................................XXIV
Figure 33: Application Architectures are Evolving from 3-Tier to SOA [L17]...........................XXIV
Figure 34: The 2 Top-level organizing principles in Modern Software continue to converge [L18]
.......................................................................................................................................................XXV
Figure 35: Web 2.0 or SOA? [L19]................................................................................................XXV
Figure 36: Technologies / standards used in a web oriented architecture [L20]..........................XXVI
Figure 37: A view of WOA [L21].................................................................................................XXVI
Figure 38: The high levels of success of Web 2.0 Models for creating Software Ecosystems helped
"discover" WOA and inform SOA [L22]....................................................................................XXVII
Figure 39: More technical representation of Web 2.0 Architecture [L14]..................................XXVII
Figure 40: Browser [L15]..........................................................................................................XXVIII
Figure 41: Browser/Application View [L23].............................................................................XXVIII
Figure 42: Browser DOM [L15]...................................................................................................XXIX
Figure 43: Technology Shift and Trend [L15]..............................................................................XXIX
Figure 44: Cross DOM access [L23].............................................................................................XXX
Figure 45: Double encoding result 1..............................................................................................XXX
Figure 46: Double encoding result 2............................................................................................XXXI

V

Figure 47: DOM-based cross-site scripting stage 1.....................................................................XXXI
Figure 48: DOM-based cross-site scripting stage 2....................................................................XXXII
Figure 49: DOM-based cross-site scripting stage 3....................................................................XXXII
Figure 50: DOM-based cross-site scripting before stage 4........................................................XXXIII
Figure 51: DOM-based cross-site scripting after stage 5..........................................................XXXIII
Figure 52: AOL scenario stage 1...............................................................................................XXXIV
Figure 53: AOL scenario stage 3 enhancement.........................................................................XXXIV
Figure 54: Globo scenario stage 1..............................................................................................XXXV
Figure 55: Globo scenario stage 2 – crafting the exploit (step1)...............................................XXXVI
Figure 56: Globo scenario stage 2 – crafting the exploit (step2)...............................................XXXVI
Figure 57: Web-Application complete Enterprise Security Model [L26]................................XXXVII
Figure 58: Microsoft Security Software Development Lifecycle (MS SSDLC) [L27]...........XXXVII
Figure 59: DOMXSS Scanner....................................................................................................XLVIII
Figure 60: WebGoat Browser Interface......................................................................................XLVIII
Figure 61: DOMScan Interface.....................................................................................................XLIX
Figure 62: Drawback in DOMScan DOM calls detection............................................................XLIX
Figure 63: DOMTracer incompatible with newest version of Firefox.................................................L
Figure 64: Web Scarab Interface..........................................................................................................L
Figure 65: Web Scarab-NG Interface.................................................................................................LI
Figure 66: DOM Snitch activity log...................................................................................................LI
Figure 67: S3 Meta-Model...............................................................................................................LII
Figure 68: Improving the Testing process of Web Application Scanners [RL10]...........................LIV
Figure 69: Flow based Threat Analysis, Example [RL10]..............................................................LIV
Figure 70: DOMXSS – aol.de on iOS v.5.0.1 (9A405).....................................................................LV
Figure 71: DOMXSS – ma.la on iOS v.5.0.1 (9A405)....................................................................LVI
Figure 72: Error response on safari with disabled JavaScript – aol.de, concerning SbO...............LVII
Figure 73: DOMXSS – aol.de on Android 2.3.5...........................................................................LVIII
Figure 74: DOMXSS – aol.de on Android 2.3.5 with diocument.cookie payload........................LVIII
Figure 75: DOMXSS – ma.la on Mozilla Firefox for Android 2.3.5..............................................LIX
Figure 76: DOMXSS – student.mit.edu on Android 2.3.5................................................................LX
Figure 77: Phase 2: Error response..................................................................................................LXI
Figure 78: Phase 3: first Popup in Mozilla Firefox .......................................................................LXII
Figure 79: Phase 3: second Popup in Mozilla Firefox ..................................................................LXII
Figure 80: Phase 3: Popup in Safari.............................................................................................LXIII
Figure 81: Phase 3: second Popup in Opera..................................................................................LXIII
Figure 82: Persistent XSS in the source code after successful injection .....................................LXIV

VI

List of Abbreviations

0day Zero-day exploit/attack
AFA Application Flow Analysis
BM Business Model
CSFU Cross-site File Upload
CSRF Cross-site Reference Forgery
DB Database
DDoS Distributed denial-of-service
Dev-Team Developers Team
DFA Data Flow Analysis
DFA* Deterministic finite automaton
DOM Document Object Model
DoS Denial-of-service
DSTO Defensive STO Model
e.g. for example
ESAPI Enterprise Security API
FFA Function Flow Analysis
FO-Team Forensics Team
i.e. id est
IR-Team Incident Response Team
ISO International Organization for Standardization
LDA Linear Discriminant Analysis
MS Microsoft
MS SSDLC Microsoft Security Software Development Lifecycle
NP-DOMXSS Non-persistent DOMXSS
NP-XSS Non-persistent XSS
OOP Object-oriented programming
OS Operating System
OSI Open Systems Interconnection
OWASP The Open Web Application Security Project
P-DOMXSS persistent DOMXSS
PoC Proof of Concept
PT-Team Pen-testing Team

VII

QA-Team Quality Assurance Team
Regex Regular expression
RE Requirements engineering
RFI Remote File Inclusion
RIA Rich Internet Applications
ROA Resource-oriented Architecture
SbO Security by Obscurity
SDLC Software Development Lifecycle
SE Social Engineering
SH Social Hacking
SOA Service-oriented Architecture
SOP Same-Origin-Policy
SQLIA SQL injection attack
SSDLC Security Software Development Lifecycle
S3MM Sources/Sinks/Storage Meta-Model
STO Strategical Tactical Operational Model
SVN Subversion
TRRs Tools' requirement rules
WAS Web Application scanners
WASC Web Application Security Consortium
Web-Dev community Web developer community
WOA Web-oriented Architecture
WOT Web of Trust
W3C W3 Consortium
XHR XMLHttpRequest
XSS Cross-site Scripting

VIII

1 Introduction

1 Introduction
Nowadays, the differences between Web Application Security and Web Services Security can be
hardly distinguished. On one hand their essence is still misunderstood, on the other these security
areas could not be strictly separated apart. Therefore, the attacks and more precisely the attack
scenarios, related to these areas, should be evaluated as unique, respecting the aspects of: their
utilization and the approach to categorize them, which are prerequirements for a precise and
complete examination and respectively for an effective sanitization.
In this project thesis, we shall observe Cross-Site scripting attacks on the client-side of modern Web
applications, which consider exploits on the JavaScript implementations of the programming logic.
Other representatives of such attacks on CSS and XML should not be discussed due to the scope of
the paper, which is outlined in the section about the paper's limitations.
To achieve a taxonomic soundness of the thesis exposition, we feel obliged to give some short
historical facts about JavaScript in this introduction.
In 1995 Netscape1 proposes LiveScript2 as an additional layer on top of the HTML. Thus, the static
HTML pages become interactive and furthermore this scripting language is directly integrated into
the Web-Browser. This methodology is well accepted and extended by two separated organizations.
On one hand the Mozilla Foundation develops and maintains JavaScript3, on the other Microsoft
supports JScript4. Ironically, the so called “Browser Wars”5 6 reflects also on the standardization of
this scripting language. Consequently to this fact, arises confusion in the Web Developers
communities. First malicious attempts to exploit the LiveScript derivatives follow as an avalanche
effect respectively. These attacks designate a new Web-Application Attack Vector – Cross-Site
Scripting, or shortly XSS. Nowadays, XSS injections are presented not only on JavaScript, but also
on PHP, ASP, JSP etc. The strive for an adequate and completed standard, considering the
LiveScript proposal and respecting the current development stages of JavaScript and JScript, is
presented by the evolution of ECMA-262 scripting language, or shortly ECMAScript7. For the
interested reader, please consider further reading on Section 4.4 False usage of filters. We shall
reckon still JavaScript and JScript for not completely compliant to the Modern Standards
represented by ECMAScript.
Let's proceed more detailed with the introduction of the attacks on JavaScript. As already mentioned
above, the most common and vigorous Web Application Attack Vector is considered to be the
Cross-Site Scripting, XSS8[AE11], [WHS10], [WHW11]. According to OWASP9 and WASC10, XSS
represents a TOP 10 Web Application Attack Vector; statistically, see Appendix Figures 22, 23, 24,
25, 26 and Table 26, designated on second place as most severe Web Application threat. XSS is
sophisticated, dynamically evolving and expanding as an attack vector. This justifies the fact for the
existence of wide range of XSS attack paradigms and the intensive occurrence of new ones.
Moreover, we observe a general categorization of the XSS subclasses in two main branches –
sever-side and client-side. The common and well-known Web-based attacks concern an
1 http://www.scriptingmaster.com/javascript/javascript-history.asp
2 http://javascript.about.com/od/reference/a/history.htm
3 https://developer.mozilla.org/en/JavaScript
4 http://msdn.microsoft.com/en-us/library/72bd815a.aspx
5 http://blogs.law.harvard.edu/doc/2011/01/30/learnings-from-the-browser-wars/
6 http://www.zdnet.com.au/a-history-of-web-browser-wars-339312301.htm
7 http://www.ecmascript.org/
8 http://www.crn.de/security/artikel-8538.html, http://www.cenzic.com/resources/hackinfo/owasp-top-10-2010/,
http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html
9 http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf
10 http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting

1

1 Introduction

exploitation of Web-Application servers. Server-side XSS attacks are designated as follows –
Persistent and Non-persistent XSS attacks. The research on these XSS subclasses in the security
and scientific communities is well established. In distinction to this, the other branch of XSS
attacks, client-side XSS, is stated to be incomprehensively documented, imposed upon the fact that
the research information: conventions, approaches, best practices, Cheat Sheets etc. are scattered
and discontinuously represented. As the major representative of client-side XSS attacks should be
considered the DOM-based XSS attack. In this paper, we describe this subclass as follows:
definition of the operational flow, areas of application, illustration on significant case studies,
estimation of the impact factor of DOMXSS. Moreover, we illustrate some suggestions for
sanitization approaches on specific implementations of DOMXSS.
In order to scrutinize the basic features and behavior, as well as some existing scenarios for
DOMXSS Attacks, the structure of this project thesis proceeds as it follows: Chapter 2 focuses on
the general structure of XSS Attack Vector, its separation on subclasses, including Persistent
(stored), Non-Persistent (reflected) and DOMXSS attacks, and gives brief information about their
specific characteristics and malicious nature. A complete analysis of the DOMXSS attacks, on
behalf of the Strategical/Tactical/Operational Model, will be performed in Chapter 3 . Furthermore,
Subsection 3.2.5 illustrates some known examples and case studies of DOMXSS, together with the
factual course. Possible remediation techniques, such as implementation and extension of Regex(s),
proper application of JavaScript patterns and filters etc., will be specified in Chapter 4 . Besides, it
presents a theoretical approach on what more could be applied to the problem, in account of
Function Flow and Data Flow Analysis. Chapter 5 will propose some important aspects for future
work on the problem, while some of them will be outlined in appropriate parts in the exposition of
the paper. In Chapter 6 , the conclusion on the topic will be presented.

2

1 Introduction

1.1 Limitations of the paper
In this project thesis, we should explicitly outline the following limitations in our research and
thesis exposition:
• Language requirements:
• as given in RFC 211911
• For the purposes of this paper, we shall use He, His, which should be understood as
she/he, her/his, respecting the lexicological relation to terms like intruder, attacker,
user etc.
• As we discuss DOM-based XSS on JavaScript client-side Web-Applications, we shall not
evaluate DOMXSS implementations, including CSS and XML.
• XML DOMXSS attacks require in most cases discussions on Web Services Security.
• If we provide limited information on the mentioned above languages, this we should utilize
only to respect the consistency of the exposition.
• We use the term Web client to distinguish precisely the group of Web-Browsers, RSS
Readers etc., from the other types of User Agents as: Robots, Crawlers, Spiders etc.,
respecting the RFC 2616, Section 14.4312; see also footnote13.
• Note, that the proposals, described in our paper are not approved on strong mathematical
level, which is considered as an appropriate scientific level, and are valuable topic for future
work.
• In some cases, we should outline conventions and patterns, with their appropriate references,
without demonstrating them in exhaustive manner.
• We should also allow us to demonstrate interesting and important techniques and
taxonomies, as related works, which are considered by their developers as not completed.
• Every aspect, which is a good candidate for a future work on the topic, should be outlined in
the appropriate stage of the paper exposition and explicitly in Chapter 5.

11 http://tools.ietf.org/html/rfc2119
12 http://tools.ietf.org/html/rfc2616#section-14.43
13 http://www.user-agents.org/

3

2 General approach to DOMXSS and limitations of the paper

In this chapter, we explain, what is DOM, in order to define it as a term and how it associates with
JavaScript. Furthermore, a taxonomy of the XSS attacks will be presented, as we divide the main
class (XSS) on three general subclasses: Persistent, Non-Persistent and DOMXSS attacks.

2.1 What is DOM?
The development of JavaScript is as controversial as the Browser evolution on itself. The so called
“Browser wars” arouses the utilization of two different formulations of the scripting language. As
mentioned in the introduction part, on one hand, Mozilla Foundation maintains JavaScript, which
implementation is applicable almost everywhere, on the other, Microsoft supports the JScript,
applicable only on the MS Internet Explorer. Furthermore, we outlined, that this paradigm
inevitably leads to lack of standardization, concerning the proper scripting language implementation
by the Web-Dev community. For these reasons, the W3 Consortium decides to propose a unifying
language-independent convention, a cross-platform model, more specific the Document Object
Model14, which includes a solution, how to solve the gap between the two different scripting
language dialects. DOM presents an interface between JavaScript and JScript. Moreover, in order to
use both languages on behalf of HTML-enabling dynamic characteristics of the Web-content, DOM
represents an instrument in the hands of the Web-Devs. The kernel in the structure of DOM is the
“document” Object. Its methods grant the implementation and execution of functions in both of the
scripting languages. This is well illustrated in Figure 27, see Appendix.
Nevertheless, there are still differences between the realization of W3C DOM specification, which
prompts a challenge even today, to respect and to compound the specifications of JavaScript and
JScript.
The lack of standardized solution hampers the Web-Dev community to implement a proper scripting
code in modern Web-Applications until nowadays. As already outlined JavaScript and JScript are
not fully compatible with the ECMA-262 Standard, please see Chapter 4 .
This unavoidably arises the question about the security aspects of the released code in Production
environment.
The other fact, that the complexity of the Web-Applications is vastly growing, stigmatizes modern
Web-Apps, as extremely attractive for malicious activities.
In the next section, we should explain more detailed the different attack techniques on modern
Web-Applications and HTML based content.

2.2 Types of XSS Attacks
As we outlined in the introduction section, the XSS attack vector splits into three main branches,
mainly: Non-Persistent, Persistent and DOM-based XSS attacks. These types dispose, firstly
regarding their art of execution: server- or client-side. Secondly, they differ in their efficiency, as
well as their discoverability and countermeasures. So, before we proceed with the objectives of this
project thesis, we will scrutinize in detail the basic features of the XSS attack subclasses as follows.

14 http://www.w3.org/DOM/

4


2.2.1 Non-persistent XSS Attacks
The Non-Persistent XSS (NP-XSS) attacks should be illustrated in our paper's exposition as the first
subclass of the XSS attack vector. Since, we want to make clear how the NP-XSS works, we
should describe a simple attack scenario. It proceeds in few steps, as it follows:
1. In order to execute an attack, a malicious user (attacker) should find a potential vulnerability
on a site. As a vulnerability input source should be designated for example a text box, search
box etc., which gives the possibility, that one can enter string (text) or an HTML-based
code, an image etc., considered as an appropriate Web-content on a dynamic Web-App:
• Find a submitted on the Web and unsanitized XSS exploit, e.g. 0day NP-XSS.
• Use a search engine, e.g. Google source15 and extract the URL of a currently running
Web-Application, which still implements such exploit in its source code.16
2. In the second phase of this attack scenario, the attacker should try to force the Web server to
process and execute the malicious code:
• As the attacker locates a proper input source on the Web-App, such as input field or
parameter of the GET-request, related to the URL of the unsecured site, He can start
with a trial and error approach to inject malicious code.
• Another alternative for the attacker is to launch an internal search within the site, if
the specific Web-App has an integrated search engine. By simulation of a common
search, the attacker can test the security filters, which are implemented on the search
box, in order to sanitize the Web-Application input stream. At first, using the search
engine, He does not produce any suspicious noise, but observes the error response of
the system – assuming the fact, that no matter what search input is utilized, the
security mechanisms on the web-server should be activated by default.
3. After completing this testing (sample-approach), the intruder gathers and organizes the
feedback about the weaknesses in the security of the Web-App, with the goal of a possible
attack utilization.
4. In order to increase vastly the impact of the attack, He advertises a link to the already
exploited Web-App, by posting it on different blogs, forums, sending it as a spam e-mail,
per VoIP (Skype) or other messenger software, such as Yahoo Messenger etc. This process
can be automated and amplified, by using bots17 for this purpose. The attacker can fulfill
furthermore two different actions:
• to make the normal18 users to embody themselves as actual attackers ('confused
deputy'19) and cause DoS/DDoS on the Web-App.
• to achieve a data steal, such as: cookie theft, ID theft etc.

15 http://code.google.com/
16 Another approach is to deploy Web-Application scanners, e.g. Acunetix Web Vulnerability Scanner (Free Edition),
Netsparker [Community Edition] , Qualys Freescan etc., on a particular domain (URL), which can automate the
exploit detection process; this method utilizes the so called point'n'scan technique, on behalf of a list with known
exploits.
17 http://cert.uni-stuttgart.de/doc/netsec/bots.html
18 We specify the term “normal user” as – an inexperienced and not security concerned user, utilizing daily Internet
activities on the Web. This user can become with greater likelihood a “Confused deputy”, see CSRF[KD10].
19 http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html, see further:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

5


This abstract scenario is presented more illustrative as a process flow diagram in the Appendix part
of the paper, see Figure 28.

2.2.2 Persistent XSS Attacks
The stored XSS attacks embody another subclass of the XSS attack vector. In order to clarify the
methodology of the Persistent XSS (P-XSS), we will represent another simple attack scenario:
1. In the preparation phase, the attacker should find a Web site (Web-based content), on which
He could post messages in HTML-based code such as: message boards, blogs, HTML-based
e-mail forms etc. Before He can proceed with the implementation of a malware code,
considering its proper20 execution, one should test the security filters on the site. If the Web-
App is not properly sanitized against integration of malicious JavaScript code, the intruder
could make (legitimate) HTML-conform postings, where vigorous script is integrated. Its
proper execution should be considered with greater likelihood, because of the continuous
operating of the compromised Web-Server, which acts as a propagation environment for the
malicious JavaScript code and the existence of the Browser rendering engine – interpreting
HTML-conform code by default. A normal user, who has no advanced security protection,
integrated within His Browser, should not be able to ascertain, that a fraudulent script is
executed in background.

2. As the attacker has completed the phase of preparation and script injection, He proceeds
with the process of spreading out a specially prepared link, in order to increase the impact of
the attack. As it was already described in Subsection 2.2.1 , the link distribution is achieved
by a dispatch over e-mail or via different instant messengers, using fake/already stolen Ids/e-
mail accounts.
For the better illustration of the P-XSS workflow, refer to the process flow diagram in the
Appendix, see Figure 29.

As we have already presented two fundamental attack scenarios for NP-XSS and P-XSS, we would
like to describe in detail the design and general application purposes of the attacks, by discussing
the differences between them. The distinguishing approach is based on the following profound
criteria21:
• complexity of attack preparation,
• complexity of attack deployment (Reproducibility),
• application (affected entities),
• impact (damage potential) and
• discoverability.

The complexity of the attack preparation by NP-XSS and P-XSS is almost the same: the attacker
has to find a currently running/0day exploit and further to search for a suitable Web-App candidate

20 We define here „proper“, considering it from the attacker's point of view, who also strives efficient and effective,
intelligently implemented fraudulent code. In particular, this has nothing to do with the moral perspective,
concerning the victim's damages.
21 https://www.owasp.org/index.php/Threat_Risk_Modeling

6


to compromise it. The complexity of deployment includes the testing phase, the utilization of XSS
code injection and the consecutive propagation/spread out. While by NP-XSS, the attacker tries to
locate input sources, such as: cookies, input fields (e.g. Web-App internal search engine) and GET-
requests, by P-XSS, His goal is to exploit the ability to dynamically extend the HTML-based
content via posting. In both cases (NP-XSS, P-XSS), the cracker22 is proceeding further with the
deployment of the attack scenario, as detecting the sanitization filters on the Web-App. If such
filters are implemented, the attacker tries to escape them, starting a blinded testing23. He refines this
iterative method, until He gains sufficient feedback, concerning the successful further
implementation of the malicious XSS injection. In case of no positive results, He applies this
scenario either to a different pattern in the directory structure of the same domain, a subdomain, or
another detected URL. Note, that these steps could be also applied concurrent on different Web-
Apps. As He succeeds to avoid the input source sanitization, the cracker injects the XSS code and
can further improve the hack. Heretofore, we cannot observe extensive differences in the
deployment complexity. At last, we should take in account the end stage, concerning the spread out
of the attack. In distinction to NP-XSS, by stored XSS, the intruder does not need implicitly to
advertise the compromised Web-App. Though, if He decides to do so, He propagates just a legal
URL, because the host already includes the P-XSS in its HTML-source. This is not the case by NP-
XSS, where the distributed URL implies the malicious code. On one hand, this designates the
differences in the deployment complexity, on the other, it also denotes discrepancy by the level of
discoverability. A legal URL, without an injection payload, cannot be directly considered as a
malicious one, which impedes the proper heuristic evaluation. Thus, the discoverability of the P-
XSS is limited to observation of the Web-App source by security experts, who inevitably utilize
static or dynamic code-checkers for automated feedback. On the opposite side, the discoverability
of the NP-XSS could demand not only code inspection, but also a complete Function and Data Flow
Analysis [L2]. So, in order to detect and prevent a NP-XSS, only a source code investigation on the
Web-App is not sufficient. Moreover, the attack discovery demands an extensive forensics
inspection24 of the Web-application-sever log files, made by a security professional, utilizing semi-
automated approaches. Taking these facts into count, the discoverability of the NP-XSS is more
complex than this of the P-XSS. We should outline, that both of the attacks cover the following
server-side injections – same origin XSS25, cross origin XSS. This designates the same level of
application. At last, concerning the impact or damage potential of the attacks, both XSS types
present very severe security threat on Web-application platforms.

Heretofore, we introduced the first two well-known subclasses of the XSS attack vector and
clarified their differences and similarities, concerning their better illustration and understanding.
Using the same pattern, we should represent the main objective of our paper – DOM-based XSS
attacks, which concern especially Cross-Site Scripting injections on the client-side implementation
of the Web-Application programming logic, in the next Chapter 3 .

22 In our paper, we use the term „cracker“, describing an attacker with malicious intentions.
23 In both cases, blinded testing could be utilized manually or using Web-Application scanners.
24 By P-XSS, the Forensics professional correlates at least the following evidences: the persistence of malicious code
within the Web-Application source, which is deterministic, and the log file entries on the server. In distinction to
this, by NP-XSS, the malicious code is just reflected by the server. Therefore, evidence is stored at most in the log
files. This enforces the professional to search for other evidences, which can be correlated to the log files, with the
goal to strengthen the Forensics heuristics and thus predict properly the core of the reflected XSS attack.
25 Samy Worm: http://namb.la/popular/

7

3 DOMXSS Attacks

3 DOMXSS Attacks
In the previous chapter, we have paid attention to attacks, which exploit the technical abilities of
JavaScript, but require as a jump-start a running Web server. On the contrary, DOM-based XSS
presumes only the Browser engine for launching XSS attacks on JavaScript host objects[S10]. Their
main representatives are the DOM-objects. These facts inevitably provoke the questions: Is a
cracker capable of exploiting such JavaScript objects? Are we capable as security professionals to
harden those, predict and prevent future exploits on Object-oriented level, concerning JavaScript
Web-apps?

3.1 Historical reference work
Even though, DOMXSS is thought to originate from 2004/2005, the first reports about the attack
are arisen in the early 2002 by Thor Larholm. For the interested reader, please check [L8].
In 2005, Amit Klein has publicized the first widespread paper on DOMXSS. The paper “DOM
Based Cross Site Scripting or XSS of the Third Kind”[L3] considers the theme and make it
accessible for the general public. Furthermore, it points out not only properties of the third subclass
XSS attacks, but also refers to some of the fundamental differences to the other XSS types (NP-
XSS and P-XSS). Based on the information back then, Amit Klein has made a basic classification,
mainly: a list of cases, concerning DOM-based XSS. Let's illustrate the general XSS structure with
its subclasses in Figure 1:

Figure 1: XSS basic classification, derived from A.Klein [L3]

In 2007, this categorization is extended and precised by Robert 'Rsnake' Hansen et al., see
[JGETA07], by specifying the main DOMXSS subclasses: Persistent DOM-based XSS (P-
DOMXSS) and Non-persistent DOM-based XSS (NP-DOMXSS). These inherit the features, which
DOMXSS proposes, and additionally designate the core for the technical implementation, the
specific DOMXSS attack is based on: if the prerequirement for the DOMXSS is P-XSS-based, we
categorize the P-DOMXSS subclass, in the opposite case – NP-DOMXSS subclass.
The differentiation between NP-DOMXSS and P-DOMXSS, shown in Figure 2, is on hand of the
utilized attack technique to achieve a DOMXSS exploit. In the first case, aiming an execution of
DOM-based XSS, the attacker uses the methodology, applicable for NP-XSS. By advertising a
specially crafted link to the potential victims, the cracker endeavors falsifying a property of a node
or even extending the DOM structure with a new node with its own properties, within the document

9

3 DOMXSS Attacks

object, loaded in the users' Browser. If the client-side logic26 of the Web-Application is not properly
sanitized, the forged document object will be conducted by the Browser engine. In the second case,
utilizing P-DOMXSS, the attacker uses Persistent XSS approach. An example of stored DOMXSS,
where we shall explain in detail the technical background of the attack, see Subsection 3.2.5 .
Moreover, in combination with other attack techniques such as Cross-site Reference Forgery
(CSRF)[KD10], Cross-site File Upload (CSFU)[L4], Remote File Inclusion (RFI)[L5][WASC10]
etc., the impact of the NP-DOMXSS and persistent DOM-based XSS is vastly increasing.

Figure 2: XSS classification, 2007, R. Hansen et al.

As Amit Klein has pointed out the basic subclasses of the XSS attack vector, in “XSS Attacks –
Cross Site Scripting Exploits & Defense”, the authors make classification based on the
methodology, more exactly the essence and semantic of the attacks. Furthermore, they pay attention
for the first time to the Function Flow Analysis (FFA) and Data Flow Analysis (DFA), considering
the XSS vulnerabilities. In order to sanitize a Web-App, not only the input (input sources), but also
the output (output sources) must be examined and properly defined (applying DFA), as well as the
functional threads by the data processing must be carefully explored (applying FFA).
In 2007, Shreeraj Shah gives a well-illustrated approach, abstract and multilayer schemata to
represent sufficient architectures of fundamental topics such as: Browser DOM engine, AJAX
workflow Model, Threat Model etc.[L11]. In next year, Stefano Di Paola and Kuza55 represent the
“Attacking Rich Internet Applications”[L9] and introduce a classification of sinks and sources. This
extends the definitions of DOMXSS and allows more precise modular approach, which becomes a
substantial part of the sanitization process.
Rafal Los [RL10] puts forward, that the “point 'n scan”-scanning of Web-Apps is not sufficient for
Web-Application vulnerabilities analysis and represents a compete definition for Function Flow
Analysis and Data Flow Analysis. This extends the proposals, already given by Robert 'Rsnake'
Hansen et al. in 2007.
In 2011, Ory Segal [L10] enlarges the classification of Sources and Sinks by adding a new
parameter, respecting the Persistent DOMXSS: Storage. On behalf of the evaluation of existing
26 This should be explicitly explained in Section 3.2.1

10

3 DOMXSS Attacks

example, concerning the DOM-based exploit of HTML527 localStorage API, he proves the
correctness of the separation between DOMXSS subclasses, made in 2007 by R. Hansen et al.
Moreover, Ori Segal illustrates the unabated impact of these attack techniques, respecting the
newest HTML Standard.
Since the history of DOMXSS can be ascertained as sophisticated, which involves implicit
discussions on the terms of source code analysis, Application Flow Analysis (AFA) and further
development of classifications, we feel obliged to explain the technical background of the DOM-
based XSS and represent methods for source code development and analysis, as well as prevention
techniques in the following sections.

3.2 Explanation of the technical background
In this section, we will describe the Threat Model, the environment, as well as the important cruxes,
considering the DOMXSS attacks, in account of Sources and Sinks, URL obfuscation – encoding
and decoding.

3.2.1 Environment and Threat Model
Before we depict the DOMXSS Threat Model, we should make clear, what is the general approach
of an attacker and what are His main objectives, regarding Web-Applications. There are two
different types of Web-Apps, respecting the E-Commerce aspect: those with implemented Business
Model (BM) and such without any. Taking this matter into count, it is easy to say, that Web-
Applications with a BM will be more attractive for an intruder to be exploited.
The Web-App E-Commerce deployment Model consists of two main interrelated levels – Technical
(implementation) Model and Business Model. These elements can also be taken in the meaning of
perception, Business interpretation: as less strongly bound – low level, and strongly bound – high
level, because of their significance and internal logic, concerning the deployment and evaluation of
a strong Business Plan. Considering this two layer architecture, an attacker wants to gain control
over both levels, as the Business Model is with highest priority.
In order to explain the basic approach of an intruder, let us simplify the tactical scheme of the attack
strategy28:
1. The E-Commerce Web-Application Architecture is proposed as a two-nodes-graph with
bijective conjunction between the nodes.
2. The main target of an attacker is the Business Model of the Web-Application, which is
accessible29 only if the intruder controls the low level in the E-Commerce Web-App
Architecture.
3. Taking both prerequirements into count, the attacker uses “divide and conquer”-approach
(please, see Figure 3).

The process can be described into several steps of the four stages, Figure 3. Let's enumerate them
explicitly, as follows:

27 http://www.w3.org/TR/html5/
28 Attack strategy - exploit the Business logic Model to disrupt the E-Commerce revenue.
29 Accessible - Business logic Model experiences its realization on the Web via the Technical (implementation) Model

11

3 DOMXSS Attacks

1. The attacker has to find and exploit vulnerabilities into the Technical Model of the platform.
2. He gains control upon the low level of the Web-Application.
3. The intruder should try to disrupt the proper communication with the “Business Model”-
level.
4. The attacker mitigates the bijective conjunction between the two nodes, as conquering the
directed edge (Technical Model to Business Model). He disrupts the proper workflow
within the E-Commerce Architecture and consequently disarranges the “Business Model”-
level.
5. As a result, the attacker controls the feedback edge – from Business Model to Technical
Model, which makes the last one unusable.
6. In summary, He conquers the E-Commerce Web-App, and in great likelihood any other
kind of Web-Application representations.

Figure 3: General attack strategy for Web-Applications

As the Business Model is getting more complex to meet the customers needs, but the periods for the
release of the Web-Applications in Production environment remain the same or become even
reduced, the technical implementation has to strive to keep these development rates. Thence, several
important drawbacks occur:
• vastly growing load in the midrange systems – servers, due to the growing number of clients
and requests to the Web-App;
• escalating concurrency into the time-to-release deadlines;
• unstructured enhancement of the existing programming code in the Production environment;
• development of programming languages for speedy application build-up;
• ignoring of established security, coding and Design patterns;
• diverge-like operating development teams, to speedy fill in the coding gaps.

12

3 DOMXSS Attacks

These strategical changes in the Web-Application design and implementation cause numerous
tactical deployments and therefore more complex operative accomplishments. Like the further
development of the Web-Application Model is getting more compound, so the attacks and the
Threat Models consequently adapt to it. Moreover, back in the days the implementation of the
Business logic was predominantly Server-side oriented. Nowadays, we experience a migration in
the Business logic implementation to the client-side, to mitigate the drawbacks enumerated above,
which inevitably lead to server overload.
So, how does the modern attacks look like?
They hit on the enticing part of the Web-Application, more exactly the migrated Business logic on
the client-side, because there is no need to attack directly the server, as an advantageous way to
abuse the Business Model, which was a winning strategy concerning the old way of BM
implementation.
What makes these new attacks conceptually so different in contrast with the “old” well-established
Web attacks?
First of all, they demand advanced programming skills, including explicit knowledge of:
• Programming environment,
• semantics of the programming languages,
• programming conventions,
• Coding/Security/Design/Anti-/DOM and Browser patterns.
To summarize this briefly: the objective is not explicitly the client (user agent or end user), but the
client-side implementation of the Business logic Model.
Second, a profound and complete analysis and understanding of the modules, their coherence and
structural representation within the client-side environment have to be assured.
Please, check up the two examples of modern Web-Applications, demonstrating the complexity of
the DOM Construction, which represent, on one hand – a modern E-Commerce B2C Portal30, and
on the other – an educational Web site. These are illustrated in the Appendix part of the paper –
Examples of HTML DOM Visualizer31, Figures 30, 31. As the reader experiences, both of the Web-
Apps are highly complex. This inevitably leads to the conclusion, that a strong taxonomic approach
has to be conducted, in order to deploy the already proposed Web-Application analysis. Please note,
that this is executed with greatly likelihood by the modern Intelligent32 attackers and is highly
required to be awaken in the consciousness of the security professionals, as follows [Enum1]:
1. understand the fundamental structure of multi-tier SOA, concerning RIA;
2. understand the coding Implementation environment;
3. understand the Function Flow of the Web-Application;

30 http://www.akshayit.com/b2b-b2c-portals.html
31 http://www.aharef.info/static/htmlgraph/
32 In this paper, we shall propose the terms – Standard intruder (attacker) and Intelligent intruder (attacker), as follows:
a Standard attacker doesn't possess personal know-how, but copies and applies well-known, published on the Web,
attacks. Furthermore, He does not respect and evaluate the noise, created by the (iterative) attacks execution, and
also does not consider taxonomic knowledge management. In distinction to this, an Intelligent intruder is able of
creating and evaluating own attack scenarios, finding 0day-attacks and respecting the balance in the attack
environment, considering minimization of the caused noise, during the (iterative) attacks execution.

13

3 DOMXSS Attacks

4. understand the Data Flow of the Web-Application;
5. understand how to apply proper security policies to harden the preceding aspects, as
mentioned in 1 – 4.
The DOM-based XSS is a good representative of such modern attacks. Let's demonstrate this,
taking into count the proposed conditions, enumerated above.
At the beginning, we want to make a retrospective illustration on behalf of several figures, to
explain the migration of the Business logic to the client-side and demonstrate the tight and enduring
consolidation of the technical implementation with the sophisticated Business Model.
The classic Technical Model, 3-Tier Model (Figure 32), which is still usable in many Web-
Applications, denotes the starting point for Business logic realizations on the Web. As well-known,
it consists of: the Client Tier, Application Tier and Data Tier. The complete Business logic is
integrated within the Application Tier, which explains the attack strategy – to conquer the BM, i.e.
exploit the Application Tier. Some attack representatives are SQLIA[KD10], the already fully
explained NP-XSS and P-XSS (please, see Section 2.2 ) and other, that involve as a prerequirement
to exploit also the Client Tier – CSRF33, see further [KD10].
With the reinventing of the Web34 – the Web 2.0 evolution, the 3-Tier Model becomes insufficient,
which explains the need for more refined and feature-rich model – the Service-oriented
Architecture, SOA. This tendency is well-illustrated in Figure 33, where the main advantages of the
SOA Model over the 3-Tier Model are enumerated.
Moreover, the unabated demand for further development of SOA and Web 2.0, engendered by the
vastly growing E-Commerce and ever and anon advancing Business Model, impose a convergence
between these top-level organizing principles (Figure 34).
At Figure 35 is shown the SOA Model. Compared to the 3-Tier Model (Figure 32), the reader
should notice the differences between the Client Tier and the Presentation Layer – SOA implies the
migration of the BM to the Presentation Layer, where the Web clients include not only HTML, but
also AJAX and RIA.
The outlined migration of the BM on the client-side, is realized adequately on the level of Object-
oriented programming (OOP) and DOM. Thus, the client-side coding layer is technically
implemented in SOA via the Presentation layer, e.g. AJAX and RIA, as shown in Figure 35. Exactly
these two components will be the main target of modern Intelligent intruder attacks. Please note, as
already stated in the limitation section of the paper, the scope of our research is AJAX-/JavaScript-
based DOMXSS.
To complete this retrospection, we should illustrate the end stadium, which we are aware of, and
should be most probably extended in the future. The complete convergence of Web 2.0 and SOA
defines a new term – Web-oriented Architecture, WOA. This definition proposes extensive features.
For an instance, the Data Tier of the 3-Tier Model becomes Resource-oriented Architecture (ROA)
in the WOA Model. The complete modern taxonomy is precisely illustrated in Figure 36.
Concerning the basics in the technical implementation of WOA, Figure 37 gives a good overview.
Finally, we would like particularly to demonstrate the complete emerging process of Web 2.0 and
SOA with the explicit allocation of WOA as a derivative of this process (Figure 38).
We shall extend these tendencies with more detailed schemes, related to our scientific research on
the problem. We shall proceed in top-down manner to reach the particular level of a correct
33 http://shiflett.org/blog/2007/mar/my-amazon-anniversary
34 http://www.oracle.com/us/products/applications/atg/b2b-ecommerce-reinventing-333314.pdf

14

3 DOMXSS Attacks

technical explanation of DOMXSS.
On behalf of Enum1, we completed Enum1.1. As next, we would like to cover Enum1.2.
We should specify the SOA Web client, as the Web-Browser, due to the fact, that DOMXSS exploits
the client-side Business logic via the Web-Browser DOM rendering engine. Furthermore, any kind
of other SOA Web clients like RSS readers etc., based on Web-Browser rendering engines, reduces
the attack complexity to the level of DOM-based XSS on Web-Browsers. Let's designate explicitly
the Programming/attack environment, concerning Enum1.2, as follows:
• all kinds of Web clients, implementing different DOM-able Browser engines,
• JavaScript Programming language and AJAX,
• any type AJAX-based frameworks, JavaScript libraries,
• SOA Web-Applications based on AJAX.
Shreeraj Shah proposes a simplified scheme of WOA, pointing out in particular the Web client as a
Browser with the SOA client-side BM implementations, AJAX and RIA. We shall call this scheme
(Figure 39) sufficient for the technical exposition of DOM-based XSS. As next, Figure 40 gives a
general overview of the Browser rendering engine and most of the integrated SOA-related
implementation techniques as components. Important in this scheme is the demonstration of the
basic attack workflow, following the top-down approach – DOMXSS can start35 even on the
Presentation layer, e.g. exploiting an HTML5 APIs (such example, should be demonstrated in the
Subsection 3.2.5 : Attack scenarios), and proceed further with its execution on the Process&Logic
layer, where we notice, that the Browser renders the JavaScript (AJAX) code and the
DOM/Browser Events. If the DOM-based XSS attack scenario implies a Browser redirection to a
malicious Phishing site(s), this could be achieved via the “XMLHttpRequest” (XHR) object in the
Network&Access layer. In order to bypass the Same Origin Policy (SOP), the intruder should
exploit the Core Policies layer.
A comprehensive attack scenario with a prerequirement – Social Engineering (SE), could be also
applied to DOMXSS attacks. This is illustrated in the next Figure 41, which represents another
differentiation of the Browser components, concerning the User Layer and Browser Internals layer.
The AJAX and RIA, HTML/DOM Interface and UI Logic components belong to the User layer,
which explains the fact, that the user is able to interact, change and modify these by His own.
Therefore, a SE is possible and amplifies not only the impact of the attack, but also the complexity
of the defense and sanitization process(es) against DOM-based XSS. Furthermore, these
components implicitly interact with the DOM rendering engine, which abstract implementation in a
Web-Browser is demonstrated in Figure 42, from the Browser Internals layer. Hence, the already
presented basic workflow is feasible.
We would like also to demonstrate the simplified DOMXSS Threat Model, see Figure 4.
To complete the Enum1.2, we should outline the JavaScript/AJAX coding specifications, more
detailed in Section 4.3 JavaScript/AJAX patterns – false usage of patterns and conventions ,where
we shall explain in particular the questions, concerning the related conventions and patterns. At last,
let's illustrate a conclusive scheme (Figure 43), proving the proposed strategic differentiation
between DOM-based XSS and the classic XSS variations, i.e. DOMXSS is accessing the client-side
implementation of the Business logic Model. More precisely, the client-side components: DOM,

35 This is related especially to stored DOMXSS attacks; though, NP-DOMXSS can start directly on the
Process&Logic layer of the Browser engine.

15

3 DOMXSS Attacks

HTML5, RIA (Flash, Silverlight etc.), overlap the server-side components, as: Presentation layer,
Business layer and the Data Access layer, from the Web-Application Business logic.

Figure 4: DOMXSS Threat Model [L13]

3.2.2 Classifications
As our goal is to represent a complete description of the technical background of DOM-based XSS,
we utilize a well-known model – Strategical, Tactical and Operational Model (STO). In Subsection
3.2.1 , we covered the strategical level of the STO, explaining Enum1.1 and Enum1.2. More
precisely, we outlined the strategic discrepancy between the classic XSS attacks and DOMXSS.
Let's proceed further with the exposition of the tactical level, covering Enum1.3 and Enum1.4:
• understand the Function Flow of the Web-Application,
• understand the Data Flow of the Web-Application,
and how these are related to the technical implementation of DOM-based XSS.
We should deploy this, by specifying and describing the fundamental abstract constructs,
considering the following simple schema:
• explaining what are Sources, Sinks and Storage (HTML5) and how are they relevant to
DOMXSS
• explaining the fundamental matter of URL encoding/decoding and how this applies to
DOM-based XSS, concerning the aspects of attack payload obfuscation, as well as tainted
input data filtering (please, see Section 4.4 )

3.2.3 Sources and Sinks
We demonstrate in Subsection 3.2.1 Environment and Threat Model, that the execution of
DOMXSS passes through multiple layers in the Browser engine, which corroborate the fact, that the
evaluation and analysis of the attack is highly complex. So, is it possible to find a simplified
representation, a Meta-Model, which can give an answer to the basic questions, considering an
attack [Enum2]:
1. Where are the vulnerabilities in the Web-Application?
2. How to exploit them?

16

3 DOMXSS Attacks

3. Is the attack feasible or not?
As already stated, the attack exploits the client-side implementation of the Web-App Business logic
Model. Let's illustrate the client-side environment in Figure 5. It is obvious, that taking into count
all related aspects of the Programming environment, will make this simplified representation
unnecessary complicated. Though, a Meta-Model, which reproduces the Implementation
environment, can give an answer to the questions from Enum2 and sustain its simplicity and
compactness. In general an attacker is essentially interested in – whether the attack works on this
particular Web-App or not.
In 2005, as already mentioned, Amit Klein proposes, that there should be a third subclass of the
XSS attack vector (DOM-based XSS) and outlines different tactical implementations for the
successful completion of DOMXSS. In his online contribution (document), he enumerates these
tactical differences in a list, and points out the characteristic aspects, considering their separation.
Nevertheless, he notes that, the list is not exhaustive and will be a subject of further improvement
and extension. This should be considered as the starting point for the creation of a descriptive Meta-
Model, related to the tactical implementation of DOM-based XSS (see Enum2).
In 2007, the authors of [CW07] propose the terms: Source and Sink, according to the proper
modular static code analysis.
These two facts are used by Stefano Di Paola, who generalizes and completes the first fundamental

Figure 5: Client-side implementation of the Web-App Business logic Model

classifications of DOMXSS Sources and Sinks, related to the Implementation environment of Web-
Applications. Hence, we should propose his classification from 2008 [L7], as a foundation for the
Meta-Model, explaining the tactical characteristics of DOM-based XSS, Enum2. We should call this
model the Source/Sink/(Storage)36 Meta-Model, or S3 Meta-Model37 (S3MM). Let's enumerate its
main parameters: a Prerequiremet(s); a Source, a Sink, a possible Storage; a Payload (or just a PoC-

36 We should explain in the further exposition the existence of Storage in the S3 Meta-Model.
37 A complete illustration of the S3MM is given in Figure 67, Appendix.

17

3 DOMXSS Attacks

Payload) and an Impact (factor). These S3MM parameters should be briefly explained in the
Appendix. On behalf of these six parameters of the S3 Meta-Model, the workflow of the DOMXSS
should be completely described, according to its representation on the Implementation environment
of the client-side Web-App Business logic Model38, Enum2. Let's illustrate as a graph, the basic
scheme of S3MM (Figure 6).

Figure 6: Processing of Source and Sink

Both – Source and Sink, should be considered as an indispensable part of the Web-Application data
and function flow. In the Implementation environment (Figure 5), the Source denotes a code
fragment, which embodies a vulnerable node from the DOM abstraction, implemented on the client-
side of the Web-App. It represents the start node of a possible data flow, where an untrusted,
malicious input data is collected and with greater likelihood acquired for processing of the Web-
Application. The Sink determines the possible functional exploitability of a vulnerable source, e.g.
how a processed tainted data could be exploited by an attacker and applied to the Source.
On behalf of the Stefano Di Paola's proposed classification of Source/Sink, according to their
processing, there are specified three main types of Sources – direct, indirect and other object
Sources, as shown in Table 1.
Let's explain briefly, how Source's types differ from one another. The direct object Sources
reference to the DOM objects instantly and can be modified by the user/attacker.
As next, there are two different ways to induce indirect object Sources:
• values of direct object Sources are stored and used later to cause vulnerabilities and
incompleteness of the data, or
• an already stored server side data from direct object Sources is exploited and executed by
an attacker, causing a malicious input in the Web-App. [L7]
A taxonomic overview of Sinks is represented in Table 2.
As a most common and therefore dangerous type of Sinks are denoted the execution Sinks. Other
important representative, which will be described more detailed in 4.4 False usage of filters, is the
“cssText” Sink.
Further valuable type in this classification is the Location Sink. As stated in [L3], both
“window.location”, “document.location” and all their representatives are Sinks and Sources.
Moreover, the Location Sink can be divided into:
38 http://blogs.msdn.com/b/simonince/archive/2008/07/18/wcsf-application-architecture-7-remote-logic-with-wcf-
services.aspx

18

3 DOMXSS Attacks

• object assignment and
• location methods .
For further information, please visit [L7].

Main types Sub-types Representatives
(Source)
document.URL
document.documentURI
document.URLUnencoded (IE 5.5+)
document.baseURI
location/documentURI/URL Sources
location
location.href

Direct sources location.search
location.hash
location.pathname
Cookies Sources document.cookie
Referrer Source document.referrer
Window Name Source window.name
History Sources history.pushState()
history.replaceState()
localStorage
Indirect sessionStorage
sources Storage Object
IndexedDB
Database (Safari Only)
Server Response Sources
opener (IE <= 7 Only)
Other object parent/top/frames[i].obj
sources
event.data of onmessage event for
postMessage method
Table 1: Classification of sources39

Table 1 as well as Table 2 are derivations of the Stefano Di Paola's domxsswiki [L7], a DOMXSS
Test Cases Wiki Cheat Sheet Project. It is intended to be a central place, knowledge base, related to
the DOM-based XSS attack subclass. This project is still in development stage and not all Sinks and

39 For more information, please visit http://code.google.com/p/domxsswiki/wiki/Sources

19

3 DOMXSS Attacks

Sources are represented there, e.g. see Amit Klein's list. Furthermore, domxsswiki gives a great
opportunity for future work and Di Paola states, that contributions are welcome.

Main types Sub-types Representatives
(Sink)
eval
Function
Direct Execution Sinks Browser JavaScript execution setTimeout
sinks
setInterval
execScript
crypto.generateCRMFRequest
document.forms[0].action
Collection
document.forms[0].submit
document.forms[0].reset ...
Set Object Sinks
HTMLElement Sinks “document” object document.body
document.title ...
Style Sinks cssText Sink *
XMLHttpRequest Sink XMLHttpRequest.open ...
Set Cookie Sink “document” object document.cookie
location
location.href
location.pathname
location.search
Set Location Sink
location.protocol
location.hostname
location.assign
location.replace
Control Flow Sink
Use of Equality And Strict Equality
Math.random Sink
JSON Sink
XML Sink

Table 2: Classification of sinks [L7]

Concerning the Storage in the S3 Meta-Model, we should point out, that this component is given in
Table 1 and is specified as an indirect object Source. Though, in our proposed S3MM, it is treated
as a fundamental criterion for separation of NP-DOMXSS from P-DOMXSS (please, see Figure 2).
An example of stored DOM-based XSS is demonstrated in Subsection 3.2.5 Attack scenarios.

20

3 DOMXSS Attacks

Why is so important such separation?
If a DOMXSS is represented in the S3MM and its Storage component matters for the proper attack
execution i.e. that the Browser stores persistent the malicious payload, for example in the
localStorage object of the HTML5 Browser API plugin. This payload can be shared between
different DOM-based XSS attack techniques, which represents a cross DOM access, as stated in
[L23], illustrated in Figure 44.
That's why, we propose in S3MM a hard separation between the components Source and Storage.
By this way, we give a sufficient description of the S3 Meta-Model and would like to outline, that
we consider further refinement of the model, regarding its properties, represented in Table 1 and
Table 2, as an interesting objective for future work.
As the workflow description of DOM-based XSS, on behalf of our simplified Meta-Model is
completed, we proceed with the next valuable topic for the technical evaluation of the DOMXSS on
tactical STO layer in the following subsection.

3.2.4 URL obfuscation – Encoding/Decoding
In JavaScript, there are three fundamental methods, which can be used to encode (Table 3) or
decode (Table 5) String values:
• escape()/unescape()
• encodeURI()/decodeURI()
• encodeURIComponent/decodeURIComponent

We shall introduce them, respecting their enumeration order.
The escape()-method returns a String in Unicode format, where all non-ASCII characters, spaces,
punctuation40 etc. are replaced with “%XX”.41 Quite the contrary, the unescape()-method inverts a
specific hexadecimal value into an ASCII String.
The encodeURI() returns an encoded String representation of an URI. In comparison to the
escape()-method, it does not encode all characters42. An example for such characters can be seen in
Table 3. In order to encode these specific characters the encodeURIComponent should be used.
Please note, that the classification is not presented in the domxsswiki project [L7], which is another
topic for future work.
In the same manner, as Table 3 – Table 5 represents the general aspects, categorizing the URL
decoding differences. Note, that the table is incomplete and demonstrates only a few examples of
the important special character list.

40 With the exception of the following characters: * @ - _ + . /
41 The XX is equivalent to the hexadecimal value in the ASCII table.
42 The following characters are not escaped: , / ? : @ & = + $ #

21

3 DOMXSS Attacks

Char ASCII Number escape encodeURI encodeURIComponent
! 33 %21 ! !
# 35 %23 # %23
$ 36 %24 $ %24
& 38 %26 & %26
' 39 %27 ' '
… ... … … ...
Table 3: Encoding Differences, derived from [L13]43

How URL encoding and URL decoding are related to the tactical utilization of DOMXSS?
Via the URL encoding, an intruder can obfuscate successfully the payload of the DOM-based XSS
and thus pass through implemented Web-Application input filters. This increases the impact factor
of the attack and also impedes the client-side Forensics, if such is applicable. For further
information, please see Section 4.4 . A more advanced technique for payload obfuscation
demonstrates the double URL encoding44. To illustrate this, we want to represent the following case
study: a double encoding on non-WebKit-based Web-Browsers, see Figure 45 and Figure 46.
In [L24] is explained the principle of double encoding and a standard payload is presented in the
context:

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

We applied the payload directly into the address bar of the current version of the top Browsers,
which caused a NP-XSS in the following ones, see Table 4.

Browser Tested Browser engine Attack successful?
Browser version
Mozilla Firefox v.10.045 Gecko Yes, produces at least 2 Popups.
IE v.9.0.8112.16421 Trident Yes, produces 4 Popups.
Chrome v.16.0.912.77 m WebKit No, sanitized.
Opera v.11.61 Presto No, sanitized.
Safari v.5.1(7534.50) WebKit No, sanitized.
Table 4: Address bar double encoded XSS

This explains, that NP-XSS is feasible in recent non-WebKit-based Browsers, because of the double
URL encoding and automated URL completion. If such payload is applied to DOMXSS, as a value
43 We present an incomplete list.
44 https://www.owasp.org/index.php/Double_Encoding
45 In the most current version of Mozilla Firefox – v.11.0, this matter is sanitized.

22

3 DOMXSS Attacks

of the XHR-object, most probably a large group of Web clients,specified as default for the client
OS, will reproduce the demonstrated in Figures 45 and 46 attack.
It inevitably leads to the conclusion, that this issue should be discussed in detail in Chapter 4, where
filtering mechanisms on behalf of URL decoding and Regexes will be proposed. At last, we
encourage the testing of this exploit on mobile Web-Browsers as a future work.
Thus, we completed the discussion, concerning the tactical STO layer of DOMXSS. We would like
to proceed further with the operational layer of its technical description, which is considerably more
demonstrative for the reader, as some interesting examples and case studies of DOM-based XSS are
explained.

Char ASCII Number decodeURI decodeURIComponent
# 35 %23 #
$ 36 %24 $
& 38 %26 &
, 44 %2C ,
… ... … ...
Table 5: Decoding differences, derived from [L13]46

3.2.5 Attack scenarios

Before we proceed further with the detailed exposition of the attack scenarios, we want to give a
brief overview of the treated case studies and examples, shown in Table 6, in a reasonably arranged
format.

Scenario name Scenario type Scenario description
Web-Goat case study Testing environment and educational scenario
AOL case study Real time scenario
Stored DOMXSS example Exploit on HTML5 localStorage object

JavaScript private functions example Ignoring the JavaScript conventions

Table 6: Scenario types

3.2.5.1 Case study: Testing environment and educational scenario

The OWASP WebGoat47 Project framework provides a testing environment (under Windows/
46 We present an incomplete list.
47 https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

23

3 DOMXSS Attacks

Linux/UNIX) in which different types of attacks can be executed. It is developed and can be used
for educational purposes. We will describe more detailed this tool in Subsection 4.5.2 Tools, where
all utilities relevant for this paper are presented. Let's advance to the DOMXSS educational scenario
on behalf of the paradigm: AJAX Security::Lab:DOM-based cross-site scripting.
This scenario is presented in 5 simple steps, which are meant to be fundamental and should be
considered as crucial for the security of every Web-Application, that uses/implements JavaScript.
In the first step, the goal is to use the input field, which is unsanitized, in order to embed an image
element into the DOM of the Browser. In the input box, concerning the user name, is inserted the
code as shown in Figure 47, which enforce the Web-Application to show a picture from the
address– “http://localhost:8080/WebGoat/images/logos/owasp.jpg”. Here, we should mention, that
an intruder can manipulate, specify arbitrarily the image URL. Among the billions of pictures on the
Web, there are many with different inappropriate content, which can ruin the reputation of a Web-
App (E-Commerce, Educational etc.). Furthermore, the attacker can even alter the “src” attribute
value, to redirect the request to a Phishing Web site.

<img src="http://localhost:8080/WebGoat/images/logos/owasp.jpg" />

The modified DOM can be seen in Figure 47.
Going further with the “adjustment” of the DOM Construction, the second stage is about the
execution of an alert screen (Pop-up). This is accomplished, as we keep on exploiting the input field
of the vulnerable Web-App and modifying the <img> tag (shown in the code box below). Therefore,
in the “onerror” attribute is implemented the JavaScript function “alert()”, e.g. “alert('P0Wnd')”.
Please, note that the “src” attribute is not given in W3L-comform style in order to impel the
Browser engine to produce an error and consequentially to execute the “onerror” attribute.

<img src=P0Wnd onerror="alert('P0Wnd')"/>

The result after stage 2 is represented in Figure 48.
In the third stage, the goal is to exploit the <iframe> tag (see next code box) and execute the
“alert()” function. Please, note that, it is not even necessary to close the <iframe> tag in order to
trigger the malicious code (Figure 49).

<iframe src=javascript:alert("P0Wnd")>

Stage 4 denotes, how an unsanitized input field can be concealed as a fake one via JavaScript, and
used by an attacker to steal passwords. By inserting the code, given in the following code box, the
DOM is changed and a common Web end user could easily walk straight into the trap (Figure 50).

24

3 DOMXSS Attacks

Please enter your password:<BR><input type = "password" name="pass"/><button
onClick="javascript:alert('I have your password: ' +
pass.value);">Submit</button><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
<BR><BR><BR><BR><BR>

As the user enters His password, the “alert()” function causes the opening of a pop-up window,
showing the concrete value of the “pass” variable, in this example it is "P0Wnd" (Figure 7). Please,
note that in this case, a cracker can modify the “onClick” attribute so, that the password can be sent
to a malicious server. Moreover, He can also induce other improper behavior of user's Browser.

Figure 7: DOM-based cross-site scripting after stage 4

In the fifth stage, the sanitization of the input field, used in the previous four phases of this scenario,
has to be initiated. For this purpose, the code of the JavaScript-file (see the code box below), which
is responsible for the sanitization, has to be changed. As next, let's represent the unsanitized code.

function displayGreeting(name) {
if (name != ''){
document.getElementById("greeting").innerHTML="Hello, " + name+ "!";
}
}

After short observation of the source code, we notice that the variable “name” is not properly
sanitized and can be used for the malicious execution of JavaScript. To prevent this, we should use

25

3 DOMXSS Attacks

the “escapeHTML()” function48, as shown in the next code fragment.
function displayGreeting(name) {
if (name != ''){
document.getElementById("greeting").innerHTML="Hello, " + escapeHTML(name) + "!";
}
}

After completing stage 5, we try to execute one of the attacks, that we applied in the previous
phases, but as shown in Figure 51, it doesn't work anymore.

Let's denote the S3 Meta-Model for this particular case study:

S3 Meta-Model: WebGoat case study
Prerequirements: none

Source: HTML DOM Text Object – textObject.name, in this case study – person.value

Sink: document.getElementById("greeting").innerHTML
Core:
Storage: none

Payload: Please enter your password:<BR><input type = "password"
name="pass"/><button onClick="javascript:alert('I have your password: ' +
pass.value);">Submit</button><BR><BR><BR><BR><BR><BR><BR><BR
><BR><BR><BR><BR><BR><BR><BR><BR>

Impact: educational attack example

What is valuable in this case study?
First of all, the transition from the classic NP-XSS to DOMXSS is demonstrated and a security
concerned user should be able to notice the difference – by injecting the malicious code, the DOM
Construction dynamically changes and triggers the execution of the attack via the DOM rendering
engine in the Browser. Secondly, an example of DOM-based XSS attack technique is presented with
visual feedback on the testing environment. At last, a sanitization technique is proposed, which
designates the WebGoat tool as an educational, respecting the Web Application Security.
As next, we will pay attention to the second scenario – real time attack scenario-AOL.

3.2.5.2 Case study: Real time scenario – AOL

What is crucial in this example?
The Aol. B2C portal still utilizes an outdated AJAX framework to auto complete the user's search

48 Please note, that the “escapeHTML()“ function is not predefined JavaScript function, but a method in JavaScript
Framework prototype.

26

DOM-based XSS Attacks Taxonomy and Case Studies

DOM-based XSS Attacks Taxonomy and Case Studies

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DOM-based XSS Attacks Taxonomy and Case Studies

Similar to DOM-based XSS Attacks Taxonomy and Case Studies (20)

Recently uploaded

Recently uploaded (20)

DOM-based XSS Attacks Taxonomy and Case Studies