-1

If I log into Facebook.com and then in another tab log into domain x.com, which uses some Facebook widget, how does the Facebook widget installed on x.com know I'm logged into Facebook and not require re-authentication to use it?

It seems that from x.com a script is able to read a cookie created under Facebook.com and that defies the consensus that cookies can't be read across domains. How is Facebook circumventing the consensus?

Matt
  • 74,352
  • 26
  • 153
  • 180
Guessed
  • 417
  • 1
  • 4
  • 15
  • 1
    Apart from what Sulliman already said in his answer, the JS SDK is of course able to make cross-domain requests to Facebook’s servers to determine the user’s login status as well. If you are wondering how that works, your research keyword is CORS. – CBroe Sep 26 '15 at 08:14
  • That appears to encompass cross-domain server data, server sessions, client sessions, and browser cookies, persistence, and controlled promiscuity. Wherever "cross-domain cookies can't be shared is stated" needs to be refuted and the @Ludovic reference in my answer above cited. – Guessed Sep 28 '15 at 15:53
  • That’s plain and simply setting 3rd-party cookies, something the advertising industry has been doing for years – absolutely nothing special about it. And this doesn’t mean that the cookie actually crosses the domain boundary – it still can only be accessed from the domain that it was set under (or “from”). – CBroe Sep 28 '15 at 17:21
  • After I applied the @Ludovic config changes, my setup is now allowing x.com to read cookies from y.com. – Guessed Sep 28 '15 at 17:49
  • No, that is not what happens. When you make the request _from_ X to Y, any cookies that have been set under the domain Y before, will be send together with that request to Y (which would not happen if `withCredentials` wasn’t set.) But that does not mean, that any domain Y could read cookies set _for_ the domain X willy-nilly. http://www.html5rocks.com/en/tutorials/cors/#toc-withcredentials – CBroe Sep 28 '15 at 18:14
  • I do not dispute that it does not mean any domain Y could read cookies from X _by default_. What I am saying, per @Ludovic, is cross-domain cookie access can be deliberately enabled with such settings as `withCredentials` at the client and specific headers at the server, etc. So, while default browser behavior provides secure cookies sandboxed within each domain, with the appropriate settings, cookies can indeed be both set and read cross-domain. Many people have asked this on SO and read answers stating that it is not possible. – Guessed Sep 28 '15 at 20:02
  • Quote from the article I linked to: “The .withCredentials property will include any cookies _from the remote domain_ in the request, and it will also set any cookies from the remote domain. Note that these cookies _still honor same-origin policies_, so your JavaScript code can’t access the cookies from document.cookie or the response headers. They can only be controlled by the remote domain.” … and that’s all there is to it. – CBroe Sep 28 '15 at 20:11
  • "Controlled" is an interesting term, since indeed the source domain must be provoked - even if remotely, but the remote domain can then access the source domain's cookie data. Remote provocation, with `cookie` in domain here.com, as in this article: **http://www.willmaster.com/library/cookies/setting-a-cookie-on-a-remote-domain.php**, can even have domain here.com provoke the creation of a cookie in there.com, without special client or server settings. – Guessed Sep 28 '15 at 20:24
  • Again, that would just a be a plain old 3rd-party cookie, and has nothing to do with CORS – and there.com is in full control here, after all it decides whether to set a cookie or not when it receives such a request. Of course you can call any garden-variety HTTP request a “provocation”, if you like … but that doesn’t change anything about the plain and simple mechanisms that are at work here. – CBroe Sep 28 '15 at 21:01
  • _“but the remote domain can then access the source domain's cookie data”_ – for sure not with just that simple image request you have shown as an example. – CBroe Sep 28 '15 at 21:02
  • @CBroe Right, after loading the you would have to use the aforementioned techniques to read the remote cookie. These methods combined comprise a powerful tracking suite. Pull Google's ubiquitous cookies into your mix and you can practically use them as a parasitic error-handling layer on top of your cookie schema. – Guessed Sep 29 '15 at 00:30
  • Please do not edit a solution into your question. Instead, post it as a separate answer below. – Matt Oct 25 '15 at 22:49
  • @CBroe But how the cross original request know which user its asking about, and which device to ask is logged in? – run_the_race Jan 30 '22 at 11:37

1 Answers1

3

Most of the time, the widgets you are talking about are really just <iframe> (or <object>) tags. So, you are just seeing a part of Facebook from their real domain on another page. The Facebook page have access to all of your Facebook cookies, so they can recognize you and log you on.

It is impossible for "x.com" to have access to those cookies for obvious security reasons.

Sulliman Aïad
  • 96
  • 4
  • I've noted frequent mention of Facebook using ` – Guessed Sep 29 '15 at 00:35