Should We Blame The Diet Coke Smuggler?


Everyone use user-controlled parameters. This is, as far as I concerned, the easiest way to create an effective http negotiation process. It means that in order to ease the interaction process between the site and the user, the site allows the user to tell him about essentials parameters that are needed for the next interaction. Even while this post is being written, after I’ll click ‘Publish’ a lot of POST parameters will be sent to the server and will be processed.

As you might have already guessed, today’s case-study will highlight the huge disadvantage of allowing users to ‘tell you what to do’.

Basically, I don’t believe in POST or GET. I know its sound funny or stupid, but when I see that so many security breaches were launched using a GET or a POST requests, I cannot live with that comfortably. I know that GET and POST are ‘just the messenger’ and it will be like blaming an innocent person who was used to smuggle diet Coke into a movie theater.

But I think that we all forgot one important thing – GET and POST are not alone. HTTP, especially on its latest version (and the next version) supports other request types. Like what? PUT, DELETE, OPTIONS. Those requests were made for a reason, and almost none of the latest players on the dev market are using them. Why? Because its not easy, and its not ‘widely used’. That idiotic term I heard a few days ago on a developer conference I participated. People kept explaining that a certain technology should not be used because “it is not widely used, and therefore there is not enough support or security research and maintenance”. And again – why exactly shouldn’t I use a unique software that no one else does? Why should I count on our security community to alert me whenever a software I’m using is breached?

As for HTTP requests, GET and POST are what I call ‘deprecated’. Too much companies and too much software use GET and POST requests with dozens of parameters to ‘get things done’. This is exactly the reason why XSSes vulnerabilities, along with IDORs and CSRFs, are being successfully executed – Websites use too much parameters and the developers, at some point, aren’t able to track the software’s behavior under certain conditions – from a general use by a client to an aggressive security research by professionals. That’s just the way it is. Another reason for security breaches is that websites count that the user will return them the parameters they expect, and if the user returns only a few parameters, some server side actions that are being executed by the missing parameters are not being executed, resulting in a security vulnerability.

Now, should we cry and bury GET and POST? No, of course that there is a way to keep using GET and POST and still be safe. All you have to do is to not blame the diet Coke smuggler, and to follow these 5 rules:

  1. Minimize the number of parameters that are being used. More parameters = more security breaches possibilities.
  2. Know exactly the purpose of each parameter.
  3. Know exactly what type of data each parameter should hold.
  4. Know what happens when each parameter is given the wrong type of data, or is MIA.
  5. And the most important thing – use all of the parameters! I can’t count the number of times a security breach was successfully launched because of a lack of using all the parameters. In fact, I’m writing these days another case-study about a Facebook security vulnerability just about that.

As for a finish, I’ll just drop this tiny note: FogMarks is looking nowdays for some new challenges. If you think you can interest us with something, simply DM us on Twitter (and make sure your’e following us) or send us an email on contact@fogmarks.com.

Open Redirects – Ups and Downs


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 the kind of thing. Why not simple redirecting 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 come from a Facebook URL, the ads engines on y.com are paying much, much more, because a popular site like Facebook is redirecting users to y.com.

Until this answer I treated open redirects as simple security issues, that can’t hurt that much. I know that innocent user can get a link of the type: innocent.com?redirect_out=bad.com, but I believed that anyone with a little common sense will see such things going on. Those kind of attacks are mostly being used by Phishing web sites, to try and simulate the domain of innocent.com.

After this long introduction, I want to introduce today’s topic – the 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.

Quick 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 (YouTube, 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 good practice, handling and taking care of this whole system is pretty much of a headache. You have more values to store at the DB, you should check for expiration times, IP address and a lot more.

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

And allowing user to be redirected only after he clicks on a button, for example, 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? This guys is 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 use them?!

Instead of carefully creating an exit token, forbidding outside redirects or requiring POST, simply translate any outside URL to a shortened URL that a certain service provides. If you don’t want third party services to store your information, you build one of your’e own using an open source system.

That way – you won’t have to worry about open redirects – they won’t be occur from your domain.

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

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

Accept the bad.com URL from the user, automatically translate it to a shorte.nd/XxXxX URL and then allow redirection.

Extra: Benefits of using a well known shortening service
As mentioned before, this solution is offered only to developer who don’t want their domain to be shown up as the referrer. If your worried about phising attacks, its a different scenario. Although by using a well known shortening service which manages a black list of known “bad domains” you’ll earn twice:

  • Your’e domain will not be the one who redirected users to ‘bad’ websites (yes, Google knows and checks that 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 potentially you).