Abstract
Advanced XSS
Advanced cross site scripting
Agenda:
* What is cross site scripting.
* Types of cross site scripting.
* Where xss can be performed
* Scenario (example) of DOM based xss.
* DOM based xss attacks.
* Prevention of xss attacks.
* Testing tools.What is xss?
Xss attack exploit vulnerability in dynamically degerated web pages enables hackers to inject client side script into web pages viewed by other users. It occurs when invalidated input data is included in dynamic content i.e., sent to a user web browser for modification purpose. Hackers can inject malicious java script, vb script, activex, html or flash for execution on victims system with help of browser.Types of cross site scripting?
* non persistant xss or temporary xss or client side xss or browser side xss.
* persistant xss or permanant xss or server side xss.
* document object model (xss dom xss).Places where the xss can be performed?
* search box
* feedback form
* enquiry form
* comment form
* registration form
* url address
* chat box.persistant xss?
The Persistent XSS condition is met when a website or web application stores user input, serves it back to other users when retrieving it at a later stage without validation before storage or before embedding stored content into HTML response pages.
Hence, malicious code is inputted by attackers into vulnerable web pages and is then stored on the web server for later use. The payload may be served back to other users browsing web pages and is executed in their context, at a later stage. Thus, the victims do not need to click on a malicious link in order to run the payload (as in the case of Non-Persistent XSS); they simply have to visit the vulnerable web page, serving back un-sanitized user input from other web sessions.
Persistent XSS is also referred to as Type 2 XSS because the attack is carried out via two requests: one for injecting malicious code and having it stored on the web server, and the other for when victims load HTML pages containing the payload.Non persistant xss?
Non-Persistent cross-site scripting (XSS), also known as Reflected XSS, is one of the three major categories of XSS attacks, In general, XSS attacks are based on the victim’s browser trust in a legitimate, but vulnerable website or web application (the general XSS premises). The reflected XSS condition is met when a website or web application employs user input in HTML pages returned to the user’s browser, without validating the input first.
Non-Persistent XSS is the most commonly carried out XSS attack, as the vulnerabilities which make it possible are more common than those which enable other types of XSS. Non-Persistent XSS is also called Type 1 XSS because the attack is carried out through a single request / response cycle.DOCUMENT OBJECT MODEL XSS?
In order to understand DOM XSS, we need to describe a bit what DOM is, and why is it relevant to this context.
The Document Object Model is a convention for representing and working with objects in an HTML document (as well as in other document types). Basically all HTML documents have an associated DOM, consisting of objects representing the document properties from the point of view of the browser. Whenever a script is executed client-side, the browser provides the code with the DOM of the HTML page where the script runs, thus, offering access to various properties of the page and their values, populated by the browser from its perspective.
DOM XSS is a type of cross site scripting attack which relies on inappropriate handling, in the HTML page, of the data from its associated DOM. Among the objects in the DOM, there are several which the attacker can manipulate in order to generate the XSS condition, and the most popular, from this perspective, are the document.url, document.location and document.referrer objects.
Example of a DOM XSS Attack
Let’s take the basic example of a page which provides users with customized content, depending on their user name which is encoded in the URL, and uses their name on the resulting page:
In this case the HTML source of http://www.example.com/userdashboard.html would look like this:
Custom Dashboard
...
Main Dashboard for
var pos=document.URL.indexOf("context=")+8;
document.write(document.URL.substring(pos,document.URL.length));
...
The result of http://www.example.com/userdashboard.html?context=Mary would be a customized dashboard for Mary, containing the string “Main Dashboard for Mary” at the top.
The malicious script can be embedded in the URL as follows
http://www.example.com/userdashboard.html?context=SomeFunction(somevariable)
http://www.example.com/userdashboard.html#context=SomeFunction(somevariable)
Furthermore, the victim’s browser receives the above URL and sends a HTTP request to http://www.example.com, receiving the static HTML page described above. Then, the browser starts building the DOM of the page, and populates the document.url property, of the document object with the URL containing the malicious script.
When the browser arrives to the script which gets the user name from the URL, referencing the document.url property, it runs it and consequently updates the raw HTML body of the page, resulting in
...
Main Dashboard for SomeFunction(somevariable)
...
Next, the browser finds the malicious code in the HTML body and executes it, thus finalizing the DOM XSS attack. In reality, the attacker would hide the contents of the payload in the URL using encoding so that it is not obvious that the URL contains a script.
Note however, that some browsers may encode the < and > characters in the URL, causing the attack to fail. However there are other scenarios which do not require the use of these characters, nor embedding the code into the URL directly, so these browsers are not entirely immune to this type of attack either.
How is DOM XSS different?
Using the above example, we can observe that:
The HTML page is static, and there is no malicious script embedded into the page, as in the case of other types of XSS attacks;
The script code never gets to the server, if the “#” character is used; it is seen as fragment and the browser does not forward it further. Hence server-side attack detection tools will fail to detect this attack; in some cases, depending on the type of the URL, the payload might get to the server and it may be impossible to hide it.
Defending against DOM XSS attacks
Effective conceptual defense methods against the DOM XSS include, but are not limited to
Avoiding client-side sensitive actions such as rewriting or redirection, using client-side data;
Sanitization of the client-side code by inspecting and securely handling references to DOM objects that pose a threat, such as url, location and referrer, especially in cases when the DOM may be modified;
Using intrusion prevention systems which are able to inspect inbound URL parameters and prevent the inappropriate pages to be served.
Testing Tools:
1. The DOMinator Tool - A commercial tool based on the Firefox browser with modified Spidermonkey Javascript engine that helps testers identify and verify DOM based XSS flaws
2. The DOM XSS Wiki
3. DOM Snitch - An experimental Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. From Google.As of now i have prepared this content if any mistakes or adding or removing content kindly inform me.
Thanks & regards,
avinash varma.
Speaker
Timing
Starts at Saturday April 16 2016, 10:30 AM. The sessions runs for about 1 hour.