Bypassing WAF to Exploit Reflected XSS: A Case Study
Introduction
Cross-Site Scripting (XSS) remains one of the most prevalent vulnerabilities in web applications. In this write-up, I’ll walk you through a lab from PortsSwigger that demonstrates how to exploit a reflected XSS vulnerability even when a Web Application Firewall (WAF) is in place. The challenge involves bypassing common XSS filters and triggering the print() function without requiring user interaction.
Understanding the Challenge
The lab presents a scenario where the search functionality of a web application is vulnerable to reflected XSS. However, the application is protected by a WAF that blocks common XSS payloads, making the task more challenging. The goal is to find a way around the WAF’s defenses and execute the print() function in the victim’s browser.
Initial Reconnaissance
My first step was to test the application’s response to basic XSS payloads. I quickly discovered that the WAF was blocking common tags and attributes, including <script> and event handlers like onload. This indicated that the WAF was using a blacklist approach to filter out known XSS vectors.
Exploring the WAF’s Limitations
To identify any potential weaknesses in the WAF’s configuration, I decided to test a variety of HTML tags and attributes. I used the ffuf tool alongside the XSS cheat sheet provided by PortsSwigger to automate this process. By systematically testing different tags and attributes, I aimed to discover any that the WAF might not be blocking.
Discovering a Bypass
Through trial and error, I discovered that the <body> tag was allowed by the WAF, which was a promising lead. However, many attributes and events were still blocked. To overcome this, I experimented with various event handlers until I identified a combination that worked.
Crafting the Payload
With the <body> tag and a working event handler in hand, I crafted the following payload:
<body onresize="print()">This payload triggers the print() function when the browser window is resized. To ensure the payload executes without user interaction, I embedded it in an <iframe> element and hosted it on the exploit server provided by the lab:
<iframe src="https://lab-url/?search=<body+onresize%3D%22print()%22>"
onload="this.style.width='10px'"></iframe>Executing the Attack
I then uploaded the payload to the exploit server and triggered the attack by accessing the crafted URL. The WAF did not block the payload, and the print() function executed successfully, solving the lab.
Conclusion
This lab demonstrates that even when a WAF is in place, it’s still possible to exploit XSS vulnerabilities by carefully crafting payloads that evade common filters. By understanding the limitations of blacklist-based filtering and using creative payloads, attackers can bypass WAF defenses and execute malicious code.
For those interested in honing their XSS skills, I highly recommend working through similar labs on PortsSwigger’s platform. They provide a hands-on experience that is invaluable for both offensive and defensive security professionals.
