100% found this document useful (1 vote)
90 views

Unraveling Some of The Mysteries Around DOM-based XSS

The document discusses DOM-based cross-site scripting (XSS) vulnerabilities. It explains that DOM-based XSS occurs when malicious JavaScript code is executed through manipulation of the Document Object Model on the client-side, rather than requiring submission to the server. The document outlines different categories of DOM-based XSS, including stored and reflected variants. It notes that DOM-based XSS can be difficult to detect and prevent compared to traditional XSS due to the dynamic and self-modifying nature of the DOM. The document also examines dangerous sources of input, propagation methods, and sinks that can enable DOM-based XSS vulnerabilities.

Uploaded by

Bala JE/BSNL
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
90 views

Unraveling Some of The Mysteries Around DOM-based XSS

The document discusses DOM-based cross-site scripting (XSS) vulnerabilities. It explains that DOM-based XSS occurs when malicious JavaScript code is executed through manipulation of the Document Object Model on the client-side, rather than requiring submission to the server. The document outlines different categories of DOM-based XSS, including stored and reflected variants. It notes that DOM-based XSS can be difficult to detect and prevent compared to traditional XSS due to the dynamic and self-modifying nature of the DOM. The document also examines dangerous sources of input, propagation methods, and sinks that can enable DOM-based XSS vulnerabilities.

Uploaded by

Bala JE/BSNL
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 36

Unraveling some of the Mysteries around

DOM-based XSS

Dave Wichers
Aspect Security, COO This presentation released under the
Creative Commons 3.0 Attribution-
OWASP Boardmember NonCommercial-ShareAlike
OWASP Top 10 Project Lead CC BY-NC-SA
OWASP ASVS Coauthor

[email protected]
Cross-Site Scripting (XSS)

Types of Cross-Site Scripting Vulnerabilities


(per OWASP and WASC)
Type 2: Stored XSS (aka Persistent)
Type 1: Reflected XSS (aka non-Persistent)
Type 0: DOM-Based XSS
Sources: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
http://projects.webappsec.org/w/page/13246920/Cross Site Scripting

“There’s also a third kind of XSS attacks - the ones that do not rely on sending the malicious
data to the server in the first place!” Amit Klein – Discoverer of DOM-Based XSS

“DOM-based vulnerabilities occur in the content processing stage performed on the client,
typically in client-side JavaScript.” – http://en.wikipedia.org/wiki.Cross-site_scripting

2
XSS Categories

Really its more like this

(Traditional) DOM-Based
Stored XSS Stored XSS

(Traditional) DOM-Based
Reflected XSS Reflected XSS

3
XSS Categories – More Details

Or maybe like this

DOM-Based ‘Pure’ DOM-


(Traditional) Stored XSS Based Stored
Stored XSS (data from XSS (data from
HTML5 Local
server) storage)
DOM-Based ‘Pure’ DOM-
(Traditional) Reflected XSS Based Reflected
Reflected XSS (data from XSS (data from
DOM)
server)
4
DOM-Based XSS - Viewed Another Way

4: DOM-Based Stored XSS


Sent Message: Bob (via AJAX Message Retrieval)
Message Body: What’s for dinner?
<script>alert(1)</script>
1: ‘Pure’ DOM-
Based Reflected XSS
User Input
3: DOM-Based Reflected XSS
Bob (via AJAX Request/Response
JavaScript What’s for dinner?
Form <script>alert(1)</script>
Store Message on Server

2: ‘Pure’ DOM-Based
Stored XSS

HTML 5
Local
Storage

5
Logic is Migrating from Server to Client…

Server-side vs. Client-side LoC in popular web


applications in 2005 and in 2010

Source:

6
And How Vulnerable are Apps Today?
Using IBM’s JavaScript
Security Analyzer (JSA),
IBM tested Fortune 500 +
Top 178 Sites and found

40%
Vulnerable to Client-side
JavaScript vulnerabilities,

90%
of which was caused by 3rd Source:
party JavaScript Libraries
7
What’s the Risk of DOM-Based XSS?

XSS Risk from OWASP Top 10

Stored XSS attack more likely to succeed than


reflected but impact is the same
Risks are the SAME for Traditional and DOM-Based XSS
Detectability is lower for DOM-Based XSS as its
harder for attackers (and defenders) to find
8
DOM-Based XSS – The Classic Example

For: http://www.vulnerable.site/welcome.html?name=Joe<script>alert(1)</script>
#name=notJoe<script>alert(1)</script>?name=Joe

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;

document.write(document.URL.substring(pos,document.URL
.length));
</SCRIPT>
Welcome to our system …
</HTML>

src: http://projects.webappsec.org/w/page/13246920/Cross Site Scripting

9
Why is finding DOM-Based XSS So Hard?

Document Object Model


“…convention for representing and interacting with objects in HTML, XHTML and
XML documents.[1] Objects in the DOM tree may be addressed and manipulated
by using methods on the objects.” (http://en.wikipedia.org/wiki/Document_Object_Model)

Existing JavaScript can update the DOM and new data can also contain JavaScript

Its like trying to find code flaws in the middle of


a dynamically compiled, running, self modifying,
continuously updating engine while all the gears
are spinning and changing.

Self modifying code has basically been banned


in programming for years, and yet that’s exactly
what we have in the DOM.

“Manual code review is hell – have you seen JavaScript lately?” Ory Segal

10
How do we make detecting/avoiding DOM-
Based XSS more of a Science?

Better Understanding of

•Dangerous Sources
•Propagators (not covered here)
•Unsafe Sinks
•Defense Techniques

11
Dangerous Sources (of Browser Input)

3rd Party Content in


#5 JavaScript Same Origin
CSS
3rd Party Server
#4 Directly from the user.
e.g., onenter(), onclick(), submit button …
Request/Window Attributes
#3 document.*
window.*

#1 New page is created/updated in DOM. Standard HTTP Response


Scripts can access any of this data.
XHR Response
#2 function handleReloadContents() {
if (httpObj.readyState == 4 || httpObj.readyState=="complete")
{
var result = document.getElementById("mainBody"); Server
result.innerHTML = httpObj.responseText;
}
}
12
Dangerous Request/Window Attributes
Page: https://code.google.com/p/domxsswiki/wiki/Sources
For: Browsers: IE 8, Firefox 3.6.15 – 4, Chrome 6.0.472.53 beta, Opera 10.61
(Safari data TBD)
Describes return values for document.URL / documentURI / location.*
(https://code.google.com/p/domxsswiki/wiki/LocationSources)
scheme://user:pass@host/path/to/page.ext/Pathinfo;semicolon?search.loc
ation=value#hash=value&hash2=value2
Example: http://host/path/to/page.ext/test<a"'%0A`=
+%20>;test<a"'%0A`= +%20>?test<a"'%0A`= +%20>;#test<a"'%0A`= +%20>;
document.url output:
http://host/path/to/page.ext/test%3Ca%22'%0A%60=%20+%20%3E;test%3Ca%22'%0
A%60=%20+%20%3E?test<a"'%0A`=%20+%20>;#test<a"'%0A`=%20+%20>;
Similar info for other direct browser data sources including
document.cookie (https://code.google.com/p/domxsswiki/wiki/TheCookiesSources)
document.referer (https://code.google.com/p/domxsswiki/wiki/TheReferrerSource)
window.name (https://code.google.com/p/domxsswiki/wiki/TheWindowNameSource)
13
Some Dangerous JavaScript Sinks

• eval()
Direct execution • window.execScript()/function()/setInterval() /setTimeout()
• script.src(), iframe.src()

• document.write(), document.writeln()
Build • elem.innerHTML = danger, elem.outerHTML = danger
HTML/Javascript • elem.setAttribute(“dangerous attribute”, danger) –
attributes like: href, src, onclick, onload, onblur, etc.

Within execution • onclick()


• onload()
context • onblur(), etc.

Gleaned from: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet


14
Some Safe JavaScript Sinks

Setting a • elem.innerText(danger)
value • formfield.val(danger)

Safe JSON • JSON.parse() (rather


parsing than eval())

15
Popular JavaScript Library #1: jQuery

jQuery Methods That Directly Update the DOM


.after() .prependTo()
.append() .replaceAll()
.appendTo() .replaceWith()
.before() .unwrap()
.html() .wrap()
.insertAfter() .wrapAll()
.insertBefore() .wrapInner()
.prepend() Note: .text() updates DOM,
but is safe.
These are all the DOM Insertion and Replacement methods in jQuery.

Don’t send unvalidated data to these methods, or properly escape the data before doing so.
16
jQuery – But there’s more…

More danger
jQuery(danger) or $(danger)
This immediately evaluates the input!!
E.g., $("<img src=x onerror=alert(1)>")
jQuery.globalEval()
All event handlers: .bind(events), .bind(type, [,data], handler()),
.on(), .add(html),
Same safe examples
.text(danger), .val(danger)
Some serious research needs to be done to identify all the
safe vs. unsafe methods
There are about 300 methods in jQuery

We’ve started a list at: http://code.google.com/p/domxsswiki/wiki/jQuery

17
What about other Popular JavaScript
Libraries?

18
XSS Prevention Techniques
Traditional vs. DOM-Based

Traditional XSS DOM-based XSS


Avoid including unsafe input Same
in response
Server Side Context Client Side Context Sensitive
Sensitive Output Escaping Output Escaping
Server Side Input Validation Same, plus:
of the Request (HARD) Client Side Input Validation
of the Response
No equivalent Avoid JavaScript Interpreter
(page is always interpreted) (i.e., avoid unsafe sinks)

19
Primary XSS Defense: Context Sensitive
Escaping
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()

HTML Element Content


(e.g., <div> some text to display </div> ) #2: All non-alphanumeric < 256  &#xHH
ESAPI: encodeForHTMLAttribute()

HTML Attribute Values


(e.g., <input name='person' type='TEXT'
value='defaultValue'> ) #3: All non-alphanumeric < 256  \xHH
ESAPI: encodeForJavaScript()

JavaScript Data
(e.g., <script> some javascript </script> )
#4: All non-alphanumeric < 256  \HH

HTML Style Property Values ESAPI: encodeForCSS()


(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )

#5: All non-alphanumeric < 256  %HH


URI Attribute Values ESAPI: encodeForURL()
(e.g., <a href="javascript:toggle('lesson')" )

See: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for more details


Client Side Context Sensitive Output
Escaping
Context Escaping Scheme Example
HTML Element ( &, <, >, " )  &entity; $ESAPI.encoder().
( ', / )  &#xHH; encodeForHTML()
HTML Attribute All non-alphanumeric $ESAPI.encoder().
< 256  &#xHH encodeForHTMLAttribute()
JavaScript All non-alphanumeric $ESAPI.encoder().
< 256  \xHH encodeForJavaScript()
HTML Style All non-alphanumeric $ESAPI.encoder().
< 256  \HH encodeForCSS()
URI Attribute All non-alphanumeric $ESAPI.encoder().
< 256  %HH encodeForURL()
ESAPI for JavaScript Library Home Page: https://www.owasp.org/index.php/ESAPI_JavaScript_Readme
Identical encoding methods also built into a jquery-encoder: https://github.com/chrisisbeef/jquery-
encoder

Note: Nested contexts like HTML within JavaScript, and decoding before encoding to prevent double
encoding are other issues not specifically addressed here.
21
Client Side Input Validation

Input Validation is HARD


We recommend output escaping instead
But if you must, it usually looks something like this:
<script>
function check5DigitZip(value) {
var re5digit=/^\d{5}$/ //regex for 5 digit number
if (value.search(re5digit)==-1) //if match failed
return false;
else return true;
}
</script>

Example inspired by:


http://www.javascriptkit.com/javatutors/re.shtml

22
Avoid JavaScript Interpreter

This is what I recommend

Trick is knowing which calls are safe or not


We covered examples of safe/unsafe sinks already

23
DOM-Based XSS While Creating Form
Attack URL Value: http://a.com/foo?"
Vulnerable Code: onblur="alert(123)
var html = ['<form class="config">',
'<fieldset>',
'<label for="appSuite">Enter URL:</label>',
'<input type="text" name="appSuite" id="appSuite"
value="', options.appSuiteUrl || '', '" />',
'</fieldset>',
'</form>'].join(''), dlg = $(html).appendTo($('body'));
...

DOM Result: <input type="text" name="appSuite" id="appSuite"


value="http://a.com/foo?" onblur="alert(123)">

Fix #1:
regexp = /http(s):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-
\/]))?/;
buttons: { 'Set': function () {
var u = $.trim(appSuite.val());
if (!regexp.test(u) || u.indexOf('"') >= 0) {
Util.ErrorDlg.show('Please enter a valid URL.');
return;
} ...

24
Fix #2 – Safe construction of the form

Vulnerable Code:
var html = ['<form class="config">',
'<fieldset>',
'<label for="appSuite">Enter URL:</label>',
'<input type="text" name="appSuite" id="appSuite"
value="', options.appSuiteUrl || '', '" />',
'</fieldset>',
'</form>'].join(''), dlg = $(html).appendTo($('body'));
...

Fix #2:
var html = ['<form class="config">',
'<fieldset>',
'<label for="appSuite"> Enter URL:</label>',
'<input type="text" name="appSuite" id="appSuite" />',
'</fieldset>',
'</form>'].join(''), dlg = $(html).appendTo($('body'));
appSuite.val(options.appSuiteUrl || '');
...

25
Techniques for Finding DOM-Based XSS #1

Test like normal XSS in obvious inputs

• Step 1: Enter test script: dave<script>alert(1)</script>


• Step 2: Inspect response and DOM for ‘dave’
• Step 3: if found, determine if encoding is done (or not
needed)
• Step 4: adjust test to actually work if necessary
• E.g., dave" /><script>alert(1)</script>
• dave" onblur="(alert(2))

Tools: Normal manual Pen Test Tools like WebScarab/ZAP/Burp can be used here
Automated scanners can help, but many have no DOM-Based XSS specific test features
More tips at: https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OWASP-DV-003)
26
Techniques for Finding DOM-Based XSS #2

Inspect JavaScript loaded into DOM

• Step 1: look for references to user controlled input


• Remember 5 browser sources referenced previously?
• Step 2: follow data flow to dangerous sinks
• Lots of dangerous sinks mentioned before
• Step 3: if data is properly validated or encoded before
reaching dangerous sink (its safe)
• Validation/encoding could occur server or client side
• NOTE: THIS IS REALLY HARD!!
Browser Plugins REALLY USEFUL: Firebug, Chrome Developer Tools
Free Tools: DOMinator, DOM Snitch, Ra.2 try to automate this type of analysis
IBM’s AppScan does this too
27
Unexploitable XSS ?? Not Always …

XSS Flaws Aren’t Always Easily Exploited

• Scenario 1: Reflected XSS protected with CSRF Token.


• Attacker workaround: Clickjacking vulnerable page
• Scenario 2: DOM-Based XSS starting with user input to form
• Can’t force user to fill out form right? Yes – Clickjacking
• Or, if DOM-Based, but data passes through server:
• Force the request to the server, instead of filling out the
form. Works for per user Stored XSS, but not Reflected
XSS, since XHR won’t be waiting for response.

28
Its not just DOM-Based XSS

Unchecked Redirect
• window.location.href = danger, window.location.replace()

HTML 5 Shenanigans
• Client-side SQL Injection
• ‘Pure’ DOM-Based Stored XSS (Discussed before)
• Local storage data left and data persistence (super cookies)
• Notification API Phishing, Web Storage API Poisoning, Web Worker
Script URL Manipulation, (all coined by IBM)
• Web Sockets ???

Lots more … 

29
Free - Open Source Detection Tools

DOMinator – by Stefano DiPaola

• Firefox Plugin (to OLD version of FF)


• Works by adding taint propagation to strings
within the browser
• Difficult to install, run, and understand output, but very
promising approach
• Update coming out soon (April, 2012)
• Updated to Firefox 8.0.1
• Adds support for some HTML5 features like cross domain
requests, new tags, etc.
• http://code.google.com/p/dominator/

30
Free - Open Source Detection Tools cont’d

DOM Snitch
Experimental tool
from Google (Dec,
2011)
Real-time: Flags DOM
modifications as they
happen.
Easy: Automatically
flags issues with
details.
Really Easy to Install
Really Easy to Use
http://code.google.com/p/domsnitch/

31
Free - Open Source Detection Tools cont’d

• Nishant Das Patnaik/Security Engineer & Sarathi Sabyasachi


Sahoo/Software Engineer, Yahoo, India
• FireFox added on, first discussed Feb, 2012
• Downloads added to Google project 6 hours ago 
• Large database of DOM-Based XSS injection vectors.
• Fuzzes sources with these attacks and flags sinks where the
attacks actually execute.
• Intended to be mostly point and click
• http://code.google.com/p/ra2-dom-xss-scanner/

32
Free - Open Source Detection Tools cont’d

DOM XSS Scanner – from


Ramiro Gómez
Online service
Just type in your URL and
hit go
Simplistic string matching
source and sink detector
Purely a human aide

33
Commercial Tools

IBM’s JavaScript Security


Analyzer (JSA)
Built into AppScan
Crawls target site JavaScript Vulnerability Types
DOM-based XSS
Copies ALL JavaScript Phishing through Open Redirect
Then does source code HTML5 Notification API Phishing

analysis on it HTML5 Web Storage API Poisoning


HTML5 Client-side SQL Injection
Analysis HTML5 Client-side Stored XSS
Hybrid HTML5 Web Worker Script URL Manipulation
Email Attribute Spoofing

34
Commercial Tools cont’d

Web Vulnerability
Scanner (WVS)
has Client Script Analyzer (CSA) for
detecting DOM-Based XSS
http://www.acunetix.com/blog/web-security-
zone/articles/dom-xss/
DOMinater Commercial Edition
(future)
Any other commercial tools??
35
Conclusion

DOM-Based XSS is becoming WAY more


prevalent
Its generally being ignored
We need to KNOW what JavaScript APIs are
safe vs. unsafe
We need more systematic techniques for
finding DOM-Based XSS flaws
We need better guidance on how to avoid / fix
such flaws

36

You might also like