The notes are available on slideshare.net

I’ve had to pull the presentation from slideshare.net temporarily – I’ll re-upload as soon as possible The problem at slideshare has now been resolved.

There was an interesting article on the Google Webmaster Central blog back in Jan talking about open redirects being abused by spammers.

One point they didn’t go into too much detail on is that of phishing vectors. If you’re running a site with any kind of user registration and you have a redirect script that allows redirects to any arbitrary urls. Then it’s fairly likely that you’ve straight away made it possible for a 3rd party to phish your registration form.

Let’s see an example of how something like this would work, first a standard redirection script:

Target Site

buyeverythingawesome.com

Attack URL

http://buyeverythingawesome.com/redirect?url=http://buyeverythingawesomee.com/login/

Attacker’s Bogus Domain

buyeverythingawesomee.com

The target site has a script which blindly redirects to anything passed to it.

All the attacker has to do is send a victim an email telling them to login to their account to view the latest offers. The link they send is http://buyeverythingawesome.com/redirect?url=http://buyeverythingawesomee.com/login/

On the bogus domain the attacker will have prepared a copy of the site’s login screen. All they need to do is get the user to login and then redirect the user back to the original site and if possible directly to the failed login page of the original site.

The way to mitigate this is to only allow redirects to your internal site or provide a whitelist of external urls that are allowed to be redirected to.

Open Redirect Login Script

Open Redirects in a login script are even worse in a way as the attacker will send the user to the real site’s login script.

The symptoms of this kind of problem are visible with a setup like so:

Target Site

buyeverythingawesome.com

Attack URL

http://someawesomsite.com/login?after=http//:somewawesomsite.com/loginfailed/

Attacker’s Bogus Domain

somewawesomsite.com

All the attacker needs to do is to get the unwitting victim to visit http://someawesomsite.com/login?after=http://somewawesomsite.com/loginfailed/

The user will be presented with the login screen for the genuine site. Once they login they are redirected to a bogus site with a “Your login has failed message – please try again” simply copied from the real site. The second time the user logs in they are logging-in to a bogus copy of the real site. Once the credentials are stolen the user can be redirected back to the real site where they are successfully logged in (This is because they aren’t redirected until they sucessfully login).

This is particularly nasty because the start and end points of this hack are the genuine site and as a result this kind of attack is much more likely to slip by unnoticed.

As a picture speaks a thousand words see this diagram of the flow: Open Redirect Phishing Vector (.png)

Preventing these kind of attacks

Firstly make absolutely sure you only allow redirects to internal links or whitelisted sites. If you need to redirect to arbitrary sites an interstitial page might be necessary to make it absolutely clear that the user is being redirected to a third party.

You might think that your site is already checking that links redirected are only internal ones. However it’s crucial that you take care to check more than just validating that the url starts with a slash.

Check you’ve covered all eventualities

It’s possible to write a link as //foo.com and the scheme (http/https etc) will be inherited from the base URI. So if you’re on http://baz.com and there’s a link with an href attribute of //google.com this will resolve to http://google.com. It’s therefore important that any validation of redirect URLs covers this case or you could be caught out.

Note: If you’re interested this aspect of how URIs work is covered by examples given in rfc 3986

As an example http://has-open-redirect.com/login/?done=//google.com would redirect to http://google.com after login if vulnerable.

Why is any of this important?

Right now you’re probably thinking that there’s nothing behind the login to your site that a hacker would want.

However, have you stopped to consider that your users might also use the same username and password to login to their amazon account for example?

Lot’s of people will only have one username and password for every site they use (this infosecurity magazine article claims 46% of all UK adults us the same password). If it’s possible to phish accounts on a low profile site – the chances are there will come a point when the attacker will hit the jackpot and get access to every site that user frequents with same username and password.

Update: The GMail team has a nice post detailing some good tips for choosing a good password. Tip number one is don’t use the same password for all sites