Cross-Site Scripting (XSS)
Description
Cross-site Scripting (XSS) is the name of a class of security vulnerabilities that can occur in Web applications. It summarizes all vulnerabilities that allow an attacker to inject HTML Markup or JavaScript into the affected Web application's front-end client.
XSS can occur whenever the application dynamically creates its HTML, JavaScript, or CSS content, which is passed to the user's Web browser and an attacker-controlled value is used in this process. If the value is included into the generated HTML, JavaScript, or CSS source without proper validation and encoding, the attacker is able to include arbitrary HTML, JavaScript, or CSS source into the application's front-end client. This source is then rendered by the victim's Web browser and, thus, interpreted in the victim's current authentication context.
In the majority of all cases, XSS is caused by insecure programming.
Examples
Before this document explores the problem domain in depth, we give a short example to illustrate the general bug pattern.
The following example takes a search-engine that utilizes an HTML form to obtain the targeted search-term:
Example Code 1
<form
action="search.jsp" method="GET">Enter your query: |
After the user enters the query and submits the form, the user's Web browser creates an HTTP request to the Web application in which the actual search-term is included as the GET parameter q. The application receives this request, executes the search process, and composes the response's HTML content:
Example Code 2
[... Initialization ...] |
The server-side script search.jsp obtains the search term from the HTTP request and temporarily stores it in the variable searchterm. This variable is used within the assembly of the Web page that lists the search's outcome. Consequently, a search for the term Cross-Site Scripting would result in a Web page that contains the following HTML:
Example Code 3
[...] |
The GET parameter q is unaltered when echoed in the resulting HTML page. Therefore, if the user enters a search term that contains HTML markup, this markup is also included in the resulting Web page. For example, the following example shows the result for the search term <h1>hallo</h1>.
Example Code 4
[...] |
Therefore, by submitting a script-tag pair (<script>alert('xss!');</script>), JavaScript can be injected into the Web application, as shown below.
Example Code 5
[...] |
Why is This a Problem?
It has to be noted that XSS is a client-side attack. With XSS, the adversary is exploiting a user (from now on "the victim") of the vulnerable Web application.
For the victim's Web browser, the injected JavaScript and the application's regular JavaScript code are indistinguishable.
Therefore the attacker's script is executed by the Web browser in the context of the exploited application and has the same capabilities as legitimate JavaScript which is native part of the affected application.
The capabilities and restrictions of a JavaScript that is executed by the Web browser are governed by the same-origin policy. In summary, this means that the JavaScript has full read and write access to all elements that are currently displayed by the Web browser and which have the same origin as the JavaScript. The JavaScript which was injected into the application using XSS inherits the origin of the application in which it was injected into. Hence, within this application, the script has unrestricted rights.
More precisely, the malicious script can:
· Leak confidential information to the adversary, for example:
¡ Read all elements of the application's HTML interface.
¡ Read the values of all existing form fields including password fields.
¡ Communicate the obtained values to the attacker.
● Manipulate the application's front-end client, for example:
¡ Alter, move, and delete all elements of the application's HTML interface.
¡ Create new HTML elements and add them at arbitrary positions.
¡ Alter the destinations of any URL present in the application's HTML, including form actions or iframe sources.
● Hijack the application and commit state-changing actions under the identity of the victim, for example:
¡ Send arbitrary HTTP request's from the victim's Web browser to the application (for example, using the XMLHttpRequest object). These requests are interpreted under the victim's authentication context, because they carry the victim's authentication credentials (that is, the victim's cookies).
¡ Read and interpret the corresponding HTTP responses, for information leakage or for preparing further HTTP requests.
The last two capabilities allow the adversary complete remote control over the user's action's on the vulnerable Web application.
Classes of XSS Problems
Reflected
The term reflected XSS denotes all non-persistent XSS issues that occur when the Web application echoes parts of the HTTP request in the respective HTTP response's HTML. To successfully exploit a reflected XSS vulnerability, the adversary has to trick the victim into sending a fabricated HTTP request. This can be done, for example, by sending the victim a malicious link, or including a hidden iframe into an attacker-controlled page.
Stored
The term stored XSS refers to all XSS vulnerabilities, where the adversary is able to persistently inject the malicious script into the vulnerable application's storage (for example, into the database). This way the malicious script remains in the application even when the session that initially caused the exploitation has ended. Hence, every user that accesses the poisoned Web page receives the injected script without further actions taken by the adversary. Therefore, unlike reflected XSS, after successfully embedding the malicious script into the application, the actual exploitation does not rely on any means outside the vulnerable application.
Stored XSS vulnerabilities are the technological foundation for XSS worms – that is, self-replicating XSS attacks - which can cause significant damage to the affected application.
DOM-Based
With the term DOM-based XSS, all vulnerabilities are summarized where XSS problems are caused purely on the client-side, that is, by the JavaScript running in the Web browser. JavaScript has several options to directly and dynamically influence the DOM-tree of the displayed Web page. Some of these methods directly insert string-values into the page's source code (such as document.write(STRING) or element.innerHTML(STRING)). If the argument of such functions can be controlled by the attacker, he or she can trick the client-side functions to introduce script code into the page.
Furthermore, JavaScript provides functions to dynamically convert string values into executable script code. This can be done using functions such as eval(STRING) or window.setTimeout(STRING, time). If the STRING value can be controlled by the attacker in these functions, he or she is also able to execute arbitrary JavaScript code in the victim's authentication context.
To make issues worse, such attacks are not necessary noticeable on the server side. Certain values, such as fragment identifiers in URLs, are present in the victim's browser but not sent to the server. If these values are used insecurely on the client side, DOM-based XSS issues can occur which cannot be mitigated using server-side mitigation or encoding.