Explaining and exploiting open redirect vulnerabilities

In this article, I’m going to cover what an open redirect vulnerability is, how to discover and exploit it, and some common defense evasion tactics. If you have any corrections or better information, do share them in the comments.

Open redirect vulnerability occurs when a flaw in the client- or server-side website code allows an attacker to use the legitimate website to redirect a user to an attacker-controlled website, essentially exploiting the trust the user has in the website. This is then usually used in email phishing campaigns to gain trust.

Open redirect may be confused with, but is different from SSRF (Server Side Request Forgery), since in SSRF an attacker tricks the server into requesting a website, but in open redirect, an attacker tricks the server or victim browser into redirecting the victim from the legitimate website to a potentially malicious website hosted by the attacker.

Discovery

What you usually want to look out for are URL parameters that look like a path or a URL. Here are some examples of the types of parameters I’ve found open redirects in the wild:

https://site.com/login?ReturnURL=https%3A%2F%2Fsite.com%2Fmy-account

https://site.com/form-complete?return=%2Fcompleted

https://site.com/api/v2/redirect?url=https%3A%2F%2Fsite.com%2F404

If you can’t find any parameters, you might want to try finding hidden ones by fuzzing the parameters with a tool like ffuf . Sometimes dangerous parameters and endpoints are left exposed either accidentally or because the developers forget to remove them from the production environment.

As a parameter fuzz wordlist, I would suggest using burp-parameter-names.txt. If you have seclists installed you can find it in /usr/share/seclists/Discovery/Web-Content. On Kali, you can install it with:

apt install seclists

or download it from Github: https://github.com/danielmiessler/SecLists.

Exploitation

If the parameter includes a URL like https%3A%2F%2Fsite.com%2Fmy-account , try changing the URL, and if it works, great; you just found an open redirect vulnerability! If it doesn’t, try the method below or the defense evasions.

If the parameter looks like a path: %2Fcompleted , replace it with a URL. If that doesn’t trigger a redirect, you can abuse the http://username:password@site.com or username@site.com authentication syntax that browsers support to your advantage. So let’s say this is what happens when you go to the URL with the redirect parameter:
1. The server receives the HTTP request.

2. The server parses the HTTP parameter.

3. The server adds the parameter value to the end of the main website URL and redirects the user to it:

app.get('/form-complete', (req, res) => {
var redirectPath = req.query.return;
res.redirect('https://site.com'+redirectPath)
});

Now coming back to the authentication syntax, we can add @attacker-website.com as the return parameter.

This would result in the user getting redirected to https://site.com@attacker-website.com. The browser would now try to log into the site attacker-website.com and use “site.com” as a username.

GET /form-complete?return=%40attacker-website.com HTTP/1.1
Host: site.com
Accept: application/json

↓

HTTP/1.1 200 OK
Location: https://site.com@attacker-website.com

↓

GET / HTTP/1.1
Host: attacker-website.com
Accept: application/json

↓

<attacker phishing website>

Includes domain

If the website has a function that checks if the website domain is included in the URL, you can bypass this by giving it as an argument to your own website like this:

https://site.com/login?return=https%3A%2F%2Fattacker-website.com%2F%3Ffoo%3Dsite.com

Payload: https://attacker-website.com/?foo=site.com

Starts with domain

If the site checks if the return URL starts with the domain, you can bypass it by using the same authentication trick as shown in the exploitation section:

https://site.com/login?return=https%3A%2F%2Fsite.com%40attacker-website.com

Payload: https://site.com@attacker-website.com

Blacklist

The website may also blacklist the keywords https:// and http:// . If this is improperly implemented by matching the whole string http:// instead of http, the filter can be bypassed by putting in a third slash in the beginning:

https://site.com/login?return=https%3A%2F%2F%2Fattacker-website.com

Payload:https:///attacker-website.com
↑ Notice the third "/" character

Avoid using return/redirect parameters and use hardcoded URLs instead.Prefix the URL with / like this:Better: "https://site.com/" + path
Bad: "https://site.com" + path

3. Use strict validation with regex or some other way.

const re = /[\w+/+\.]/;
const matches = re.exec(req.query.return);
if (matches) {
/*Redirect*/
} else {
/*Doesn't redirect*/
}To test open redirect in practice, you can use https://webhook.site to test your payload.Burp has an extension for this: https://portswigger.net/support/using-burp-to-test-for-open-redirectionsURL shorteners help make the redirect URL less suspicious.