22

My buddy Carsten Lau came along with an interesting idea on how to read cross-domain-cookies.

Situation: You want to read a cookie from domain "A" that was set on domain "B". Idea: From the client on domain "A", you execute a get-request to a dynamic resource on domain "B" – f.e. an image or javascript, which on the server "B" is in fact a programming language capable of reading cookies like PHP, Java etc. With that request, you send an unique identifier like a session id. So the code on the client which looks at a site on domain "A" could look like this:

<img src="www.domainB.com/?getCookie.php?sessionID=1234">

Now comes the funny part, server B reads on server-side the cookie set by domain "B" and writes the result with the provided session-id either in a DB accessible by domain "A" or returns a response which contains the cookie information to the client on domain "A" which then sends it via AJAX to server "A".

I am pretty sure there is a flaw we didn't find yet. I personally believe server "B" will not be able to read cookie informations because the client-browsers URL points to domain "A", but of course the "getCookie"-request explained above points to "B".

Please tell us what you think about it, why it works or why it can't work. A small proof of concept was, to my big surprise, successful.

Raphael Jeger
  • 5,024
  • 13
  • 48
  • 79
  • 2
    This should work. In fact, this is how websites handle logins for users from different domains, because the domains share databases which contain session data. – Joseph Apr 24 '13 at 08:18
  • 1
    Thanks. Everywhere on the internet and here on SO, you can read "cross domain cookies = impossible" while in fact that simple hack makes it possible, if you own both domains and can add a little script on domain "B"? Strange... – Raphael Jeger Apr 24 '13 at 08:25
  • 9
    There’s nothing strange about this. You are not reading or setting a cookie for a different domain here – that _is_ impossible from just your domain. If you have “help” from the other domain, then there is little “cross-domain” about it – you are getting the info _by choice_ from the other domain; whereas the cross-domain policy is in place to prevent that from happening where the other domain does not want this. – CBroe Apr 24 '13 at 09:16
  • How would I make this cookie data useable in my php? – alexander7567 Aug 05 '13 at 19:55
  • Now we have an ietf draft(so called "SameSite" attribute) to ban this behavior: https://tools.ietf.org/html/draft-west-first-party-cookies-07 – 罗泽轩 Jun 16 '16 at 02:44

2 Answers2

19

This is normal, because you have control of the 2 domains. This is how most websites achieve cross domain single-sign-on by the way. But if you do not have control of the second domain you cannot read cookies from it.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 4
    sure, you are right, but nonetheless most of the times when you are looking for setting cross-domain-cookies there are simple (and false) "not possible" answers all along. If you own both domains, there is no problem at all. – Raphael Jeger Apr 07 '14 at 07:02
2

I put together an NPM package to help with cross-domain cookie/localStorage usage. I know this post is a bit old, but I thought I'd share, in case anyone else needs help with this:

By using an iframe hosted on Domain A, you can store all of your user data on Domain A, and reference that data by posting requests to the Domain A iframe.

Thus, Domains B, C, etc. can inject the iframe and post requests to it to store and access the desired data. Domain A becomes the hub for all shared data.

With a domain whitelist inside of Domain A, you can ensure only your dependent sites can access the data on Domain A.

The trick is to have the code inside of the iframe on Domain A which is able to recognize which data is being requested. The README in the above NPM module goes more in depth into the procedure.

Hope this helps!

jmealy
  • 583
  • 1
  • 5
  • 14