Facebook exploit– Verify website site visitor identities

Short variation: I found a bug that would let any type of website determine a logged in FB individual by validating their ID. Facebook dealt with in 6-9 months and also compensated a $1000 bounty.

In ins 2015 coverage of the Facebook/ Cambridge Analytica privacy problems, Mark Zuckerberg was asked to indicate prior to Congress, and among the questions they asked was around whether Facebook can track customers also on other sites. There was a whole lot of news protection around this aspect of Facebook, as well as a great deal of people were up in arms. As one element of their response, Facebook introduced a Data Abuse Bounty, with the objective of protecting customer information from abuse.

So, having just recently located a bug in Google’s internet search engine, I laid out to see whetherIcould track or determine Facebook individuals when they got on various other websites. After a couple of incorrect starts, I managed to find a pest whichpermits me to recognize whether a visitor is visited to aspecificFacebookaccount, and also can examine hundreds of identities per 2nd (in the series of 500 p/s).

I have produced an evidence of idea of the assault (now fixed), which checks both a little known checklist of IDs but additionally permits you to enter an ID and also it will confirm whether you are visited to that account or otherwise.


Facebook has a great deal of backend endpoints which are utilized for numerous AJAX demands throughout the site. They are nearly all are protected byaccess-control-allow-originheaders and also magic prefixes on JSON feedbacks that stop JSON hijacking as well as other unpleasant strikes.

I browsed across the site looking for any kind of endpoints that really did not have these protections and also which did pass my individual id in the URL, seeking any type of way I may be able to parse an action from Facebook to confirm whether the UID in the LINK was correct.

I also tried to find any kind of images that include the individual ID in the LINK and also act in a different way when the UID matches the visited user (so I could do something comparable to this method, however, for particular IDs); the closest I obtained was a photo that did behave in a different way however the LINK likewise consisted of Facebook’s well recognizedfb_dtsgparameter that is one-of-a-kind for individuals (as well as transforms consistently) which prevented it being abused.

In addition I looked for any kind of 301/302 s in these URLs which may represent an opportunity to reroute to an image in a style would enable the very same trick as above.

After very carefully checking lots of these endpoints I eventually located one that had a slight variance in exactly how it behaved which was a little void yet stood for a weak point; it did have anaccess-control-allow-originheader, but it just consisted of a magic prefix when the customer ID (in the__ customerLINK parameter) didn’t match, not when it did match. When the individual ID provided in the URL did match the feedback was pure JSON.

Nevertheless, as a result of the peskyaccess-control-allow-originheader, I could not call this by means of an XHR request as the browser would certainly obstruct it. At this moment I believed it might be an additional dead end, however I ultimately realised what I can do is use it as thesrcfor a regularblock; this would naturally stop working however importantly it falls short differently in both the cases (due likewise to thecontent-typeheader), and also in such a style that this can be detected usingonloadand alsoonerroroccasion trainers.

Here is an example of the URL for the endpoint:

https://www.facebook.com/ajax/pagelet/generic.php/TimelineEntStoryActivityLogPagelet?dpr=2&ajaxpipe=1&ajaxpipe_token=AXjeDM6DZ_aiAeG-&no_script_path=1&data={%22 year%22:2017,%22 month%22:9,%22 log_filter%22:%22 surprise%22,%22 profile_id%22:1159016196} & __ user=XXXXXXXXXXXX & __ a=1 & __ dyn=7AgNe-4amaxx2u7aJGeFxqeCwKyWzEy4aheC267 UqwWhE98 nwgU6C4UKK9wPGi2uUG4XzEeUK3uczobrzoeonVUkz8nxm1typ8S2m4pU5LxqrUGcwBx-1-wODBwzg7Gu4pHxx0MxK1Iz8d8vy8yeyES3m6ogUKexeEgy9EhxO2qfyZ1zx69 wyQF8uhm3Ch4yEiyocUiVk48 a8ky89 kdGFUS & __ req=fetchstream_8 & __ be=1 & __ pc=PHASED:DEFAULT & __ rev=-LRB- ********************************) & __ spin_r=-LRB- ********************************) & __ spin_b=trunk & __ spin_t=-LRB- ******************************) & __ adt=8 & ajaxpipe_fetch_stream=1

I was then able to craft a basic Javascript script that would take a list of individual IDs as well as generate many script tags with callbacks to establish success or failure. Because the endpoint is HTTP2 it likewise indicates you can have much of these requests in trip at when, that makes inspecting versus large listings of IDs really quick. I did a little test below and also had the ability to test 400-500 customer IDs per secondly; if this was carried out in the background on a regular web page that an individual got on momentarily it would be feasible to inspect thousands of IDs. There really did not seem to be any type of type of rate restricting on this endpoint.


I have actually developed a tiny demo which shows the assault. It examines a little list of well-known user IDs instantly when you arrive on the page, as well as additionally allows you to enter an ID on the page and will certainly validate whether you are logged in to that account.


This is limited because you require to be checking against a well-known listing of customers, instead than simply being able to figure out the customer’s identification instantly. Nonetheless, anyone impacted by the Cambridge Analytica data circumstance whose data is currently understood, they would now have the ability to be identified and also tracked across internet sites even without using any kind of Facebook APIs.

In addition, one of the most threatening exploiters (e.g. a repressive regimen) of such a bug would likely have a checklist of individuals they appreciated determining (which they could also narrow down based upon your place and also various other factors). A final example might be any individual on a corporate IP address or network, where the list of individuals is probably fair simple to harvest as well as is fairly limited.

So the scope is rather slim, the effect on numerous may be small, however, for some that effect could be high. This would certainly be an offense of personal privacy for any Facebook customer who did get identified.

Disclosure Timeline

  • 20 th April 2018– I filed the initial bug report.
  • 20 th April 2018– Facebook responded allowing me understand this was being handed to the proper team to check out.
  • first May 2018– I asked for an update.
  • second May 2018– FB responded– still exploring.
  • 23 rd May 2018– I asked for an update, noticing it was repaired in Chrome however not Safari.
  • 23 rd May 2018– FB responded– they were examining options.
  • 20 th June 2018– FB granted a $1000 bounty.
  • 1st October 2018– I requested approval to release.
  • 1st October 2018– FB responded they were still servicing the solution, as well as they ‘d update me.
  • 19 th February 2019– I adhered to up as well as FB appeared satisfied for me to release.

( It is unclear when the last repair rolled– it appears like 6-9 months after I reported it.)