Mitigating OWASP Web Application Risk: Cross-Site Scripting (XSS) using F5 BIG-IP

Cross-Site Scripting (XSS) is a widespread and dangerous security vulnerability that affects web applications. It allows attackers to inject malicious scripts into web pages viewed by other users, exploiting the trust a user has in a particular website. These scripts can execute in the context of the victim’s browser, enabling the attacker to manipulate the user’s interaction with the site. The malicious script is typically written in JavaScript, though other languages (like HTML or Flash) can also be used.

XSS can lead to a range of attacks, from stealing session cookies to performing actions on behalf of users without their knowledge. In this article, we will explore the types of XSS attacks, how they work, and how we can mitigate them using F5 Advanced WAF.

How XSS Works

An XSS attack generally follows these steps:

Injection: The attacker injects a malicious script into a website, typically through a vulnerable form, URL, or input field that doesn't properly sanitise user input.
Execution: The malicious script is executed in the victim’s browser when they visit the compromised page.
Exfiltration: The attacker can now execute various malicious activities, such as stealing cookies, logging keystrokes, altering the content of the page, or redirecting the user to a malicious website.
Impact: Depending on the type of attack, the consequences can range from a minor nuisance to severe financial and reputational damage for both the user and the website owner.

Types of Cross-Site Scripting Attacks

There are three primary types of XSS attacks: Stored XSS, Reflected XSS, and DOM-based XSS.

Reflected XSS (Non-Persistent XSS) :

Reflected XSS occurs when the malicious script is part of the HTTP request (e.g., in the URL, query string, or HTTP headers) and is immediately reflected in the server’s response. The script is executed as soon as the victim clicks on a crafted URL containing the payload.

Unlike stored XSS, the malicious payload is not stored permanently on the server and is instead executed immediately. The attacker often needs to trick the victim into clicking on a link with the malicious payload, making it more difficult to exploit at scale.

Example:

REFLECTED XSS

An attacker submits a comment containing a malicious script on a blog. When other users visit the blog, the script is executed in their browsers, stealing their session cookies.

Stored XSS (Persistent XSS) :

Stored XSS occurs when malicious input is permanently stored on the server (e.g., in a database, comment field, or user profile) and then delivered to users who request the compromised resource. This is the most dangerous form of XSS because it does not rely on an attacker tricking users into visiting a specific URL. Instead, any user accessing the affected page is vulnerable to the attack.

Example:

STORED XSS

An attacker sends a victim a URL with a malicious script embedded in the query string. When the victim clicks on the link, the script runs and performs malicious actions.

DOM-based XSS :

DOM-based XSS occurs when the client-side script manipulates the DOM (Document Object Model) so that it executes an attacker-controlled payload. Unlike reflected and stored XSS, the attack is entirely client-side and does not require any interaction with the server’s response.

In this case, the vulnerability lies in how JavaScript on the page processes the data coming from the URL or other sources and manipulates the DOM without proper validation or sanitization.

Example:

The page uses JavaScript to take user input from the URL and dynamically update the page content without sanitizing the input. An attacker can inject malicious code that executes in the user's browser.

Attack Demonstration and Mitigation:

For this demonstration, we will see how we can exploit the DOM-Based XSS vulnerability in ‘XVWA’ application. This application is added as a pool member in F5 BIG-IP LTM and can be accessed via a virtual server. For more information, refer to how to add pool member.

Navigate to Security > Application Security > Security Policies > and create an application policy with below configurations.

Enforcement mode: Blocking

Signature Staging: Enabled

Policy Building Learning Mode : Automatic

Virtual Server: < Virtual server on which the application is accessible >

Other configs are set to default values

Note: Staging is enabled by default while creating the application security policy and the default staging period is seven days. It can be tuned according to the customer’s requirements. For more information related to staging, refer to Attack Signatures & Staging

Now perform XSS attack on this application. Go to XSS – DOM Based page of this application

In this page, now search for something and observe the response of the page.

From the above screenshot it is evident that whatever input user gives the page appends it to the ‘search’ query and displays the same as “You have searched for <input>”.

Now input javascript <img src=1 onerror="alert('You are hacked')"> which should display an alert pop up saying you are hacked in the search query and observe what the page displays.

If Staging is enabled and the staging period (by default seven days) is not completed, Advanced WAF will be able to detect the malicious request but it won’t block the request. Only when the staging period gets completed, all the malicious requests that are detected will get blocked. For more information on staging and staging period, refer to Staging.

The attack is performed again post the configured staging period, and Advanced WAF was able to detect as well as block the attack.

Conclusion:

This article covered basics of XSS attacks, its types and as demonstrated above, these attacks can be effectively mitigated by implementing robust application policies and enforcing relevant attack signatures through Advanced WAF, ensuring enhanced security against such vulnerabilities.