Facebook's security hole?
Thursday, February 12, 2009
Serving dynamic content on the web is tricky. In the end, all the content needs to be stored somewhere and needs to be rendered as web pages. In the case of Facebook, there are gigabytes of data stored in a large number of servers. Of course, all of the data is secure...Or is it?
When you create a Facebook profile, you are "guaranteed" a secured area for your content. Note that I put guaranteed in quotes, because not all of your content is password protected--at least, it isn't right now. For example, this
picture of one of my drawings is accessible without you having to enter your Facebook id and password.
This is obviously a problem or an oversight. More important, if you play around with the URL, you can get different images. Check this out:
http://photos-a.ak.fbcdn.net/photos-ak-sf2p/d357/239/43/507502334/.
I don't know this guy, and it's likely that he doesn't want us to be looking at his "private" picture, but here it is available without a Facebook id and password.
This is what the images look like right now:
me;
dude I don't know.
Is this really a problem? The answers can be left to interpretation, and some could say yes and some could say no. I'm on the side of this actually being a security hole.
The problem is that images in Facebook pages live locally in web servers that are accessed as follows:
<img src=/mydir/myimage.jpg>Nothing surprising with this code: we have a directory and an image on some computer.
This code is how secure Facebook pages load images. Mind you that they have all those crazy numbers in the directory and image names, but it's the same thing: a link to a static file somewhere.
So the question is, then, what is secured and what is not secured in a Facebook session?
In the case of a Facebook page, the content is secure but the image is not. You could argue that the image is secure because the HTML that renders the page is password protected and there is no way for anyone to guess the location of the image. This is nonsense, of course, because if I copy the link of the image and provide it to anyone without a Facebook account he or she can see the image. This is hardly secure.
Schematically, this is what a page currently looks like:
If this is a problem, is there a solution? Yes, actually. What Facebook could do is to stream the images via some proxy process (a streaming program). This way, users don't know where the image is and the image would only be displayed if users are authenticated. A high level view of the solution looks like:
The issue with this solution is that this is CPU intensive, because we are adding one more layer on top of HTTP to serve the image. HTTP servers are optimized to serve static content, but once you add something in the middle of the browser and the server, this something will require CPU cycles and memory. With thousands of concurrent users, this is a
big problem. Not a new problem, but a problem nonetheless.
Another feasible solution for Facebook is to modify the HTTP server itself to handle pages serving secure images that are within the context of a session. This is not hard, but it adds more complexity to the overall architecture. I'd probably consider this as option B, as creating a streaming process a trivial programming exercise.
Finally, the last solution I can think of involves configuring web servers so that any requests that are not originated from facebook.com will be considered invalid.
Regardless of what you and I think about this, the "hole" needs to be fixed. It strikes directly to the core software engineering concept of abstraction and hidden implementation.
Comments: