Hello there,

I am Pratik Dabhi, a Bug Bounty Hunter and a Penetration Tester. Many of you may already know me, but for those who aren’t, please visit my website to learn more about me.

In this blog, I will share an interesting bug I discovered last year on a multinational corporation’s website. The bug revolves around how I bypassed SSRF protections by chaining it with an open redirect vulnerability on a third-party domain. As in my recent blog posts, I’ve been detailing the bugs found during the reconnaissance phase. Similarly, in this case, I uncovered this bug during my reconnaissance phase.

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can trick a server into sending HTTP requests to internal or external systems that the attacker should not normally be able to reach.

This can lead to:

• Accessing internal-only services (e.g. databases, admin panels)
• Scanning internal networks and discovering open ports
• Retrieving sensitive data from cloud metadata services
• Bypassing IP restrictions or firewalls

Companies often try to prevent SSRF by blocking requests to certain hostnames like localhost or private IP ranges. But as you’ll see, creative chaining of bugs can sometimes bypass these defenses.

The target had a service running at:

https://thumbnail.example.com/?url=<external_url>

This service fetched images from external URLs to generate thumbnails displayed on their platform.

They had protection mechanisms in place that blocked direct requests to internal resources. For example, if I tried:

https://thumbnail.example.com/?url=http://localhost:443

…the server responded with an error message like:

Error: localhost is prohibited.So far, everything seemed secure.

While performing reconnaissance, I came across a third-party domain blip.bizrate.com that had an interesting endpoint:

https://blip.example.com/flip?u=https://evil.com

When I opened this URL in my browser, it redirected directly to https://evil.com without any validation or restrictions.

So, it was confirmed that the blip.example.com endpoint was vulnerable to an open redirect via the u parameter.

Here’s where the fun began. I thought:

If I can’t request localhost directly, what if I redirect through a trusted domain?

So, instead of directly hitting localhost, I crafted this payload:

https://thumbnail.example.com/?url=https://blip.example.com/flip?u=http://localhost:80

Here’s what happened behind the scenes:

1. thumbnail.example.com fetched the initial URL:
https://blip.example.com/flip?u=http://localhost:80

2. The server at blip.bizrate.com issued an HTTP 302 redirect to:
http://localhost:80.

3. thumbnail.example.com followed the redirect and attempted to connect to http://localhost:80.

And that’s how the SSRF was triggered despite protections.

When I tested my crafted URL, the server responded with:

dial tcp 127.0.0.1:80: connect: connection refused

This clearly showed that the server attempted to connect to localhost. The connection was refused because nothing was listening on that port during my test.

To scan other ports, I simply changed the port number in my payload:

https://thumbnail.example.com/?url=https://blip.example.com/flip?u=http://localhost:443

If a service was running on that port, I’d receive either a different error message or possibly even a thumbnail response with sensitive data.

Through this method, I could perform internal port scanning and potentially interact with services not exposed publicly.

The vulnerability existed because:

• The developers correctly blocked direct requests to internal hosts.
• However, they trusted external domains and followed redirects blindly.

The open redirect allowed me to start with a trusted external domain and end up at an internal resource — bypassing the protection logic entirely.

Severity: Medium

With this SSRF vulnerability, an attacker could:

• Scan internal services and discover open ports.
• Access internal endpoints like admin panels or databases.
• Attempt to exploit other vulnerabilities on internal services.
• Potentially access cloud metadata services (e.g. AWS, GCP, Azure) which could leak sensitive credentials.

Here’s how such issues can be fixed:

✅ Strict Allowlisting
Limit the thumbnail service to only fetch images from trusted domains (e.g. *.example.com).

✅ Validate Final Destination
Check the final resolved IP of the URL after following redirects. Block requests to internal IP ranges or localhost.

✅ Avoid Open Redirects
Third-party services like blip.example.com should fix open redirects by validating allowed destinations or implementing strict allowlists.

With this vulnerability, I was able to earn good money, I will show you some of my reports.

Thanks, everyone for reading:)

Happy Hacking ;)

Support me if you like my work! Buy me a coffee and Follow me on Twitter

Website:- https://www.pratikdabhi.com/

Instagram:- https://www.instagram.com/i.m.pratikdabhi

Twitter:- https://twitter.com/impratikdabhi

Youtube:-https://www.youtube.com/impratikdabhi