Everyone knows what a redirect is: sending a user from one site to another. So what is an Open Redirect? It sounds like the name of an open standard, but in reality it’s a vulnerability that lets an attacker silently send a user to any site from a trusted domain.
warning
All information is provided for informational purposes only. Neither the editorial team nor the author is responsible for any potential harm resulting from the materials in this article.
This flaw is mostly used for phishing. An attacker redirects users from a vulnerable, trusted site to their own phishing page and steals their data. This vulnerability was actively used by hackers in attacks against government websites as reported here.
Imagine if apple.com allowed an open redirect to apple.evil.com. A user would think they’re on a trusted site but end up submitting their data to the attacker’s domain. In fact, a similar vulnerability has already been found.
What if there’s a live vulnerability in Google right now? A user goes to Gmail via google.com and enters their credentials. Maybe they glance at the browser’s address bar and the URL—everything looks fine. They land in their inbox and see the usual, everyday view. How often do users check the address bar at that point? Meanwhile, relentless Russian hackers aren’t sleeping!
A deeper dive into Open Redirects
For example, suppose we have a trusted site http://. However, it contains an open redirect vulnerability that looks like this: http://. After logging in on the site, the user is redirected to http://.
Let’s try replacing http:// with http://. That gives us the link http://. If, after logging in, we follow this link and get redirected to evil., the site has an Open Redirect vulnerability.
How does this vulnerability arise?
Website administrators typically either aren’t aware of this vulnerability or don’t validate the redirect URL against a predefined allowlist. Vulnerable server-side code might look something like this (PHP example):
<?php$redirect_url = $_GET['url'];header("Location: " . $redirect_url);?>Then the vulnerable URL will look like this: http://.
Here’s the Java equivalent — this is also a server-side redirect.
public class RedirectServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String query = request.getQueryString(); if (query.contains("url")) { String url = request.getParameter("url"); response.sendRedirect(url); } }}The server receives a GET request with a url parameter and redirects the browser to the address provided in that URL.
As for a client-side redirect, it might look something like this:
<a href="http://bank.site.com/redirect?url=http://evil.com">Click here to log in</a>A user might assume the link is safe because it starts with bank.site.com. However, after clicking it, they’ll be redirected to a lookalike phishing site.
How to Find This Vulnerability Yourself
- Carefully go through all the site’s links and look for redirect parameters.
- Alternatively, use fuzzing with specialized tools.
- Enter into Google search:
site:.target. com inurl: redirectUrl=http - Analyze where redirects might be used—for example, a post-login redirect.
- Try to reproduce the vulnerability with various known tricks:
target.,com/ ?redirect_url=https:// evil. com target.. You can find other tricks at the links.com// evil. com
Exploiting the Vulnerability: Key Threats
Phishing
To carry out the attack, the attacker sends an email containing the link http://. The victim sees a trusted-looking URL and follows it to a page identical to the legitimate site. They then enter their username and password, which the attacker captures with a script.
This vulnerability was used to phish Visa users. It was also used for bank‑account phishing. People clicked a banner containing a vulnerable link, which redirected them to a phishing site.
Chaining with Another Vulnerability
Another attack variant is to send the victim to a site hosting a browser exploit or a CSRF attack. You can also chain an open redirect with XSS, as a researcher did with google.com.
There are many ways to combine them. The key is to sit down and methodically, persistently try out different approaches.
Using Open Redirects for DDoS
There’s an interesting script on GitHub that uses an open redirect to launch DDoS attacks.
The author describes UFONet as a botnet for conducting Layer 7 DDoS attacks (for educational purposes, of course).
There are videos online where hackers use UFONet against real websites. You can download it and play around with it on your own site. But don’t expect too much from it! 🙂
$ ls -l$ git clone https://github.com/epsylon/ufonet.git
Google’s Open Redirect Vulnerability
In 2016, a researcher discovered a vulnerability in Google. The issue was that when following a link with a redirect, it would open the standard Google sign-in page. The link looks something like this:
https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fappengine.google.com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fevil.com%2F&service=ah
Anyone who opens it will be redirected to evil.. How can that be abused? Google’s developers told the researcher that an open redirect by itself isn’t considered a vulnerability and chose not to fix it. Attackers, however, have seized on it and are actively exploiting it. Let’s take a closer look at their techniques.
Link delivery
In a targeted attack, the attacker typically engages the victim directly, delivering a weaponized link under any pretext and via any channel. In a mass campaign, they blast out spam or seed the link on sites where the victim is likely to take the bait and click.
One flavor of this spam is an email sent to a non-Gmail address claiming your account is linked to a Gmail mailbox. The message then urges you to sign in to your account under various pretexts.
Attack Techniques
Google Account Phishing
After clicking a link in an email, the user lands on a google. sign-in page. They enter their credentials, but then see the same sign-in window again with an error message about invalid credentials (even though they were correct). So what’s going on? Usually, the person thinks they mistyped or entered the wrong password.
In reality, they’re already on the attacker’s site. The page is just showing a fake window that looks identical to the Google sign‑in.
The information entered in this window will be sent to a PHP script that stores it on the attacker’s server.
<?phpif (empty($_POST["username"])) { exit();} else { $result = array( 'username' => $_POST["username"], 'password' => $_POST["password"] ); echo json_encode($result); $Login = $_POST['username']; $Pass = $_POST['password']; $log = fopen('accounts.php','a+'); fwrite($log,"<br> $Login:$Pass \n"); fclose($log);}?>After clicking the button, the victim is redirected to their inbox, unaware that it’s been compromised. The attacker on the other end of the screen grins, having obtained the prized data.
Malware Infection
Using the same trick, after the sign-in prompt at google. the victim can be redirected to a bogus “browser update” page that prompts them to download a malicious file.
Once the page loads, the victim is redirected to their inbox and suspects nothing. There’s a good chance they’ll be pleased with the “updated browser” and end up installing the malware themselves.
Phishing for Other Accounts (PayPal, Amazon, VKontakte, etc.)
After the authentication window at google., the victim lands in what looks like their inbox. However, all the latest messages are from a particular site that persistently urges them to log in under any pretext.
In reality, it’s a fake webmail interface—a prop where nothing works except opening the message. The message contains a link to a phishing site with a disguised domain, for example, paypal.login-com.com. A careless victim, panicking, clicks through to the attacker’s site and hands over their credentials.
Bottom line
The Open Redirect vulnerability is a web application flaw that lets attackers silently redirect users to arbitrary destinations and trick them into accepting anything the attacker serves. To prevent this, at a minimum you should warn users before performing a redirect.
The internet is teeming with vulnerabilities. Malicious hackers from Russia and elsewhere never sleep, cashing in by stealing other people’s data. Meanwhile, their white‑hat counterparts earn thousands of dollars by finding such flaws through bug bounty programs.
In short, stay alert: verify the URL in the address bar, don’t sign in via links from emails, and be cautious if a login window pops up unexpectedly or looks even slightly suspicious. Warn less tech-savvy friends and family about this risk. And if you want to learn more about open redirects or level up your skills working with them, check out the useful resources linked below.