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.

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...

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"...

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.

The results could have been skewed by people clicking through intentionally to experience the redirect.

Author here. Thanks for your comment. I think you have a valid point about users clicking anything. However I would only say that's the case if you send around 20 phishing mails. In a targeted attack you want to send one or two phishing mails and you wanna maximize your chances of success to avoid a reaction from the blue team.

I agree that the impact is low compared to other vulnerabilities. It is definitely the case that you get a t-shirt (at best) for it. Though, my point is that they could be critical for the users, not for the website itself. An attacker that don't really care about the vulnerable website can still exploit the trust in the vulnerable website to perform attacks on the user he is interested in (e.g. hash stealing or malicious redirects). In fact, I believe malicious redirects is a really common payload of XSS flaws.

Right, but a targeted phishing attack against an internal user is just as likely to rely on an application (or a facsimile of an application) you don't control, like a benefits management portal or something that supposedly authenticates through an SSO.

I guess if your argument is that there would be high value in eradicating open redirects wholesale, I sort of see your point. But the incremental value of eliminating one open redirect is marginal at best.

There is also value in customer trust. If a customer gets burned by a Google.com link, they are going to check next time they see such a link. Google would be better of if customers felt 'oh, it is Google so it must be safe'.

That might not be an issue for Google, but I could see it being a big problem for a company that relies heavily on projecting a "family friendly" image (think Disney).

Back in the day you could change some URL parameters and make it look like Toys R Us was selling firearms on their website because they used the same ecommerce back end as a sporting goods store. Like you'd go to the URL and it would be a hunting rifle (or whatever) but it would be on the Toys R Us site.

I don't think Toys R Us was ever harmed but it was mildly amusing and I'm sure a few people's panties got knotted after they found out Toys R Us doesn't actually sell firearms and they got all enraged over nothing.

I hadn't heard of this issue specifically, but it sounds like you may be talking about eBay Enterprise[1]. They ran a lot of e-commerce operations for brick and mortar stores at one point, including both Toys R Us and Dick's Sporting Goods.

[1] https://en.wikipedia.org/wiki/EBay_Enterprise

As a security professional I agree. When I worked at companies with bug bounties I always considered open redirects in the lamest category of bugs, unless the open redirect was cleverly combined with other issues, which was very rare.

I once worked to patch an open redirect on a system where the redirect was at the end of the oauth flow. Could have been used for some pretty nasty phishing attacks.

I suppose there's some potential for SSRF abuse, although it's easy to argue the fault lies elsewhere.

Right, and also internal CSRF is in fact an underrated vulnerability.

One other note for open redirects is that it can trick spam filters into thinking it's legit. Some filters follow links but some others do not. So you can use that as a way to improve spam scores maliciously.

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.

> 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.)

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.

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/

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/

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.

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.

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?

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

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/

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...

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.

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"

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

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.

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?

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.

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

You have never needed an open redirect for that (just an internal redirect page).

In the past, one solution was to HMAC the destination URL with a time component (i.e. the redirect is only valid for a short period of time).

Today, you can check the origin header when your user lands on the redirect page or just tell the browser what information you want in the referrer (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...).

I really, really hate such things: they’re no longer at all necessary (see referrer-policy), and they clutter up browser history with an extraneous entry every time.

there are many browser extensions to spoof or disable your referrer

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

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

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

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.

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

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.

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

You might find this to be interesting and informative reading: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...

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.

Also a great tool for bypassing corporate firewall for browsing.