Reverse engineering Facebook photo links; circumvents privacy settings | Hacker News Reader

Reverse engineering Facebook photo links; circumvents privacy settings

lightbluetouchpaper.org

82 pointsjjguy25 comments

Open articleView on HN

Change the "s" to an "n" of the image name in the URL and you can still view full versions of the pictures in question.

Take one of my photos for example:

http://photos-b.ll.facebook.com/photos-ll-snc1/v2339/95/113/...

to:

http://photos-b.ll.facebook.com/photos-ll-snc1/v2339/95/113/...

This would largely be applicable when profiles are deemed private and all you can do is view the small profile picture. In the grand scheme of things, it is minor but it should still be fixed.

Interestingly, a few years ago I discovered that you could also change the "t"/"s"/"n" (tiny/small/normal) to a "b" (big) and access the full-resolution image which was uploaded.

They seem to have discontinued the "b" prefix shortly after I found it (perhaps to save space?). It was a bit of a privacy concern that they retained the full-resolution image, considering that most users probably do not crop their images before uploading them.

I believe that, now, they resample the images prior to upload. Perhaps to save bandwidth as well.

Client side resample ? I would love to know how they do that. With AJAX it does not seem possible.

With Javascript (AJAX) it wouldn't be, but with a little Java or Flash it is. (I'm not 100% sure on Flash, but I bet it's possible)

I think Facebook uses Java for this bit (not totally sure, and I don't want to have to log in just to check)

Facebook uses the Aurigma Image Uploader, which is implemented both in Java and as an ActiveX control.

you can't access uploaded images in flash. you have to send the full image to a server, then re-download it, do your manipulation, and then upload the final version.

particularly annoying when uploading to S3, since you have to go client->server->client->server->S3.

Wow, I've just lost a great deal of respect for the programming skills of Facebook and its employees. This is really obvious stuff. I can understand a junior programmer missing something like this (or a non-junior one, everyone makes stupid mistakes sometimes) but surely someone should be checking?

I've just set up a similar system (non-public media served from a faster server without access checking) and the fact that the urls needed to be non-guessable was pretty damn obvious. The timeout thing is also really really obvious if you don't want people to be able to pass around a permanent link.

Whn I interviewed at Facebook I was kind of thrown back by the lack of engineering discipline. If I remember the quote accurately (this was about 1.5 years ago), they averaged 1 hour of downtime per subdomain (i.e. <college>.facebook.com) per week, which may or may not effect all users associated with that domain. To make scaling issues easier, race conditions are also all over. There is no data integrity of any sort. Some/all of these design decisions I could see being justified, because it is afterall just social profiles... but I was a little surprised. The weird thing is they release some really cool open source stuff and have some pretty great engineers there, so I'm not sure where this stems from.

There is an additional privacy "hack" that I noticed a few years ago. The surprising thing is that as of about a month ago the hack no longer works -- not because Facebook stopped it, but because your data on Facebook is now less secure by default, removing the need for the hack!

It used to be that when a friend was tagged in a photo album of a non-friend, you could only view those photos that your friend was in. By removing the "id=xxxxxx" from the URL, you could view ALL photos from the non-friend's album.

As of recently, you can now view ALL photos from any non-friend's album if a friend is tagged in only one of the photos (alleviating the need for the "hack")! Hence, for all their talk about privacy and their very complicated privacy settings, it seems that in some ways your Facebook data is becoming subtly less secure!

As someone said on the blog, the second link is actually pointing to: http://photos-c.ak.fbcdn.net/photos-ak-sf2p/v646/41/83/21013... and not to: http://photos-c.ak.fbcdn.net/n210132_34947682_4899.jpg as he says.

I don't think FB is too worried, honestly. I reported some security issues with photos through the API, and it took weeks/months for them to fix them.

Write a blog post and they'll probably take you more seriously :P

Silly me, I used the bug tracker. :\

I do think that fb's current approach makes sense when you want to share photos to people who are not on facebook, and that the marginal return from that being possible outweighs the "information leakage" of the current setup

Some of the techniques he discusses are for photos uploaded in Europe only.

Meaning that if you upload in the US you are a tiny bit safer.

This has been around. I remember discovering this when I wanted to share pictures found on facebook with others. A simple "View image location" and copy/paste and they could see it.

I remember finding this about videos too. Was going to try and work out the naming scheme, but never got round to it. Presumably it's a similar system.

In case anyone's wondering, OurDoings, doesn't have this vulnerability. You can share the link to one photo without exposing related photos.

Nobody was wondering. If you're going to advertise your company, just be transparent about it.

Look at my history. I've been talking about OurDoings here for years. If somebody wants to say every such comment should include a disclaimer I'll listen, but I won't be lectured on transparency from an account like izboyd created just for posting this one comment.

This vulnerability is an example of Facebook's failure to think things through. It does push my buttons and I'm going to say something. Just because it's popular doesn't mean it's good.

My issue with your comment is that you jumped on a /bug/ in Facebook to push your cause.

Analogy: Let's say I had a car company that competed with a fictitious competitor, Toyonda. There was a news story on HackerNews about a software bug that caused all Toyonda Freerunners to crash whenever somebody pushed the gas too long. I then posted a comment that my car, the Legendary Esquilax, doesn't have that bug. It's self-serving and adds nothing to the conversation.

Now, if you said something like, "Our Esquilax line of cars uses an O(1) lookup on the rotor hashtable to avoid a backup of 'gas' events which caused the bottleneck bug at the root of the Toyonda issue." That would be interesting, provide useful news about competing products, and potentially spark a discussion about the "right" gas pedal algorithms.

About your comment on lecturing: I signed up with Hacker News to post a comment. Every person needs an impetus to join a community, and your comment provided that for me.

Thanks for following up. I understand where you're coming from now. Unfortunately in this instance there's not a lot of potential for interesting discussion about the "right" way to form semi-private URLs on a host that isn't doing authentication. You need enough randomness; that's obvious. Apparently it wasn't obvious to Facebook.

PS Welcome to HN.

Yet another reason why nobody should be using facebook.

In any case we can't expect a website as big as facebook to implement encrypted urls which dynamically change with each user's session, which the session data server-side is used to decrypt and execute. Its not necessarily the best way to do things (like say ensuring the given user HAS permission to access the photo before serving it.)

O well I guess if the problem is too big for facebook, it must be too big for the rest of us. I am going to go to work tomorrow and rip it out of our application since this should not be a solvable problem.

epic fail

Reply on news.ycombinator.com