How i Found X-Forwarded Header Injection — Server Be Like, ‘Ab Toh Trust Issues Ho Rahe Hain!’ 😂

3 min read2 days ago

Introduction:

Namaste! I’m AIwolfie, a passionate bug bounty hunter who loves hunting vulnerabilities as much as Indians love chai and samosas. With a knack for finding bugs in the wild, I’ve uncovered several vulnerabilities in web applications. Today, I’ll share a fun yet insightful story about how I found a vulnerability involving X-Forwarded-* headers. Sit tight because this one will leave you laughing (and maybe questioning your server's security).

The Scene:

Imagine this: a server chilling like a Bollywood hero who blindly trusts its love interest (read: HTTP headers). The X-Forwarded-Host header comes along saying, "Mujhpe Bharosa Karo" (Trust me), and the server says, "Dil Se" (from the heart). Little did the server know, I was the one controlling the narrative. 🙃

This vulnerability was all about misplaced trust — and we all know what happens when you trust the wrong person, right? “Dhokha hi milta hai” (Betrayal is inevitable). 😜

What I Found:

While running my trusty Nuclei scanner, I stumbled upon something interesting — a redirect vulnerability caused by improper validation of the X-Forwarded-Host header. The server was happily redirecting users wherever I wanted, like an autorickshaw driver taking you on an unplanned city tour. 😎

Steps to Reproduce (or as we say, “Proof Hai Bhai!”):

Step 1: Analyze the Endpoint

The vulnerable endpoint looked innocent, like your college crush during viva exams. But as we know, appearances can be deceptive. Here’s how I approached it:

Open your favorite terminal or Burp Suite (your best friend for bug hunting).
Target the URL that trusts X-Forwarded-* headers.

Step 2: Send a Manipulated Header

Here comes the fun part. I added a little spice to my HTTP headers, and voila! The server was like, “Jo tu bolta hai, wahi sach hai” (Whatever you say is the truth).

Here’s what I sent:

curl -I -H "X-Forwarded-Host: evil.com" http://target-site.com

Step 3: Observe the Magic

The server replied with:

HTTP/1.1 302 Found
Location: http://evil.com

Aisa laga jaise server ne kaha, “Hukum mere aka” (Your wish is my command). I redirected the users wherever I wanted — be it a phishing page, a meme site, or my GitHub profile (for shameless self-promotion 😜).

Step 4: Exploit for SSRF

To take it up a notch, I tested whether the server would fetch internal resources like a good ol’ obedient intern. Here’s what I tried:

curl -H "X-Forwarded-For: 127.0.0.1" -H "X-Forwarded-Host: 127.0.0.1:9200" http://target-site.com

And surprise, surprise! The server fetched data from internal services faster than Swiggy delivering momos. 🥲

Impact:

This bug could let an attacker:

Redirect Users to phishing or malicious pages. (“Aapko lagta tha Swiggy khol rahe ho, par aap toh cybercrime ke shikar ban gaye!”)
Access Internal Resources using SSRF, potentially exposing sensitive data like cloud metadata or admin interfaces. 🫢
Steal Trust (and we all know how hard it is to rebuild that). 💔

How to Fix It (Server ko samjhaana padega):

Stop trusting X-Forwarded-* headers blindly. Validation zaroori hai, bhai! (Validation is a must, bro.)
Implement strict whitelisting for redirects. Sirf trusted URLs allowed hone chahiye (Only trusted URLs should be allowed).
Use a WAF to block these shady headers. “Hawa tight rakhni padegi, bhai” (You need to tighten the screws).

Final Words:

As Indians, we believe in “Atithi Devo Bhava” (Guests are God), but this server took it to another level by treating even attackers as VIP guests. Don’t be this server! Protect your application like Indian moms protect their secret recipes. ✨