DOM Based Cross Site Scripting(XSS) vulnerability Tutorial
By Parth
So far i have explained about the Traditional Cross site scripting that occurs because of insecure server-side code. In this post , i am going to explain the DOM Based Cross Site Scripting vulnerability. if you don't know what is cross site scripting , then i recommend you to read the basics from here.
Before explaining about the DOM based xss, let me explain what DOM means to.
Like server-side scripts, client-side scripts can also accept and manipulate user input with the help of DOM.
Before explaining about the DOM based xss, let me explain what DOM means to.
What is DOM?
DOM is expanded as Document object model that allows client-side-scripts(Eg: Javascript) to dynamically access and modify the content, structure, and style of a webpage.Like server-side scripts, client-side scripts can also accept and manipulate user input with the help of DOM.
Here is a very simple HTML code that accepts and writes user input using JavaScript with the help of DOM.
<html>
<head>
</head>
<body>
<script>
var pos=document.URL.indexOf("BTSinput=")+9; //finds the position of value
var userInput=document.URL.substring(pos,document.URL.length); //copy the value into userInput variable
document.write(unescape(userInput)); //writes content to the webpage
</script>
</body>
</html>
If you know HTML and Javscript, understanding the above code is a piece of cake.
In the above example, the javascript code gets value from the url parameter "BTSinput" and writes the value in our webpage.
For example, if the url is
www.BreakThesecurity.com/PenTesting?BTSinput=defaultThe webpage will display "default" as output.
Did you notice ?! The part of the webpage is not written by Server-side script. The client side script modifies the content dynamically based on the input. Everything done with the help of DOM object 'document'.
DOM Based XSS vulnerability:
When a developer writes the content using DOM object without sanitizing the user input , it allow an attacker to run his own code.
In above example, we failed to sanitize the input and simply displayed the whatever value we get from the url.
An attacker with malicious intention can inject a xss vector instead . For example:
www.BreakThesecurity.com/PenTesting?BTSinput=<script>alert("BreakTheSec")</script>
As i said earlier, the document.write function simply writes the value of BTSinput parameter in the webpage. So it will write the '<script>alert("BreakTheSec")</script>' in the webpage without sanitizing. This results in running the script code and displays the alert box.
Patching the DOM Based Cross Site Scripting Vulnerability
Audit all JavaScript code in use by your application to make sure that untrusted data is being escaped before being written into the document, evaluated, or sent as part of an AJAX request. There are dozens of JavaScript functions and properties which must be protected, including some which are rather non-obvious:
The document.write() function
The document.writeln() function
The eval() function, which executes JavaScript code from a string
The execScript() function, which works similarly to eval()
The setInterval(), setTimeout(), and navigate() functions
The .innerHTML property of a DOM element
Certain CSS properties which allow URLs such as .style, .backgroundImage, .listStyleImage, etc.
The event handler properties like .onClick, which take JavaScript code as their values
Any data which is derived from data under the client's control (e.g. request parameters, headers, query parameters, cookie names and values, the URL of the request itself, etc.) should be escaped before being used. Examples of user-controlled data include document.location (and most of its properties, e.g. document.location.search), document.referrer, cookie names and values, and request header names and values.
You can use the JavaScript built-in functions encode() or encodeURI() to handle your escaping. If you write your own escaping functions, be extremely careful. Rather than using a "black list" approach (where you filter dangerous characters and pass everything else through untouched), it is better to use a "white list" approach. A good white list approach is to escape everything by default and allow only alphanumeric characters through.
Reference:
http://www.rapid7.com/vulndb/lookup/http-client-side-xss
Comments