Context

Cross-Site Scripting (XSS) represents a Web security vulnerability that allows an attacker to compromise user interactions with a vulnerable application. XSS attacks usually allow the attacker to impersonate a victim user and perform all actions that the user is capable of, as well as access all of the user's data. In the case where the victim user has privileges in the application, the attacker could take full control of all application functionality and data. These attacks occur by manipulating a vulnerable website to return malicious JavaScript code to users. Once the malicious code executes in a victim's browser, the attacker can fully compromise their interaction with the application.

Exploiting a cross-site scripting vulnerability typically allows an attacker to:

• Impersonate the victim user or act on their behalf;
• Perform any action that the user is capable of;
• Read any data that the user can access;
• Capture the user's login credentials;
• Perform a virtual defacement of the website;
• Inject a Trojan horse functionality into the website.

XSS attacks are mainly of three types:

• Reflected XSS, where the malicious script comes from the current HTTP request;
• Stored XSS, where the malicious script comes from the web site's database;
• DOM-based XSS, where the vulnerability resides in the client-side code rather than the server-side code.

Reflected XSS

Reflected XSS is considered the simplest category of XSS attacks. This type of attack occurs when the web application receives data in an HTTP request and includes it in the immediate response without taking necessary security measures.

 https://website.com/status?message=All+is+well.
<p>Status: All is good.</p>

As the application does not process the received data, an attacker can easily create a Reflected XSS attack by exploiting this weakness.

 https://website.com/status?message=<script>/*+Bad+code+here...+*/</script>
<p>Status: <script>/* Bad code here... */</script></p>

Stored XSS

The attacker can exploit the Stored XSS, which occurs when an application includes data from an untrusted source in its HTTP responses. The data in question can be submitted to the application via HTTP requests such as comments on a blog post, user nicknames in a chat room, or customer information on an order form. The data can also come from other untrusted sources, such as a webmail application displaying messages received via SMTP, a marketing application displaying social media posts, or a network monitoring application displaying data packets from network traffic. For example, in a messaging application, users can submit messages that are displayed to other users, which can potentially be exploited by an attacker to execute malicious code.

 <p>Hello, this is a message!</p>

By exploiting a Stored XSS vulnerability in a messaging application, an attacker can easily send a malicious message that compromises the security of other users.

 <p><script>/* Bad code here... */</script></p>

DOM-based XSS

DOM-based XSS occurs when a web application contains client-side JavaScript code that manipulates data from an untrusted source, often by rewriting the data in the DOM. A common example is when an application uses JavaScript to extract the value of an input field and write that value to an HTML element.

 var search = document.getElementById('search').value;
var result = document.getElementById('result');
result.innerHTML = 'Result: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that triggers the execution of their own script:

 Result: <img src=1 onerror='/* Bad code here... */'>

In a typical scenario, the input field would be filled from a part of the HTTP request, such as a URL query string parameter, allowing the attacker to launch an attack using a malicious URL, in the same way as reflected XSS.

Impact

The actual impact of an XSS attack usually depends on the nature of the application, its features and data, as well as the status of the compromised user. For example:

• In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
• In an application containing sensitive data, such as banking transactions, emails, or medical records, the impact will generally be severe.
• If the compromised user has high privileges within the application, the impact will typically be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

Finding and Testing XSS Vulnerabilities

Manually testing for reflected and stored XSS normally involves submitting a single simple input (such as a short alphanumeric string) into each entry point of the application, identifying each location where the submitted input is returned in HTTP responses, and testing each location individually to determine if a properly crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select an appropriate payload to exploit it.

To find DOM-based vulnerabilities in non-URL-based inputs (such as document.cookie) or non-HTML-based receivers (such as setTimeout), nothing beats examining the JavaScript code, which can be extremely time-consuming.

How to Prevent XSS Attacks

Preventing cross-site scripting attacks is easy in some cases but can be much more difficult depending on the complexity of the application and how it handles user-controllable data. In general, effective prevention of XSS vulnerabilities likely involves a combination of the following measures:

• Filter input on arrival
• Encode data on output: Depending on the output context, this may require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response headers: To prevent XSS in HTTP responses that aren't intended to contain HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses as you intend.
• Content Security Policy: As a last line of defense, you can use Content Security Policy (CSP).