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, 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.


Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.