A quick security analysis of Facebook’s Album Privacy

Most social networking sites have privacy options which allow users to share photo albums with selected people or groups. Such features encourage end users to upload possibly compromising photos, for example photos of last night’s party. The idea is that it is acceptable to share certain photos with your friends, but not with your future employer. These same privacy features have previously been found to be insufficient and have been bypassed. For example, a year ago MySpace’s privacy features hit the news when a 17 gigabyte download was available containing thousands of photos obtained from MySpace which were supposed to be private. According to this report by Wired.com, these bugs had been abused by “self-described pedophiles and run-of-the-mill voyeurs” for quite a while.

So when I saw this blog post titled “Access any album on any Facebook profile” on the Security Ninja Blog, I decided to give this a quick look. In the blog post, Dave described how the privacy protection can be broken. He showed how he made use of a tool to launch a bruteforce attack and guessing a secret made up of 5 hexadecimal characters. A similar attack can be demonstrated by making use of  the HTTP Fuzzer in Acunetix WVS, and you can watch a demo of this feature being used to attack a similar case of weak authentication.

How does the Facebook attack work?

The album.php script on Facebook requires 3 parameters:

  1. “id” : this is the user’s id, which is publicly available and can be guessed by simply searching for that user
  2. “aid” : the album’s id – which is always -3 when the album is the public profile
  3. “l” : this is the secret

Therefore the only unknown ID to view the public profile is the “l” parameter. I will be referring to this parameter as the secret. While the album id (aid) is always -3 when the target album is a public profile, the album id for other albums is not so predictable. Non-public profile albums tend to have a long numeric id. During my brief research I saw album id’s which were 3 characters long, and others which were 6 or 7 characters long. So I decided to get a better idea of how the album id is generated. I created a new Facebook account and started adding new albums. The album id’s that were automatically generated were 2001832, 2001833, 2001834, 2001835, 2001836. Anyone will notice the sequence. Although a Facebook user who is not on the victim’s friends list cannot see what albums are available, public albums can be accessed if the album URL is known.This is intended behavior and the Facebook Help page has this to say about it:

“Please note that the “Everyone” privacy setting allows anyone on Facebook to view the album if they are linked to it.”

I did some more testing of my own…

So I created another Facebook user and started creating more albums. The id’s given to these albums were 2007969, 2007970 and so on. A very similar pattern but does not follow the sequence of the previous user. What I did next was to let some time pass and create yet another album. The id skipped a number, so that if the previous ID was 2007970, then the new one was 2007972. This behavior might indicate that Facebook uses time when generating new the album IDs or that some other user was assigned the album id 2007971 if album IDs are unique to the system. This seems to show that the album id (“aid” parameter) is easily guessable especially if one knows any particular album ID that is associated with the target user.

Facebook email feature

The Security Ninja blog post also mentioned that for an attacker to view all albums of the victim, the attacker would have to bruteforce both the album id and the secret (“l” parameter). This sounded too complex and a malicious user using this attack would have to generate tens of thousands of requests just to view an album. However by default, albums are public and one can assume that most users will have at least one public album and only set specific interesting albums as private. This means that by default, album URLs do not require the secret. Therefore what an attacker can do is locate a few public albums for a specific user to get a rough idea of the range of album IDs that are assocaited with the victim. This means that the attacker can limit the bruteforce attack to a much smaller number of album IDs.

I also decided to take a look at the secret (“l” parameter) and get an idea of how it is generated. This parameter is normally used when someone shares an album with privacy settings with a non-facebook user by sending the other user an email or an instant message with the link. During the testing I noticed that the secret is static unique for each private album. This means that each private album is directly associated with the secret. When the album privacy settings change, the secret remains the same. If this secret is generated based on some public property of the album (for example, the album id and user id), then an attacker may generate a large number of albums and analyze the resulting secrets to find out how they are generated. At this stage I do not know if this is the case, but would be interested in hearing other people’s input.

My conclusions:

  1. Even if the attacker is not within the social network of the victim, the album id is susceptible to bruteforce and the attacker can then view victim’s public albums
  2. Since album ids follow a certain pattern, an attacker may be able to target a range of album IDs to find out the secret and gain access to these private albums

Public albums should be treated as public and the secret is not much of a protection; my suggestion is to avoid uploading photos that might embarass you. Unfortunately, as with many other free services, end users cannot do much to protect themselves other than not sharing compromising content. By their nature, social networking sites tend to be open and the idea is to share information. Therefore it is likely that we will keep seeing similar issues in Facebook and other social networking sites.



  • Hi Sandro,

    I’m glad my work has inspired further research into this area. I agree with what you were saying about brute forcing the aid and l parameters, that would be a huge amount of requests.

    Perhaps I’m not reading your work correctly but on my own profile the l= value is different for each one of my private photo albums. I had seen this behaviour with all of the tests I carried out, that value seemed to be different for each album whether it was multiple albums from a single user or albums from different users. I wouldn’t have thought the logic behind the values is complex, its too small to be complicated 🙂

    I agree with your thinking behind the aid value, I’m almost certain that these just increment by one for every album across all Facebook users like you have stated.

    I look forward to seeing what other people are going to look into following on from my findings.


  • Hi Dave .. thanks for the comments!

    Yes the secret is different for each album. I corrected the post to reflect this because “the secret is static for each private album” has a different meaning (as you pointed out) from what I had in mind. What I meant to say was that if you have an album that is private, and you change the permissions to public then back to private, the secret remains the same. I think this means one of two things: either that the secret is generated based on some other static information, or that the secret is generated when an album is created and simply hidden or displayed depending on the album permissions.

    Hope that I’m more clear this time 🙂

  • Comments are closed.