REALLY FUNNY PICTURES?

Are Facebook pictures really private and are they hosted on Facebook servers?

• EDIT: The last paragraph was added ~24 hours after the post was first published I am adding this question as a suggestion from . Thanks for offering to invite someone from the images team to answer. A few weeks ago, I noticed that Facebook stores images on a domain which is not under facebook . com. Further investigation revealed that there is no authentication to view this URL. Which really means that all pictures are public (I use public VERY loosely). To elaborate, you don't really need to be authorized (or even authenticated )into facebook to view ANY picture. Obviously, this made me even more interested and I investigated further. Here is an example: The picture below, is a screenshot of my windows 8 experiment, which is set to be visible to "My Friends" (https://www.facebook.com/photo.php?fbid=10152213398405361&set=a.10150432494480361.626183.832245360&type=3&theater). On closer inspection of the source, I noticed that the image is actually stored here (I am not sure how to keep the URL, it keeps getting replaced  by the image): . Notice that this picture is public and accessible to you (which is scary, unless you are my friend on Facebook). So, two interesting things: 1. The URL is under the domain on akamaihd . net. This means, FB does not really store it on it's servers (this is Chris's response which partially explains the akamai situation: ). 2. More importantly, you don't need to be authenticated to view private pictures. This is scary because "if" a user has access to this akamai URL, he/she can view the picture irrespective of their authorization level. so, does #2 mean that all FB pictures are "public"? Not quite. It is very hard to guess the file name (such as https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-ash3/664843_10152213398405361_313988370_o.jpg). I submitted this information as a Facebook security issue on their Whitehat page. I received a prompt (yet brief) response which read "Not a bug, this is how our and every cdn works." There was another response too, but it eluded to the same point. So, the "privacy" of a given picture is directly proportional to the difficulty in guessing the magic file name (such as https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-ash3/664843_10152213398405361_313988370_o.jpg). Let's break this down : Every picture I looked up has a "fbid". This parameter is a part of the facebook image URL (in this case, https://www.facebook.com/photo.php?fbid=10152213398405361&set=a.10150432494480361.626183.832245360&type=3&theater)  Notice that this "fbid" is also embedded in the "image name" in the Akamai URL. So, let's assume a friend of mine (say A") who has access to the above picture forwards the Facebook URL of the image to a friend of his (say "B") who is not a friend of mine. Now, "B" has the URL of the image, but cannot actually "view" the image. However, he now knows the "fbid". This makes it mathematically easier to guess the rest of the file name. The fact that there appears to be no authentication or throttle control on the Akamai CDN site means "B" has unlimited guesses to get the correct file name and access the image (which I repeat, is improbable, not impossible). So, my questions: 1. Does Facebook still use Akamai and/or other vendors to store user pictures (it appears so)? 2. Is there ANY plan to restrict access to these CDN URLs? Some implementation similar to SAML would be useful. It is scary that  all I need is a URL (which could be leaked in various ways such as web proxies and other cache's on the user's computer or network) to view ANY picture. 3. Is "everybody else does it this way" a valid response for a company as big and popular as Facebook? Disclaimer 1: In my last communication with FB Security, I asked them if it is OK to make this information public since they do not think it's a bug. This email was sent on April 30th 2013. I have not received a response about this specific question. If Facebook changes it's mind and thinks this is a security issue, I would be glad to take this post down. Disclaimer 2: It is not simple to write a script to generate valid file names. While I have not had the time to perform cryptanalysis or write scripts, the sheer length of the file-names helps FBs case (it does not however help that only numbers are used). Disclaimer 3: A week or two after I found this, I looked and found a YCombinator thread talking about something similar way before I found this. The situation does not seem to have changed since then. (https://news.ycombinator.com/item?id=1739243) EDIT: To address some of the questions below, in the security world this kind of an issue is commonly called "Insecure direct object reference" (https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References) . To be honest, this is a more complex case of DOR. To reiterate, just the fact that images are stored on a different server is not a major issue (may be some kind of legal concern, I don't know).. the issue here is that the image can be accessed without any authentication

• Answer:

  Thanks for asking this question.  Our whitehat queue gets so many questions that sometimes we don't explain in enough detail.  Hopefully this discussion can help serve as an FAQ. Those additional portions of the image url you mention *are* the authentication for the image.  They don't authenticate you but instead authenticate that the url was originally served from Facebook where it was subject to privacy checks.  Privacy checks on Facebook only serve the full image url to people you've specified. Essentially, the facebook.com portion of the site uses an http://en.wikipedia.org/wiki/Access_control_list security model while the CDN portion of the site uses a http://en.wikipedia.org/wiki/Capability-based_security model.  Once your friends have the photo, they can save a copy of the photo itself and share that or share the full image url with others -- the two are equivalent for most purposes.  I trust my friends to do reasonable things. You're right that sometimes one of your friends might inadvertently leak the photo fbid without leaking the full image url (e.g., forwarding the page (not image) url not realizing the recipient cannot see the photo).  Even with the photo fbid, you have to brute force the remaining portion of the url.  That remaining portion has 2**45 combinations that needs to be guessed correctly (that's 35,184,372,088,832 possible values).  In the far more common case where someone hasn't leaked the photo fbid, there's many, many more combinations (the photo fbid is a 64-bit number, but because it's not totally random, it adds less than 64 bits of randomness).  Also, we just finished a major data migration, so that third field will soon be 63 bits on new photos rather than 31. Insecure networks and proxies are important but orthogonal to this question about CDN urls.  It's definitely worth verifying that you're using https to avoid insecure networks.  Most Facebook users are using https, but you can check your "Secure Browsing" settings at https://www.facebook.com/settings?tab=security&section=browsing&view So why use Akamai or a CDN at all?  Why not just serve photos directly from Facebook's servers where they're stored?  CDN caches are installed in ISPs' networks close to you so the bandwidth stays local to your ISP and you get the content faster.  ISPs can't handle installing separate servers for every popular web site. Instead, they just work with a handful of well-known CDN providers -- and occasionally big companies building their own CDNs.