Prevent reflected XSS attacks

This section explains reflected Cross-site Scripting (XSS), typical examples of such attacks, and best practices to prevent the underlying vulnerabilities.

About reflective XSS

Reflected (Non-Persistent) XSS attacks occur when the malicious payload is included in the request sent to the vulnerable web application and is then reflected such that the server HTTP response consists of the payload. Attackers leverage social engineering techniques such as phishing attacks to make the victim include the malicious script in their request to the web server. The infected browser then executes the malicious script as the HTTP response.

Reflected XSS attacks are non-persistent; each victim must send the request with a malicious payload. As a result, attackers tend to trick as many users as possible to succeed in the attack. Such attacks are often aimed at message forum form submissions, error messages, or search engine results pages, as it is easier to craft a malicious e-mail message that many users can select. As one of the most common types of XSS attacks, reflected XSS does not require the attacker to locate and access a vulnerable web application that would allow them to inject malicious scripts permanently.

Impact to your business

As reflected, XSS vulnerabilities allow malicious users to misuse inline scripts and JavaScript. The severity of the attacks depends on the functionality and data affected. Infected JavaScript can access all the session tokens available to the affected web page, allowing attackers to impersonate legitimate users by stealing their sessions. Attackers can also exploit a reflected XSS vulnerability to access user files, geolocation, microphone, and other devices through HTML5 APIs. Application developers must address such vulnerabilities to protect user data and application functionality.

Attack examples

Below are some common approaches attackers leverage to carry out reflected XSS attacks.

1. Reflected XSS attack on a search query

Assume a web app accepts a search string from users through a search parameter within a query string:

http://darwin.com/aform.html?search=Hacker1

In the event the application server uses PHP to show the user-supplied value on the results page by pulling it from the URL and then generating the resulting HTML:

<?php echo 'You Searched:' .$_GET["search"];?>

The web server directly parses the user-supplied value in the URL to HTML with no input validation or output encoding. In such instances, attackers can craft arbitrary code that is executed in the browser when the victim selects a URL:

http://darwin.com/aform.html?search=<script>alert('XSS by Product1');</script>

This script gives hackers access to the cookie for the user session and allows them to assume a legitimate identity of the user.

2. Reflected XSS attack on an error message

Suppose a web page accepts an input parameter that contains the text displayed in an error message and displays it directly within its response. In that case, attackers use such vulnerabilities to orchestrate XSS attacks.

Assuming the URL that returns the error message as:

http://darwin.com/error/5/Error.ashx?message=Sorry%20+some+error+message

The returned error page directly copies the values of the URL message parameter and then displays it suitably within the page:

<p>Sorry, some error message</>

Without sanitization or appropriate validation, attackers can create a malicious payload to generate a pop-up screen:

http://darwin.com/error/5/Error.ashx?message=<script>alert("XSS by Hacker1")</script>

If an unsuspecting user requests this page, the browser executes the malicious script, redirecting the user to an HTML page with the following content in place of the actual content:

<p><script>alert("XSS by Hacker1");</script></p>

Prevent attacks

A reflected XSS attack is a commonly exploited form of XSS vulnerability. Organizations should leverage common prevention mechanisms to prevent the reflected cross-site scripting vulnerabilities in web applications.

Protection against reflected XSS primarily involves avoiding using dynamic malicious content from HTTP requests to embed scripts on a vulnerable application. Some approaches to achieve this include:

Validate user input

User input validation/content filtering forms the first line of defense against most XSS attacks, including reflected XSS. It is essential to treat a user input from any source as untrusted and formulate mechanisms to check against semantic and grammatical requirements. Security teams should also apply allowlists/blocklists for data patterns that should be accepted or rejected. Additionally, it is recommended thatQA and administration teams treat data from both authenticated and public users as untrusted inputs while applying the same input sanitization techniques across all users.

Escape dynamic content

Suppose the application relies on user-controllable data as part of its HTTP responses. In that case, the output data should be encoded so that the server does not interpret it as active content. This ensures that any special characters from the application datastore are treated as HTML tag content, not raw HTML. It is recommended to replace any significant dynamic characters with HTML entity encoding schemes to be interpreted safely. Developers should use dedicated tools to enable a safe stylesheet and script encoding if dynamic content is inserted into the <script> and <style> tags.

Implement a content security policy

A robust Content Security Policy lets web administrators/developers control where the web page can load and execute scripts. Since reflected XSS attack relies on the attacker embedding malicious content on a web page, CSPs prevent attacks by specifying the sources of inline scripts. Developers instruct browsers using a content-security-policy header or meta element, including directives for sources and sinks of specific resources and actions. Web developers can add sources of trusted scripts to an allowlist using a directive of the form:

Content-Security-Policy: script-src 'self' https://darwin.com

This directive allows for the trusted execution of scripts from the server hosting the current page and those originating from https://darwin.com.

Most modern browsers support CSPs, making them one of the most crucial aspects of preventing reflected XSS attacks.

Utilize a vulnerability scanning tool

Vulnerability scanning tools automatically test web applications and underlying source code to identify security gaps that can lead to the successful execution of XSS attacks. DAST Essentials includes an XSS tool that can scan JavaScript and web applications for vulnerabilities, such as XSS with no false positives.