
Open redirects – a vulnerability class no one but attackers cares about - a1a
https://stevetabernacle.github.io/blog/open-redirects-the-vulnerability-class-no-one-but-attackers-cares-about/
======
tptacek
I don't know, I think this case is pretty flimsy. In practice, the value of an
open redirect against modern applications is for "phishing". But speaking as
someone who has dealt with several ATO dramas over the past two years: users
will click on anything. They're not hovering over links to make sure they're
safe.

Open redirects are worth fixing, but they're a lot more common than I think
people expect they are. I think the severity:low the "good" (unconstrained,
straightforward links, persistent, across all browsers) ones get is well
measured.

I see open redirects as sort of the archetype of the "t-shirt vulnerability"
\--- the one the bug bounty sends you swag, instead of cash, for finding.

~~~
shittyadmin
That's quite true, but I think the value in these attacks is that they work
against more technical users than typical phishing attacks - I remember
several years ago someone posted a link on a large technical subreddit which
appeared to be to youtube.com.

It presented a page which claimed to be an age flagged video - at the time
youtube was having many problems with age flagging videos - and sure enough
many people tried to login to it - they looked at the "(youtube.com)" text on
reddit, they looked at their browser when they first clicked the link, but
they never noticed when the URL changed to offsite when they had to login. It
never struck them that a legitimate youtube link could have sent them offsite.

The solution most of those people arrived was simple though: use password
managers which will force some extra suspicion if the login page doesn't
behave as expected.

EDIT: Found the link and discussion,
[https://old.reddit.com/r/programming/comments/bpy7h/think_yo...](https://old.reddit.com/r/programming/comments/bpy7h/think_youre_immune_to_phishing_attacks_see_if_you/)

By the numbers it looks like about 1/2 the people who made it to the sign in
page made it to the submit page. That's a pretty good result especially given
that it's a technical subreddit and people were primed with "think you're
immune to phishing attacks"...

~~~
chrismorgan
It is interesting to note that YouTube now inserts an interstitial “you are
leaving YouTube” screen on its open redirect spot.

That Reddit shows the domain name _next to the link_ (HN also) is, I think,
the key here—it casually set expectations. Most link situations won’t be like
that, and so I’m broadly with tptacek, that it’s not actually so useful. Plus,
businesses commonly use all sorts of different domains, rather than
subdomains, and something like yourbank-security.com instead of yourbank.com
may not even raise eyebrows—to say nothing of people probably not even
twitching at login.yourbank.com.evil.com anyway.

------
wtracy
A decade ago people were using Google redirects to lure people into visiting
shock sites.

Back then, it seemed reasonable to not consider this a real security flaw. Now
that everyone has a Google account, the possibility of credential theft seems
like something worth taking seriously.

At the very least, either host the redirect on a domain that is clearly
distinct from the domain users log into, or ignore the destination parameter
if the referrer is not a trusted source.

Now I'm wondering if this is also a potential vector for DDoS attacks against
a third party. Widely distribute links "to a cute puppy on Instagram" that
redirect to a URL that triggers a resource-intensive search operation on the
victim's server? (Bonus points if the redirect points to a page that loads an
actual cute puppy in one frame, and targets the victim with a 1-pixel frame.)

It sounds like a stretch, but I can't rule the possibility out. Even if it
can't be used to launch a DDoS, I could see it being used for advertising
fraud.

~~~
geofft
> _Now that everyone has a Google account, the possibility of credential theft
> seems like something worth taking seriously._

Not sure I follow - is the idea to redirect from google.com to an attacker's
site that spoofs the Google login page? I think we'll get more mileage out of
solving that with origin-aware authentication mechanisms (password managers,
U2F, WebAuthn, etc.) and perhaps address bars that show the eTLD+1 instead of
/ more prominently than the full URL. Phishing is already a problem even
without open redirects.

> _Widely distribute links "to a cute puppy on Instagram" that redirect to a
> URL that triggers a resource-intensive search operation on the victim's
> server?_

Keep in mind that unrelated web pages can send GET requests to each other by
just using an image tag, so if your website has a resource-intensive search
delivered over GET and no automation to detect suspicious behavior and spikes
in certain types of requests, you're already vulnerable to this via e.g.
someone submitting an interesting blog page to HN that loads youe search page
as a resource. Either make it POST or add some HTTP-level DDoS protection a la
Cloudflare.

Same with advertising fraud - ad clicks should be POSTs. (Open POST redirects
do seem more dangerous but are probably rare.)

~~~
wtracy
Relying on your customers to use password managers to protect themselves is
not very useful in the Eternal September age of the internet. (I do see your
point that a Google redirect is only marginally more likely to be effective
for phishing than a link to something like goegle.com.)

Everything else in your comment is spot on.

------
TomAnthony
The problem is that often Open Redirects can be leveraged in unexpected ways,
beyond the conventional attacks listed.

I have previously been awarded a bug bounty by Google for an issue that
leveraged open redirects on victim sites to hijack their link equity
(PageRank): [http://www.tomanthony.co.uk/blog/google-login-
hijack/](http://www.tomanthony.co.uk/blog/google-login-hijack/)

It would have allowed a non-trivial financial impact on victim companies.

Secondly, I submitted an issue to Google which leveraged open redirects on
their properties to hijack the login flow (i.e. a user is on an official
Google page, selects a user and is redirected to an attacker for the password
prompt - halfway through the login flow, when a user has likely already
established they are on a real site):
[http://www.tomanthony.co.uk/blog/google-login-
hijack/](http://www.tomanthony.co.uk/blog/google-login-hijack/)

Sometimes open redirects are unavoidable, but all too often they aren't
necessary and so it is simply lazy to not fix them and point to Google and
others who mark them as WONTFIX as reason not to bother doing so yourself.

------
arkadiyt
Surprised the author doesn't mention oauth - open redirects are the achilles'
heel of oauth flows and allow for full account takeovers. It is very common.

~~~
enjo
Very common in 2019? I haven't run across an OAuth provider in some time that
isn't properly checking redirect_uri against at least a whitelist of domains
(if not the full URL).

Is there another redirect attack I'm not aware of? The other attacks on
redirect generally involve gaining access to some other page on the client you
are attacking and using that as a redirect which the provider will often allow
if it's only validating the domain. That's not really an open redirect,
however...

Am I missing something?

~~~
bennofs
If they check the domain, chain it with another open redirect in the same
domain.

------
edent
They're also really useful for evading spam filters. I found[1] a bunch of
government domains with open redirects.

Spammers were sending out emails containing links to
`example.gov.uk/redirect?url=dodgy-viagra.ph` - and certain spam filters were
trained to whitelist "trusted" domains.

You also see a lot of open redirect abuse on forums - especially where they're
configured to only show the first few dozen characters of a link.

[1]
[https://www.openbugbounty.org/researchers/edent/](https://www.openbugbounty.org/researchers/edent/)

------
quangio
Open redirect alone doesn't look dangerous. But combining it with another
vulnerabilities like OAuth misconfiguration -> account takeover. I wrote a
blog about this common mistake some time ago: [https://pwn.netlify.com/open-
redirect-to-oauth-token-theft.h...](https://pwn.netlify.com/open-redirect-to-
oauth-token-theft.html)

------
codezero
If you ever get a third party penetration test, this is like, the first thing
they find. To say "no one but attackers cares about," is pretty nonchalant –
we immediately patched up this clearly bad attack vector, despite it not being
extremely likely to manifest as a serious problem to us, because, like, you
should just do that.

~~~
OliverJones
I just fixed one myself. It's not that hard to sanitize redirect parameters.
One good way, if it fits your app, is to insist they be internal-only:
"/app/profile" rather than external
"[https://evil.example.com/phish/login"](https://evil.example.com/phish/login")

I believe it's worth fixing these, not only because it gets penetration tests
to shuddup, but because cybercreeps...

------
hayksaakian
Open redirects are also used for SEO spam to hijack domain authority and other
nefarious purposes.

It's silly that these big tech companies won't fix them.

------
GlitchMr
I once reported an open redirect attack to GitHub, and they were like, nah,
WONTFIX. I believe the issue still exists.

That said, how useful is an open redirect attack really?

~~~
Kalium
Depends on where in the system it is. If it's part of a flow involving
sensitive data, an open redirect can be used to harvest that data from users.
This might be anything from login credentials to bank account info, depending
on what flow is involved.

------
userbinator
Open redirects are also used to prevent referrers from propagating through. In
that sense, they're very useful for anonymisation.

~~~
trumped
there are many browser extensions to spoof or disable your referrer

~~~
userbinator
The point is for the site owner to prevent it from showing up in the referer
logs of other sites, regardless of browser.

~~~
trumped
I wish every site would do that... but they like to do the opposite

------
tikumo
You could just add some kind of hash based on the redirect url and check that,
to ensure that it can't be altered.

~~~
xxs
For this you need some pepper (i.e. a secret) to prevent doctoring.

The better option is an encrypted blob containing all relevant data and a
timing component. Of course those thing do require effort. It makes it opaque
for everyone but the server handling the redirect.

------
ggggtez
I don't think most browsers support redirect to javascript anymore. Maybe IE?

~~~
dbielik
Yes, they still do depending on how you redirect (i.e. unsanitized:
location.href = url).

A nice benefit of using a framework like angular, Vue, react, etc, is that
they prevent attacks like this unless you explicitly disable those features.

------
foobar_
Is there a definitive list of attacks with prevention mechanisms somewhere ?

~~~
Kalium
You might find this to be interesting and informative reading:
[https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)

This covers what the vulnerabilities are, how they happen, how they work, and
how to prevent them. It's not exhaustive, because that list would be endless,
but it's one of the best resources for a web developer who is not a security
practitioner.

------
bronco21016
Also a great tool for bypassing corporate firewall for browsing.

