Opening Open Redirects

A few years ago, when FogMarks was not even a tiny idea or a vision in my head, I used to do casual programming jobs on Fiverr.

One of the jobs/gigs I was asked to do is to cause a user in site x.com to be redirected to Facebook.com and then, without an action from his side, to be redirected to a y.com site. I didn’t realize back then why would someone want that kind of thing. Why not just simply redirect the user directly to y.com?
I asked the person why would he want to do such a thing. His answer changed the way I (and after that, FogMarks) treated and took care of Open Redirects. He answered that by forcing a user request to originate from a Facebook URL, the ads engines on y.com are paying much, much more, because a popular site like Facebook has redirected the user to y.com.

Until this answer I treated open redirects as simple security issues, that can’t cause too much damage. I knew that innocent user could get a misleading link like: “www.innocent.com?redirect_out=bad.com”, but I believed that anyone with a tiny bit of common sense will detect such things. Those kind of attacks were mostly used by Phishing web sites to try and simulate that an evil page is actually hosted by the innocent domain (and in this case- of innocent.com).

After this long introduction, I want to introduce today’s topic — a simple solution to open redirects. Facebook did it in their Linkshim system, but I want to introduce a much simpler solution that any of you can use.

Side Note: Who should not adopt this solution? Websites who want their domain to be present on the Referrer header.

Well, the regular ways I have seen to prevent open redirects are creating a token (like YouTube’s and Facebook’s l.php page), forbidding URLs that don’t not contain the host of the website and allowing a user to be redirected only from a POST request.

While creating an exit token is a considered a good practice, handling and taking care of this whole system is pretty much of a headache. You have more values to store in the DB, you should check for expiration times, IP addresses and much more.

Another approach is to forbid redirection to URLs that don’t not contain the host of the website. It is simply wrong. Websites should allow other users to be redirected to another websites, not only to pages within themselves.

Allowing user to be redirected only after an action she initiated (like a click on a button), isn’t always that convenient — to you or to the user.

The Golden Solution

Honestly, the first thing you’ll about to say is: “What? Is this guy crazy?”. But the next thing will be: “Okay, I should give that a try”.

Well, a lot of websites today offers a free URL shortening services. In addition to that — they offer a free modular & convenient API.
Why don’t we use them?!

Instead of carefully creating an exit token, forbidding outside redirects or requiring them to be initiated POSTly (yes, I have invented this verb!), simply translate any outside URL to a shortened URL that a certain URL-Shortening service provides. If you don’t want third party services to store your information, you can build one of your’e own using an open source system.
Allow redirection only to the domain of the shortened URL.
That way you won’t have to worry about open redirects — they will never occur directly from your domain.

Lets say you have a page called ‘redirect_out.php’ with an r GET parameter that a user can control:

www.my.com/redirect_out.php?r=http://bad.com

Normally, you should also include a token in this request, and a mechanism to validate its origin and expiration time.
I say- accept the bad.com URL from the user, and automatically translate it to a shorte.nd/XxXxX URL. Then always allow redirection to shorte.nd. A lot of the shortening services follow security guidelines and will deny redirection to ‘bad websites’, better than you will. Trust me.

If you want to strengthen up this method even more, you can add a whitelist to the shortening service, and configure it to direct requests only to a host which is in the whitelist.

Extra: Benefits of using a well known shortening service

As mentioned before, this solution was offered only to developers who don’t want their domain to be shown up as the referrer. If your’e worried about direct Phishing attacks, it’s a different scenario.

By using a well known shortening service which manages a black or a white list of known “good or bad” domains you’ll earn twice:

  • Your’e domain will not be the ‘one to blame’ who redirected users to ‘bad’ websites (yes, Google knows and checks that too), although you should really care about it too.
  • You’ll increase the phishing protection level of your web. Your users will be able to be redirected to ‘bad’ web sites, but the shortening service will deny it, or at least warn those users (and optionally you too).

Wrap up

This idea may sound a bit bizarre at the beginning, but it requires zero development time (when choosing to use a commercial service). The main idea here is to acknowledge that unwanted redirection of a user from one site to another can occur, and the best way to prevent the worst thing that could happen (that the user will arrive to bad.com) will be to rely on a mechanism to

Let me know your opinion on that.

Comments are closed.