$200 XSS Exploit: Bypass Cloudflare Using Waybackurls – A Complete Guide for Bug Hunters

By Satyam Pawale (@hackersatty)

About Me

Hi! I’m Satyam Pawale (@hackersatty), a passionate bug bounty hunter. In this article, I’ll take you through one of my real-world XSS vulnerability discoveries that earned me a $200 bounty. We’ll walk through:

• How I identified the vulnerable parameter

• How I used Waybackurls to bypass Cloudflare

• The exact payload and encoding used

• Impact analysis (session hijacking, data theft)

• How to responsibly report the bug

If you’re learning bug bounty hunting, this deep guide will equip you with practical steps and critical insights into exploiting and defending against XSS vulnerabilities.

What is Reflected XSS?

Reflected Cross-Site Scripting (XSS) is a security flaw that occurs when a web application immediately reflects user input without sanitizing or validating it. For example, if a user inputs JavaScript code in a URL parameter and the server reflects it back into the HTML response, that code executes in the victim’s browser.

Example Impact:

• Session Hijacking

• Account Takeover

• Phishing attacks

• Bypassing security protections like Cloudflare

A vulnerable endpoint might look like:

https://example.com/ajax/load.php?game_id=<script>alert(1)</script>

Discovery and Initial Testing

I started testing a web application that used Cloudflare as its WAF (Web Application Firewall). While many parameters were sanitized on modern endpoints, I wanted to check if older, unmaintained endpoints existed.

Step 1: Finding Old URLs Using Waybackurls

To search archived endpoints, I used the Waybackurls tool:

waybackurls example.com > urls.txt

This revealed endpoints like:

https://example.com/ajax/load.php?game_id=123
https://example.com/search.php?q=123

Many of these were no longer linked on the website, but some were still functional. This is a goldmine for XSS testing.

Identifying the Vulnerable Parameter

Among these, the game_id parameter on load.php reflected input directly into the page without encoding or sanitization.

I first tested this URL:

https://example.com/ajax/load.php?game_id=<svg onload=alert(1)>

Cloudflare blocked the request.

But the fact that it was reflecting content hinted at a deeper issue. So, I moved to encoding the payload.

Crafting and Encoding the XSS Payload

Initial Payload:

<svg onload=prompt(document.cookie)>

Encoded Version (To Bypass Cloudflare):

Dec%3a%20%3csvg%20onload%3dprompt%26%230000000040document%2ecookie)%3e

The trick is using special characters, HTML entity encoding (%3c, %3e, etc.), and payload obfuscation (e.g., &%230000000040 for @) to evade WAF pattern matching.

Final Exploit URL

I injected the encoded payload into the vulnerable parameter:

https://example.com/ajax/load.php?game_id=Dec%3a%20%3csvg%20onload%3dprompt%26%230000000040document%2ecookie)%3e&sort=id-desc

Upon visiting this URL in the browser, the page executed the JavaScript and showed a cookie prompt — confirming the XSS.

Real-World Impact: Why This Matters

This is more than just an alert box. With this kind of XSS vulnerability, an attacker could:

1. Steal Session Cookies: Gain access to authenticated sessions

2. Impersonate Admin Users

3. Craft Phishing Campaigns: Alter the DOM to trick users

4. Exfiltrate Data: Send sensitive info to a third-party domain

5. Bypass Cloudflare’s WAF: Encoding and archive hunting helped bypass filtering

This XSS existed despite the site using Cloudflare, showing that WAFs are not foolproof.

Step-by-Step Exploitation Recap

Step 1: Run Waybackurls

waybackurls example.com > urls.txt

Step 2: Identify Reflection Points

Test URLs with special characters:

https://example.com/ajax/load.php?game_id=<test>

Step 3: Craft Payload

Use <svg onload=prompt(document.cookie)> as base.

Step 4: Encode the Payload

Use HTML and URL encoding to bypass WAFs.

Step 5: Inject & Confirm Execution

Visit encoded URL. Confirm if cookies or other actions are triggered.

How to Report Responsibly

When you find a valid XSS vulnerability:

• Write a clear report with step-by-step instructions

• Include screenshots or video proof

• Highlight risk and business impact

• Provide remediation tips (see next section)

This professional approach led to my report being accepted and rewarded with $200.

Preventing Reflected XSS – Tips for Developers

Input Validation

Ensure all inputs are validated server-side, not just in JavaScript.

Output Encoding

Use proper encoding libraries to prevent raw HTML/JavaScript injection.

Implement CSP

A strict Content Security Policy limits allowed scripts.

Disable Old Endpoints

Endpoints like ajax/load.php may remain live unintentionally.

Use Frameworks with Built-in XSS Protection

React, Vue, Angular, etc. escape user data by default.

Key Lessons for Bug Bounty Hunters

• Use tools like Waybackurls to uncover legacy vulnerabilities.

• Obfuscate payloads with encoding to bypass WAF filters.

• Don’t rely on modern endpoints only — check archived, deprecated URLs.

• Combine your XSS findings with other bugs (e.g., session fixation or open redirect) for greater impact.

Final Thoughts

Reflected XSS vulnerabilities are often overlooked in modern apps, but they can still cause significant damage, especially when combined with weak defenses or forgotten endpoints. This case study proved that even with Cloudflare in place, encoded payloads and historical data can be used to craft successful exploits.

Always test ethically, report responsibly, and never stop learning. Want more content like this? Check out my bug bounty blog and follow for real-life hacking walkthroughs.

Other Internal Blog Link:

• Hackersatty

External DoFollow Links:

• OWASP XSS

• WAYBACKURLS

• XSS CSP

   

  Final Thoughts: Keep Hunting, Keep Learning

  This was one of my earliest critical bug bounty finds and taught me that APIs are one of the most vulnerable attack surfaces today. With tools like Swagger, Postman, and Burp Suite at your disposal, you don’t need to brute force—just observe and test logically.

  🔍 API is more than headers and tokens—it’s about understanding how developers structure access and how attackers think.

  If you found this write-up helpful, feel free to connect with me on LinkedIn or follow my work on Twitter.

  Until next time, stay curious and stay secure! 🔐

•