Unraveling some of the Mysteries around DOM-based XSS Dave Wichers Aspect Security, COO OWASP Boardmember OWASP Top 10 Project Lead OWASP ASVS Coauthor [email protected]This presentation released under the Creative Commons 3.0 Attribution- NonCommercial-ShareAlike CC BY-NC-SA
36
Embed
Unraveling some of the Mysteries around DOM-based XSS · 2020-01-17 · Unraveling some of the Mysteries around DOM-based XSS Dave Wichers Aspect Security, COO OWASP Boardmember OWASP
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Unraveling some of the Mysteries around DOM-based XSS Dave Wichers Aspect Security, COO OWASP Boardmember OWASP Top 10 Project Lead OWASP ASVS Coauthor [email protected]
This presentation released under the Creative Commons 3.0 Attribution-NonCommercial-ShareAlike CC BY-NC-SA
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
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
function handleReloadContents() { if (httpObj.readyState == 4 || httpObj.readyState=="complete") { var result = document.getElementById("mainBody"); result.innerHTML = httpObj.responseText; } }
New page is created/updated in DOM. Scripts can access any of this data.
Directly from the user. e.g., onenter(), onclick(), submit button …
HTML Element ( &, <, >, " ) &entity; ( ', / ) &#xHH;
$ESAPI.encoder(). encodeForHTML()
HTML Attribute All non-alphanumeric < 256 &#xHH
$ESAPI.encoder(). encodeForHTMLAttribute()
JavaScript All non-alphanumeric < 256 \xHH
$ESAPI.encoder(). encodeForJavaScript()
HTML Style All non-alphanumeric < 256 \HH
$ESAPI.encoder(). encodeForCSS()
URI Attribute All non-alphanumeric < 256 %HH
$ESAPI.encoder(). 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.
• 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))
26
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)
• 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!!
27
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
• 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.