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.

What is SSRF?

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.

Bug Summary

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.

Discovery of the Open Redirect

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.

Chaining the Open Redirect into SSRF

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.

Confirming the SSRF

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.

Why This Vulnerability Happened

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.

Impact

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.

Mitigation

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

impratikdabhi

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

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

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

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

From Open Redirect to Internal Access: My SSRF Exploit Story was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 today’s blog, I’m going to share an interesting bug I found last year that allowed me to take over user accounts by manipulating the password reset link. This vulnerability is called Password Reset Poisoning via Host Header Injection.

🌟 What is Password Reset Poisoning?

Whenever you forget your password, websites typically offer you a “Forgot Password” feature. When you use this feature, the website sends you a password reset link in your email. This link includes a unique token that allows you to reset your password.

However, the reset link itself is created by the server and typically includes the domain name (like https://example.com/reset?token=abc123). But if the application relies on user-supplied headers (like the Host header) to build this link, it can be manipulated.

This is known as Password Reset Poisoning. If an attacker can control the host in the reset link, they can hijack the reset link and take over other users’ accounts.

🕵️‍♂️ My Recon Process

Like every bug bounty hunter, I start with reconnaissance. Recon is the most important phase because it helps you understand how the target application works and where potential vulnerabilities may exist.

Here’s my approach:

✅ Subdomain Enumeration
I used tools like Subfinder and Assetfinder to find all the subdomains of the target domain:
👉 target.com
This helps to map out the full attack surface.

✅ Wayback Machine URLs
I ran waybackurls to discover historical URLs. Sometimes older endpoints can reveal interesting behavior or vulnerabilities.

✅ Probing with httpx
I used httpx to check if the discovered subdomains were alive and what technologies they used.

✅ Manual Browsing
Finally, I always manually browse the site. Manual exploration often leads to interesting insights!

🪝 How I Found the Vulnerability

During my recon, I came across the account subdomain:
👉 https://account.example.com

On this subdomain, I found a “Forgot Password” page:
👉 https://account.example.com/en/cant-login

This page allows users to enter their email address to receive a password reset link.

🔍 Testing the “Forgot Password” Feature

I wanted to see how the password reset link was created and if I could control any part of it.

Here’s what I did:

1️⃣ Opened Burp Suite to capture the request.
2️⃣ Entered a test email address on the “Forgot Password” page.

3️⃣ Clicked the submit button to trigger the password reset process.

Burp Suite captured the POST request:

POST /en/cant-login HTTP/1.1
Host: account.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46

email=test@example.com&action=forgot_password

💡 My Key Idea: Host Header Injection

I suspected the server might be using the Host header to build the password reset link.

Why?
Because if the application is not validating the Host header, I could change it to any domain I want. This means the password reset link sent to the user would include the domain I control instead of the real site!

⚙️ Reproducing the Issue

To confirm my suspicion, I decided to manipulate the Host header using Burp Suite.

Here’s how:

1️⃣ In Burp Suite, I sent the captured request to the Repeater.
2️⃣ In the Repeater tab, I modified the Host header to a different domain:

Host: bing.com

3️⃣ I sent the modified request.

🔥 The Response: It Worked!

Shortly after sending the request, I checked my email. The password reset email arrived. But here’s the surprise: the reset link pointed to https://bing.com instead of https://account.example.com!

Here’s what the reset link looked like:

👉 https://bing.com/reset?token=abcdef123456

This proved the application was using the Host header in the request to build the password reset link — and it was not validating it at all.

Impact

Attackers can fully take over a user’s account by capturing and using the poisoned password reset link. This allows them to change the victim’s password and lock them out of their own account.

After taking over an account, the attacker can access any sensitive or confidential information stored in that account, such as personal details, financial data, or internal company information.

If attackers exploit this vulnerability, it can lead to a loss of trust from users, as well as significant damage to the company’s reputation, which can affect future business and customer loyalty.

Mitigation

Applications should not rely on the Host header from the user request when creating password reset links. Instead, they should use a secure, server-side configuration like SERVER_NAME to ensure the correct and trusted domain is always used.

If the Host header is absolutely necessary for some functionality, it should be checked against a list of trusted and known domains to ensure it has not been tampered with.

Conduct regular security testing, including penetration testing and code reviews, to identify similar vulnerabilities early and fix them before they can be exploited.

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

impratikdabhi

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

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

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

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

How I Hacked Accounts Using Host Header Injection in Password Reset Link — $$$$ was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello there,

I am Pratik Dabhi, a Bug Bounty Hunter and Penetration Tester. Many of you might already know me, but if you’re new here, please visit my website to learn more about me and my work.

In this blog, I want to share an important vulnerability I discovered last year on a multinational corporation’s infrastructure — unauthenticated access to their Kibana dashboard. I found this bug during the reconnaissance phase of my testing, which highlights how critical thorough recon is in finding high-impact vulnerabilities.

Shodan & Reconnaissance: Finding Exposed Kibana Dashboards

Before diving into the vulnerability, let me share how I use reconnaissance tools to find such exposed services.

Kibana dashboards are often deployed internally but sometimes mistakenly exposed to the internet. To identify these, I rely heavily on Shodan, the search engine for internet-connected devices.

Using this Shodan query, I searched for publicly accessible Kibana instances:

product:"Elastic Kibana"

This query reveals numerous Kibana dashboards exposed without proper protection.

Additionally, I use Google dorks like:

intitle:"Kibana" inurl:"/app/kibana"

to identify publicly accessible Kibana pages indexed by Google.

If you are a security researcher or a defender, I highly recommend running these queries on your network to detect accidental exposure of Kibana dashboards and take action.

Vulnerability Finding: Unauthenticated Access to Kibana Dashboard

What is Kibana?

Kibana is a powerful open-source analytics and visualization platform designed to work with Elasticsearch. Organizations use it to monitor, analyze, and visualize data stored in Elasticsearch indices, which often include logs, metrics, and sensitive operational data.

The Bug

During my recon, I discovered a Kibana dashboard at the URL:

https://kibana.example.net/app/management/data/index_management/indices

What shocked me was that no authentication was required to access this dashboard. Simply visiting the URL gave me full admin access.

How I Verified It

• I tried accessing multiple Kibana endpoints and confirmed they all allowed unauthenticated access.
• I documented this with screenshots and videos showing full access to sensitive index management functions.
• This means anyone on the internet could act as an admin, view sensitive data, and modify or delete indices.

Impact

• Full administrative control without login.
• Exposure of sensitive data and system analytics.
• Potential for attackers to manipulate or disrupt services.
• Compliance violations due to data exposure.

Fix and Mitigation

To secure Kibana:

• Enable authentication mechanisms like Basic Auth, LDAP, or SAML.
• Configure multiple providers with unique names and prioritized order in kibana.yml.
• Example:

xpack.security.authc.providers:
  basic.basic1:
    order: 0
  saml.saml1:
    order: 1

• Restrict Kibana access through firewalls or VPN.
• Keep Elastic Stack components updated with security patches.

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

impratikdabhi

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

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

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

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

Unauthenticated Kibana Dashboard Access — A Serious Security Risk You Can’t Ignore was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 gained unauthorized access to the Grafana Dashboard. 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.

What is Grafana Dashboard?

Grafana dashboards provide centralized, visually appealing views of data from various sources, enabling monitoring and analysis of metrics such as CPU usage, network traffic, and application performance. They are customizable, connect to diverse data sources, and support collaboration, fostering improved observability, productivity, and communication.

Bug Summary

Grafana, a popular data visualization tool, possesses default credentials for the admin account, allowing anyone to access the dashboard without the necessity of creating their own account. This presents a significant security risk, as individuals with access to the default credentials could gain unauthorized access to sensitive data and potentially compromise the system. Utilizing the default username and password, I successfully accessed the dashboard with admin privileges.

I initiated the process with the basics, collecting all the subdomains of the target using various tools like Subfinder and more.

Then, I used waybackurls along with httpx to probe the URLs and retrieve the current status of the URLs.

I found a few IPS in the URLS which were found by waybackurls so the IP looks something like this “hi.dd.en.ip” using “-td or -tech-detect” switch in “httpx” I found this IP has Grafana in it. So I tried checking for a few bugs on Grafana using “Nuclei” in the background along with that I was manually checking for the bugs and whenever I found that the particular IP was using some technology I always tried to log in with default credentials that’s my first approach.

So, I googled the default credentials of Grafana, which is “admin/admin”.

I tried the same and it was the easy guess and I was able to log in.

Once I was inside the dashboard, I tried to change the password.

After changing the password, I found a few interesting information in it, which may help an attacker to further investigate the target application and exploit it accordingly.

Impact -This can lead to sensitive information about the server’s analytics and other information on resource utilization.
An attacker can also generate an API key to pull the resources out of this platform to an attacker’s control domain.

Mitigation -Default passwords in applications are like open doors for cybercriminals to enter and steal sensitive data. To mitigate the issue, one should change default passwords to strong and unique ones and enforce regular password rotation.

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

impratikdabhi

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

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

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

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

Unlocking Cash: Easy P1 Bug in Grafana Dashboard with Default Credentials = €€€€ was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

So, in this blog, I wanted to share an interesting bug that I have found on an MNC (Multi-National Company) website. The story starts when I was doing the recon on my target, I found a few interesting subdomains are gave me 403 Errors. I thought why don’t try to fuzz and try to bypass the protection? So, I used the 4-Zero-3 Tool to bypass the security and then I found a few more interesting endpoints that helped to bypass the protection. Let’s get started.

What is 403 Error?

A 403 Forbidden error is an HTTP status code that means that the client was able to communicate with the server, but the server won’t let the client access what was requested. This can happen for a number of reasons, such as:

· The client does not have permission to access the requested resource.

· The requested resource does not exist.

· The resource is protected by a password that the client does not know.

· The server is configured to deny access to all clients.

403 Bypass is the act of circumventing a 403 Forbidden error and gaining access to a protected resource. There are a number of different ways to bypass a 403 error, but none of them are guaranteed to work. Some of the most common methods include:

· Path fuzzing: This involves trying to access the resource using different variations of the path. For example, if you are trying to access a resource at /admin/, you could try /admin/’,/admin%2e/, or/admin/.htaccess`.

· HTTP header fuzzing: This involves trying to access the resource using different HTTP headers. For example, you could try setting the Referrer header to a different website or setting the User-Agent header to a different web browser.

· Exploiting vulnerabilities in the server software: This is a more advanced method, and it can be very dangerous if you don’t know what you’re doing.

What is the 4-Zero-3 tool?

This tool has all the possible techniques to bypass the 403/401 Error. You can learn more about it from Github

GitHub - Dheerajmadhukar/4-ZERO-3: 403/401 Bypass Methods + Bash Automation + Your Support ;)

I started with basics, collecting all the subdomains of the target using various tools like amass, sublister, and more.

I used waybackurls along with httpx to probe the URLs and retrieve the current status of the URLs.

I found https://staging.target.com/actuator/prometheus is giving me a 403 error but the parent folder of the same is giving me [200 OK] status. As I have found a few bugs on the targets using “spring boot”, so, I was familiar with “/actuator” folders on websites but I was not aware of “/prometheus” like what it is and why it is used, So I use google to gather some information about it. If you don’t know let me brief you about it.

What is Actuator?

Spring Boot Actuator is a sub-project of Spring Boot that provides production-ready features for monitoring and managing Spring Boot applications. It exposes operational information about the running application, such as health, metrics, info, dump, env, etc., through HTTP endpoints or JMX beans.

The actuator is enabled by default in Spring Boot applications. To expose the actuator endpoints, you need to add the spring-boot-starter-actuator dependency to your project. Once the dependency is added, you can access the actuator endpoints at the /actuator endpoint.

What is Prometheus?

Prometheus is a monitoring system and time series database. It is presumed that untrusted users have access to the Prometheus HTTP endpoints and logs. They have access to all time series information contained in the database, plus a variety of operational debugging information. It is also presumed that only trusted users have the ability to change the command line, configurations file, rules files, and other aspects of the runtime environment of Prometheus and other components.

I found this endpoint interesting so I used 4-ZERO-3 to bypass it and after testing a few payload tools found that using URL Encoding, I was able to bypass it.

So the URL looks something like https://staging.target.com/actuator/prometheus;%2f..%2f..%2f

After investigating the endpoint I found a few interesting information in it, which may help an attacker to further investigate the target application and exploit it accordingly.

Mitigation

To fix a 403 Bypass, you need to identify the method that is being used to bypass your security measures. Once you have identified the method, you can take steps to mitigate the risk.

Here are some general steps that you can follow to fix a 403 Bypass:

· Identify the method that is being used to bypass your security measures. You can do this by analyzing your server logs and looking for suspicious activity. You can also use a web application firewall (WAF) to detect and block malicious traffic.

· Update your server software. Make sure that you are using the latest version of your server software, and that all of your security patches are installed.

· Configure your server correctly. Make sure that your server is configured correctly and that all of your security measures are enabled.

· Use strong passwords and authentication mechanisms. Make sure that you are using strong passwords and authentication mechanisms for all of your accounts.

· Monitor your server for suspicious activity. Use a monitoring tool to monitor your server for suspicious activity, such as failed login attempts and unusual traffic patterns.

Here are some additional steps that you can take to fix specific types of 403 Bypass attacks:

Path fuzzing: To prevent path fuzzing attacks, you can use a web application firewall (WAF) to block requests that contain suspicious characters in the path. You can also configure your server to deny access to all files and directories that are not explicitly allowed.

HTTP header fuzzing: To prevent HTTP header fuzzing attacks, you can use a WAF to block requests that contain suspicious HTTP headers. You can also configure your server to ignore or deny requests that contain certain HTTP headers.

Exploiting vulnerabilities in server software: To prevent vulnerabilities in server software from being exploited, you should keep your server software up to date and install all of the security patches. You should also configure your server correctly and use strong passwords and authentication mechanisms for all of your accounts.

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.

impratikdabhi

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

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

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

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

Hunting for Hidden Treasures: Unveiling the 403 Bypass Bug Bounty Adventure 🕵️‍♂️💰 was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello there! I’m Pratik Dabhi, a bug bounty hunter and penetration tester. Many of you may already be familiar with me, but for those who aren’t, you can visit my website to learn more about what I do and who I am.

In this blog, I wanted to share an interesting bug that I have found on an MNC (Multi-National Company) Website. While I was in the recon phase I found an interesting parameter that made me think to test it for CRLF Injection. So in this blog, I am going to share the methods and tools I used during this phase also I will share some tips that you can use during your bug-finding process. Let’s get started.

What is CRLF Injection?

The CRLF injection attack is one of several types of injection attacks. It can be used to amplify more malicious attacks such as cross-site scripting (XSS), page injection, web cache poisoning, cache-based obfuscation, and more. A CRLF injection vulnerability exists if an attacker can inject CRLF characters into a web application, for example using a user input form or HTTP request.

Tools I have used in this — Crlfuzz, Burpsuite, and Windows Terminal

I started with basics collecting all the subdomains of the target using various tools like amass, sublister, subfinder, and more. Then I found the subdomain.redacted.com subdomain.

I initiated website fuzzing using tools such as Waybackurls and Gobuster. Subsequently, I forwarded all the unique parameters and URLs through a proxy to facilitate examination using Burp Suite.

After examining 10 of URLS I found subdomain.redacted.com/%0D%0A whatever we type after this it used to come on the response header. So I thought why I don’t give CRLFUZZ a try to find any CRLF vulnerability.

As here in the above image, I have confirmed that the target site is vulnerable to CRLF Injection. So I tried to use other exploits which I can trigger using CRLF Injection.

Exploits I can trigger using CRLF Injection –

Cookie Injection: It is a web security vulnerability that occurs when an attacker is able to inject malicious data into a user’s cookies. This can be done by exploiting a flaw in the way that the website handles user input, such as through a form or a request parameter. Once an attacker has successfully injected malicious data into a user’s cookies, they can then use that data to gain unauthorized access to the user’s account or to perform other malicious actions.

Disabling XSS Protection: If the website has disabled cross-site scripting protection (XSS), it is more vulnerable to XSS attacks. XSS attacks are a type of web security vulnerability that allows an attacker to inject malicious code into a website. This code can then be executed by other users when they visit the website, potentially giving the attacker access to their cookies, session tokens, or other sensitive data.

HTTP Header Injection: HTTP header injection is a type of web security vulnerability that allows an attacker to inject malicious data into the HTTP headers of a web request. This can be done by exploiting a flaw in the way that the website handles user input, such as through a form or a request parameter.

Once an attacker has successfully injected malicious data into the HTTP headers of a web request, they can then use that data to gain unauthorized access to the user’s account or to perform other malicious actions.

Mitigations

A developer should keep the following things in mind to prevent CRLF injection:

Sanitization of user input.

Encode CR & LF characters (\r, \n) so that even when they’re supplied, they aren’t recognized by the server.

Validate the user input before they reach the response headers (e.g. by using methods like StringEscapeUtils.escapeJava()). An unnecessary header should be disabled.

I end this blog here. Hope this helps you to find new bugs.

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

Web Application Vulnerabilities: CRLF Injection and Beyond was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey guys Pratik this side. In this writeup, I’m going to share some of my open-redirection hunts and what resources I use to find open-redirection as well as how do I make its severity higher. So let’s hop into it.

What is an Open-redirection Vulnerability?

According to netsparker.com, “An Open Redirection is when a web application or server uses an unvalidated user-submitted link to redirect the user to a given website or page. Even though it seems like a harmless action to let a user decide on which page he wants to be redirected, such techniques if exploited can have a serious impact on the application security, especially when combined with other vulnerabilities and tricks”.

Open-redirections are the low hanging fruits. If you hunt for it

Some resources

https://twitter.com/jae_hak99/status/1279303602532528128

https://twitter.com/search?q=openredirection&src=typed_query

https://twitter.com/search?q=open%20redirection&src=typed_query&f=live

Some dorks

/{payload}

?next=

?url=

?target=

?rurl=

?dest=

?destination=

?redir=

redirect_uri=

?redirect_url=

?redirect=

/redirect/

cgi-bin/redirect.cgi?{}

/out/

/out?

?view=

/login?to=

?image_url=

?go=

?return=

?returnTo=

?return_to=

?checkout_url=

Common Parameters

dest, redirect, uri, path, continue, url, window, to, out, view, dir, show, navigation, Open, url, file, val, validate, domain, callback, return, page, feed, host, port, next, data, reference, site, html

What happens in open-redirection (Short Story)

Basically when the ?url=redirects-to-home but you insert your malicious place then the web page redirects to there.

Private Bug Bounty Story

I found 8+ open redirections on bugcrowd public and private programs but most of them haven’t patched yet so I don’t have the permission to share the the info for those bug but 2 bugs that are patched.

First case

Redacted.com using /// and then payload then webpage is redirect to payload.com

Like this

redacted.com///pratikdabhi.com — -> pratikdabhi.com

Second Case

Redacted.com/google/?dest_path=, here in place of path={}, I use javascript:alert() and changed its severity from P4 to P3

Like this

redacted.com/google/?dest_path=javascript:alert() — -> javascript popup

Url Based xss payloads

https://github.com/R0X4R/D4rkXSS

Open-redirection leads to SSRF (PortSwigger)

In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, suppose the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection and makes a request to the internal URL of the attacker’s choosing.

*Solve the lab to get hands-on practice.

→ Lab solve

In the lab, we get 2 vulnerable params that are stockApi and path, where path has open-redirection and stockapi has ssrf vulnerability. First, we have to do some param spidering using burpsuite.

By clicking on check stock we get the stockapi param

After we get the param just send that request to the repeater.

To get path param we need to click on next product link.

Then we get our ?path= param send this request to repeater

Now copy the whole path /product/nextProduct?currentProductId=1&path=

Paste it on stockApi param. Like this stockApi=/product/nextProduct?path={here paste your given ssrf ip} for me its stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin

Then click on go wait sometime then you get the response scroll down and you get the path which you use to delete user Carlos.

Then just paste the path in stockApi (stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?user=carlos) param and click go and BOOM! Lab solved.

Impact of Open-redirection (AC PortSwigger)

The user may be redirected to an untrusted page that contains malware which may then compromise the user’s machine. This will expose the user to the extensive risk and the user’s interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.

The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker-controlled web page that appears to be a trusted web site. The phishers may then steal the user’s credentials and then use these credentials to access the legitimate web site.

hanks everyone for reading:)

Happy Hacking ;)

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

impratikdabhi

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

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

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

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

Open-redirection leads to a bounty was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.