How mobile phone users stumbled into other people's FaceBook account

AP is reporting: "Network flaw causes scary Web error":

A Georgia mother and her two daughters logged onto Facebook from mobile phones last weekend and wound up in a startling place: strangers' accounts with full access to troves of private information.

The glitch -- the result of a routing problem at the family's wireless carrier, AT&T -- revealed a little known security flaw with far reaching implications for everyone on the Internet, not just Facebook users.

True. Most internet sites that do not use secure login (https) may be vulnerable until AT&T fixes their problem. Boston Globe readers are reporting that they faced the same problem as far back in 2007, on carriers other than ATT Wireless.

As an aside, I had to laugh after reading this line in the AP article:

In each case, the Internet lost track of who was who, putting the women into the wrong accounts.

Reminds me of this AOL helpdesk gem: "This is not an AOL problem. Have
you tried calling the Internet's support department?"

To understand how this could have happened, lets take a look at how a website knows who is who once they log in. Of course, they could just have your username added to each page request. But then anyone who knew your username would be able to impersonate you. One popular mechanism is using session cookies. Here is a very simplified description:
HTTP is stateless (meaning the web server has no memory of who you are or what you just did), so the server has no way of keeping track of the users who logged in (and tying them to a specific browser).

Once a user logs in, a cookie is set with a lifetime (say, 15 minutes), and this cookie and matching userid is stored somewhere, preferably a database. It is typically a long and random string like xyn29f071bca9bf7f85da28205439fc3, so someone can not just guess it.

Every time the user tries to go to a protected page, the server reads the cookie from the browser, looks up the username that matches the cookie, and allows (or disallows) access. The cookie is also updated with each request (lifetime extended by 15 minutes). If no request is made, the cookie expires, and user gets logged out for inactivity. If the user chooses to log out or in the previous case gets logged out due to idle timeout, his/her cookie is deleted on the server, so they can not access protected pages any more.

So, if for some reason Alice gets Bob's cookie (before Bob logs out), the server will think Alice is Bob, look up pages that Bob has access to, and bada bing!--Alice will be looking at Bob's pages.

Now the million dollar question is, how would Alice get access to Bob's Facebook session cookies? Stealing session-cookies is a well-known attack; people have demonstrated this on multiple sites including Google Spreadsheets, and bad guys have used this to compromise accounts. But we can be pretty sure in this case the person who experienced this wasn't doing any such attack. So what happened?

Here we enter the murky territory of speculation. We know that AT&T is worried about the amount of data usage by it's wireless customers because their network can't keep up. So is it possible they used HTTP pipelining to improve performance?

Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.

HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.

What I think happened was: ATT's web proxy uses pipelining. User A and User B where both trying to log onto Facebook at the same time. When the responses came back it messed up the order, and sent the response destined for User A to User B's browser, thus giving her access to User A's facebook page.

PS: Where did the response meant for User B go? To user A? To yet another person who has not come forward yet? To User B's browser, which then discarded it because it thought it already got a response to its original request? To the bit-bucket? Who knows.