Party Crashers

Are you following FogMarks?

In what way do you interact with private information of your users? I’m intending to information like their full name, email address, living address, phone number or any other kind of information that may be important to them.

Today’s case-study talks just about that. We will talk about the way private elements (and I’ll explain my interpretation of the term ‘elements’ later) should be handled, and then we will see 2 neat examples from vulnerabilities I have found on Facebook (and were fixed, of course).

OK, so you’re mature enough to ask your users to trust you with their email address, home address and phone number. If you are smart, you’ll know that this type of information should be transmitted on the wire via HTTPS, but you’ll remember that sometimes it is also a good practice to encrypt it by yourself.

So your users info is properly transmitted and saved in the database, the DB is immune to SQL injections or other leakage incidents, and you are thinking of cracking a beer and starting another episode of How I Met Your Mother.
Awesome! But first, I’d like to introduce you to another enemy: IDOR.

Insecure Direct Object References are your information’s second-worst enemy (after SQLi, of course). Attacker who is able to access other users private elements (such as email address, phone number, etc) basically could expose all of the private data from the server, without “talking” with the DB directly.

This is the time to explain my definition to private elements. User elements are not just the user’s phone number, email address, name, gender, sexual-orientation or favorite side of the bed. They are also elements that the user creates or own, like the items in the user’s cart, a group that the user owns or a paint that a user makes.

The best way to handle private elements is to define them as private and treat them with honor.

If you know that only a certain user (or users) should be able to access a certain element, make sure that only those users IDs (or other identifier) are able to access and fetch the element.

How will you do so?

Using a private elements manager of course.
The idea is simple: A one-and-only mechanism that is fetching information about private events only if an accepted identifier is being provided (for example, a class that will return the email address of the user ID ‘212’ only if the ID of the user who requested that information is ‘212’).

By sticking to this logic you’ll enforce a strong policy that will make all of the APIs to interact the same way with the private elements.

Let’s look at an actual scenario

Our good friends at Facebook apparently forgot to change their logic on their old mbasic site (mbasic.facebook.com).

I have found 2 vulnerabilities which allowed the name of a private (secret) group or event to be disclosed to any user, regardless the fact that he is not invited or in the group/event. The first vulnerability is here by presented, but the second one is yet to be fully patched (it is in progress these days):

Now getting that secret party’s location doesn’t sound so hard, hah?!

Cheers!