Open Redirect: The underestimated vulnerability that turns your trusted relationships into traps

Introduction : Hi everyone, I'm ATTER Koffi Kallern, also known as hackus_man, passionate about ethical hacking and a web penetration testing specialist. Since high school, I've been training in this field, which I'm so passionate about. I haven't yet pursued formal computer science studies due to financial constraints, but that hasn't stopped me from pursuing my passion for protecting computer systems through self-study. Here, I'll show you how I found an Open Redirect vulnerability in a real application and how you can potentially discover it in your own situation.

Link to my LinkedIn profile : https://tg.linkedin.com/in/atter-koffi-kallern

An Open Redirect is a security vulnerability that allows an attacker to control the destination of a legitimate website redirect. In practical terms, when a web application uses a parameter like ?url=, ?redirectTo= or ?next= to know where to send the user, if this parameter is not validated, an attacker can replace it with any address.

In concrete terms, when a web application uses a parameter like ?url=, ?redirectTo= or ?next= to know where to send the user, if this parameter is not validated, an attacker can replace it with any address.

The classic model:

1. Legitimate website: https://site-victime.com/redirect?url=https://site-victime.com/profil

2. Malicious URL: https://victim-site.com/redirect?url=https://attacker-site.com 3. Victim clicks → redirected to attacker's site

In one sentence: The application blindly trusts the URL provided by the user.

Why is this serious?

Because the user sees the real domain name in the URL and clicks without suspicion.

Why does Open Redirect deserve your attention ?

SQL injections are becoming rare. Modern ORMs (Prisma, TypeORM) and prepared statements have done their job. XSS vulnerabilities persist, but frameworks like React and Vue provide default protections (automatic escaping). Open Redirect, however, remains. No modern framework automatically protects against an improperly validated redirect.

Where do I start on my end to discover this kind of vulnerability?

I start by listing all the URLs of the application or website in question using Katana. Learn more about Katana… https://github.com/projectdiscovery/katana

I use this command:

katana -u https://ex.com/ -d 5 -jc -kf all -fx -ef css,woff,woff2,png,jpg,jpeg,gif,svg,ico,mp4,mp3,pdf,doc,docx -c 50 -o all_urls.txt

Breakdown option by option : Katana crawls the site https://ex.com/ in depth to retrieve all possible URLs, filtering out some unnecessary files, and then saving the result to a file.

• • u https://ex.com/ : Defines the target to scan
• -d 5 : Defines the crawl depth; Katana will follow links up to 5 levels. The larger the depth, the more endpoints you'll find (but the slower the crawl).
• -jc : Enable JavaScript crawling; Katana will execute the JS to discover hidden routes (SPA, API, etc.). Very important for modern websites.
• -kf all : Use all possible sources to find URLs (HTML, JS, robots.txt, sitemap.xml, etc.)
• -fx : Enables advanced filtering, allowing you to exclude certain file types (defined with -ef).
• -ef css,woff,woff2,png,jpg,jpeg,gif,svg,ico,mp4,mp3,pdf,doc,docx Excludes unnecessary files: Images (png, jpg…), Fonts (woff…), Media (mp4, mp3), Docs (pdf, doc…)

Objective: to keep only the relevant endpoints (API, pages, parameters).

. -c 50 : Defines concurrency (threads), 50 parallel requests → fast scan but be careful: it can be detected or blocked.

. -o all_urls.txt : Save the results to all_urls.txt

Final result : You will get a file containing: endpoints , API routes ,hidden pages , interesting parameters.

An image to illustrate what I'm saying :

After using Katana to extract all the URLs, we need to map the attack surface towards open redirect vulnerabilities by searching for certain parameters in the URLs, and these parameters are generally:

?checkout_url={payload}
?continue={payload}
?dest={payload}
?destination={payload}
?go={payload}
?image_url={payload}
?next={payload}
?redir={payload}
?redirect_uri={payload}
?redirect_url={payload}
?redirect={payload}
?return_path={payload}
?return_to={payload}
?return={payload}
?returnTo={payload}
?rurl={payload}
?target={payload}
?url={payload}
?view={payload}
/{payload}
/redirect/{payload}

?checkout_url={payload}
?continue={payload}
?dest={payload}
?destination={payload}
?go={payload}
?image_url={payload}
?next={payload}
?redir={payload}
?redirect_uri={payload}
?redirect_url={payload}
?redirect={payload}
?return_path={payload}
?return_to={payload}
?return={payload}
?returnTo={payload}
?rurl={payload}
?target={payload}
?url={payload}
?view={payload}
/{payload}
/redirect/{payload}

Now search for its parameters ?

There are several ways, one of the ways I use is to rely on the gf tool. What is the gh tool?

GF is the tool that transforms a raw file of URLs (Katana output) into priority targets. It saves you hours of manually searching for relevant parameters. After crawling with Katana, the next logical step is GF. This is exactly what professionals do to save time and find more vulnerabilities. Learn more about the tool: https://github.com/tomnomnom/gf

Simply run: cat all_urls.txt | gf redirect > urls_redirect.txt

This command transforms a large raw file into a targeted file containing only the URLs that deserve your attention for the Open Redirect. This is the essential step between crawling and vulnerability testing.

An image to illustrate this :

What tipped me off was the consistent presence of the lng and redirectTo parameters in the URLs. The lng parameter defines the language (en or fr), while the redirectTo parameter indicates where to redirect the user after this language change. It was precisely this second parameter that caught my attention: why would a redirect parameter accept external values?

A careful developer would limit redirects to internal site paths. The absence of this restriction immediately made me think of a possible vulnerability in Open Redirect. Let's investigate this together… I'm heading over to my friend Burp Suite.

Burp Suite is an intercepting proxy that sits between my browser and the server. It allows me to capture, modify, and replay HTTP requests. With it, I can: Intercept the request containing the lng and redirectTo parameters.

. Modify the value of the redirectTo parameter in real time

. Replace the internal path with an external domain such as https://evil.com

. Replay the modified request to the server

. Observe the server's response and see if it accepts the external redirection. Learn more about Burp Suite: https://www.youtube.com/watch?v=rQRhHhhGTjM&t=1739s&pp=ygUXQnVycHMgc3VpdGUgdG91dCBzYXZvaXLSBwkJBAsBhyohjO8%3D

So the idea here is just to change: /_next/static to for example https://evil.vom to see if the redirection will be processed, if so bingo we have found an open redirect vulnerability.

And in my case it worked, here's the proof :

Why did it work?

Now we understand that the redirection worked for a simple reason: the server does not validate the redirectTo parameter.

How can we protect ourselves from these kinds of vulnerabilities?

Never trust a URL provided by the user

The 3 golden rules: 1. Always validate: Verify that the destination is authorized 2. Always filter: Block external domains 3. Always limit: Use a whitelist or internal identifiers

⚠️ The simple rule: If you must use a redirect parameter, NEVER pass a full URL. Instead, use an internal identifier.

The user is the enemy, never trust them.

To learn more about detecting and exploiting open redirect vulnerabilities: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect

In conclusion: Open Redirect is an underestimated but dangerous vulnerability. Many developers consider it "not critical" because it doesn't allow direct access to data or the server. However, this is a misjudgment. Why is it dangerous?

Because it breaks trust. The user sees the URL of the legitimate site and clicks without suspicion. But in reality, they land on a malicious site that can steal their login credentials, personal data, or install malware.

What an attacker can do with an Open Redirect:

— Create phishing campaigns that are indistinguishable from real ones

— Stealing OAuth tokens and taking control of accounts

— Bypassing CSRF protections

— Redirecting to pages exploiting browser vulnerabilities An Open Redirect might seem harmless, but it's often the gateway to much more serious attacks. That's why it should never be ignored, whether you're a developer or a bug hunter.

The good news: This is perhaps one of the easiest vulnerabilities to fix. Input validation, a domain whitelist, or the use of internal credentials is enough to block it completely.