Facebook announced this morning that between 50 and 90 million accounts have been breached due to unnamed hackers stealing the access tokens of other users:
“…ATTACKERS EXPLOITED A VULNERABILITY IN FACEBOOK’S CODE THAT IMPACTED “VIEW AS”, A FEATURE THAT LETS PEOPLE SEE WHAT THEIR OWN PROFILE LOOKS LIKE TO SOMEONE ELSE. THIS ALLOWED THEM TO STEAL FACEBOOK ACCESS TOKENS WHICH THEY COULD THEN USE TO TAKE OVER PEOPLE’S ACCOUNTS.”
For those who don’t know, “access tokens” (also called “session tokens”) refer to something saved on your computer to let the web application know who you are, and that you are logged in. It’s what enabled you to stay logged in on website without having to enter your password every time. Most commonly, these are “cookies”, but there are many types of access tokens.
If an attacker is able to take your access-token and add it to their browser, the web application will think their browser is logged in as you.
What appears to have happened is that hackers used the “view as” feature, a bug in Facebook would sometimes make the video uploader appear. This video uploader came with an access token, that the attacker was able to steal.
This specific breach was complicated, in that it involved various systems working together, so there is not likely a simple fix that will prevent this sort of breach in your organization — rather, this breach can be viewed as multiple security-points failing at once.
However, there are a few best practices to be aware of that will help.
Securing your application at multiple levels is called defense in depth. Defense in depth refers to the concept of having multiple layers of defense within an application or network. There is no single implementation of defense in depth — the important point is that your application has security involved at every step, so when one part breaks, the others can carry the weight.
Never send restricted data without re-authenticating the user
Banks and most large e-commerce websites do this already — when you make a purchase or transfer, the application asks you to reverify your credentials. This wouldn’t stop an attacker from stealing your personal data, but would prevent them from doing anything more disastrous with your account.
However, access-tokens count as “restricted data”. The server should only send you your access token when you provide a password (i.e. login). It should never be re-sent (and in fact, the server shouldn’t even have the ability to resend it). Any time an access token is revealed in the response, it should both a) be a new token, and b) require re-authenticating.
I don’t want to comment too much on Facebook’s architecture without knowing their internals, but if their video uploader did expose the access token in the first place, then the “bug” that the hackers exploited wouldn’t have been able to go anywhere.
Keeping cookie expiration times as low as possible
All session tokens (should) come with an expiration date, at which point the server will no longer accept them. At WhiteHat, we recommend an expiration of 24 hours or less (we use 12 hours in house!). If your organization happens to get breached in a method similar to Facebook, the damage would be limited only to users who logged in within the last 24 hours (or whatever you set your expiration to).
Make sure you have a prominent logout button (that works)
This may seem surprising, but we often come across web applications that either don’t have a logout button at all, or they do, but it only deletes the auth-token on the user’s computer instead of invalidating it on the server.
Just deleting the token on the user’s computer leaves them defenseless in the situation that their tokens were stolen.