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
Definition
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.
Vulnerability
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
Link is dead, and I'm lazy to republish it, sorry
.
(() => {
const u = new URL(window.location);
const r = u.searchParams.get('r');
if (r === 'javascript:alert(document.domain)') {
window.location.href = r;
}
})(); 
"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.
"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
Link is dead, and I'm lazy to republish it, sorry
.
"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:
- if you are not logged in, the page shows a login form (and once logged, redirects you to a place decided by the attacker)
- if you are logged in, it directly redirects you to that arbitrary page
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.
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 email 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).
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://*.example.reinom.com/openredirect/or-ex1.php?r=https://reinom.com/open-redirect-demo"
alt=""/> 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).
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).
Since CSP violation is active, the browser sends a violation report (to the attacker's domain you are browsing right now).
The attacker now knows that you are currently logged into this vulnerable "xenos.reinom.com" website.
If this was not an "Open Redirect on login condition" (which is very widely spread IMO) but an
"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.