This vulnerability enables anyone to get some basic information (mainly just name, and uploader/author’s ID for photos and posts with a specific condition) from any post, photo, page or group regardless of its privacy setting, or type (published state for pages / visibility for groups).

All these information results from the dialog title and full URL for a given Facebook object (e.g. a post or photo) in an AJAX script at https://www.facebook.com/ajax/pages/show_tab_permalink.php?page_id=...&app_id=...&__a. Originally, the script is for page admin to get the full URL for an app installed in a page. The script takes two essential parameters, page_id and app_id, which apparently indicate the IDs for a page and an app. The HTML content in the response is a dialog with a title (“Link to the A for B”, with A for the app name and B for the page name) and a full absolute URL for the app in the page.

Perhaps, if you are a hacker like me, you would immediately try an ID of an unpublished page and app in sandbox mode. Luckily, it works. It reveals nothing more than the name and the page address of the page and app regardless of their type and visibility. In the first place, I reported this to Facebook and waited for their reply.

At that time, I had underestimated the vulnerability; afterward I kept trying plugging in different ID to the URL. Surprisingly, the page_id parameter name is totally misleading because it accepts other Facebook objects as well. Here comes to the conclusion of the possibilities of page_id value and the result.

1. Page ID
Reveal the name of a page regardless of its published state and whether you are an admin of the page or not.

2. Group ID
Reveal the name of a group regardless of its visibility state (secret group) and whether you are in the group or not.

3. Photo ID (fbid in photo URL)
Reveal the uploader’s ID of a photo regardless of its privacy setting as long as it is not deleted.

Practical usage: When you get a Facebook static image URL (the one starting with “fbcdn-sphotos” and ending with “.jpg“), you could extract the fbid from it. The full URL of a photo reveals the album ID containing its uploader’s ID.

Uploader’s ID no longer presents in static photo URL since mid 2012.

4. Post ID (the post must share something, whatever URL or other’s post)
Reveal the author’s ID of a post that shares something regardless of its privacy setting.
For unknown reasons, the dialog title and content both contain the author’s ID.

The vulnerability is now fixed by only allowing IDs of published pages and apps not in sandbox.

21 Dec 2013 – Reported to Facebook
23 Dec 2013 – Acknowledgement of report
6 Jan 2014 – Sent POC video to Facebook
11 Jan 2014 – Vulnerability fixed

Facebook responded that this vulnerability was reported before by someone else and it is now fixed.

This is a CSRF vulnerability that enables anyone to generate a URL to accept an invitation of being a page admin (or any other admin role). Undoubtedly, this is not really a big deal but still a problem.

For example, I am an admin of a page and send an invitation to a user with known email address. An email will then be sent to the recipient’s mailbox to tell him or her to accept/decline the invitation. However, the sender (me in this case) could generate a URL that makes the recipient accept the invitation without any confirmation or security code required. Normally, fb_dstg parameter is required to prevent such kind of CSRF attacks but this is not applicable in this case. The URL looks like:

https://www.facebook.com/pages/admin/invite?page_id=PAGE_ID&action=accept&sender_id=MY_ID&recipient_id=TARGET_ID&admin_type=0&email=TARGET_EMAIL

As long as the recipient triggers the URL above (like through an image or script tag, or direct click), the recipient accepts the invitation automatically.

1 Dec 2013 – Reported to Facebook
3 Dec 2013 – Notified of duplicated report

This vulnerability allows anyone to get the sharing URL from any post which can even be the one you cannot access due to its privacy setting. But it only reveals the sharing URL, not the content or author of the post.

The hack is pretty simple. It takes place in the share script on the mobile platform.

https://m.facebook.com/sharer.php?sid=...

The script can take a parameter called “sid” indicating ID of the sharing object. The sid value will be used in POST content when sharing the post. It can be set to ID of any post that shares a URL (not applicable to sharing a post or other Facebook items with this vulnerability) and the post, surprisingly, could still be shared successfully afterward. Eventually, the sharing URL in the post with a known post ID is then revealed.

5 Aug 2013 – Reported to Facebook
12 Aug 2013 – Acknowledgement of report
1 Nov 2013 – Vulnerability fixed