Settings
Log out
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into a trusted websites.
XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.
Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
In this session we are going to discuss JavaScript bugs which lead to XSS. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie.
A DOM-based XSS vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker. Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results.
The consequences are the same as a typical XSS flaw, only the means of delivery is different. In comparison to other types of cross site scripting vulnerabilities (reflected and stored, where an un-sanitized parameter is passed by the server then returned to the user and executed in the context of the user's browser, a DOM-based XSS vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.
Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques impotent to such attacks.
This hypothetical example uses the following client side code: An attacker may append # to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser, but as a fragment. In this example, the code is immediately executed and an alert of “xss” is displayed by the page.
Unlike the more common types of cross site scripting (reflected and stored in which the code is sent to the server and then back to the browser, this is executed directly in the user's browser without server contact. The consequences of DOM-based XSS flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection, etc., and should therefore be treated with the same severity. How to Test JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server.
Additionally, JavaScript is often executed outside of However, it may not be detected in the following contrived case: For this reason, automated testing will not detect areas that may be susceptible to DOM-based XSS unless the testing tool can perform additional analysis of the client side code. Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker. Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed.