Cross-Domain Cookies

后端 未结 15 2522
抹茶落季
抹茶落季 2020-11-21 21:56

I have two webapps WebApp1 and WebApp2 in two different domains.

  1. I am setting a cookie in WebApp1 in the HttpResponse.
  2. How to read the same cookie fro
相关标签:
15条回答
  • 2020-11-21 22:32

    Yes, it is absolutely possible to get the cookie from domain1.com by domain2.com. I had the same problem for a social plugin of my social network, and after a day of research I found the solution.

    First, on the server side you need to have the following headers:

    header("Access-Control-Allow-Origin: http://origin.domain:port");
    header("Access-Control-Allow-Credentials: true");
    header("Access-Control-Allow-Methods: GET, POST");
    header("Access-Control-Allow-Headers: Content-Type, *");
    

    Within the PHP-file you can use $_COOKIE[name]

    Second, on the client side:

    Within your ajax request you need to include 2 parameters

    crossDomain: true
    xhrFields: { withCredentials: true }
    

    Example:

    type: "get",
    url: link,
    crossDomain: true,
    dataType: 'json',
    xhrFields: {
      withCredentials: true
    }
    
    0 讨论(0)
  • 2020-11-21 22:33

    Cross-site cookies are allowed if:

    1. the Set-Cookie response header includes SameSite=None; Secure as seen here and here
    2. and your browser hasn't disabled 3rd-party cookies.*

    Let's clarify a "domain" vs a "site"; I always find a quick reminder of "anatomy of a URL" helps me. In this URL https://example.com:8888/examples/index.html, remember these main parts (got from this paper):

    • the "protocol": https://
    • the "hostname/host": example.com
    • the "port": 8888

    The "path" part is:/examples/index.html. Notice the difference between "path" and "site".

    path

    Servers can set a Path attribute in the Set-Cookie, but it doesn't seem security related:

    Note that path was intended for performance, not security. Web pages having the same origin still can access cookie via document.cookie even though the paths are mismatched.

    site

    The SameSite attribute, according to web.dev article, can restrict or allow cross-site cookies; but what is a "site"?

    It's helpful to understand exactly what 'site' means here. The site is the combination of the domain suffix and the part of the domain just before it. For example, the www.web.dev domain is part of the web.dev site.

    This means what's to the left of web.dev is a subdomain; yep, www is the subdomain (but the subdomain is a part of the host)

    In this URL https://www.example.com:8888/examples/index.html, remember these parts:

    • the "protocol": https://
    • the "hostname" aka "host": example.com
    • (in cases like "en.wikipedia.org", the entire "en.example.com" is also a hostname)
    • the "port": 8888
    • the "site": www.example.com
    • the "domain": example.com
    • the "subdomain": www

    Useful links:

    • https://web.dev/samesite-cookies-explained/
    • https://jisajournal.springeropen.com/articles/10.1186/1869-0238-4-13
    • https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03
    • https://inst.eecs.berkeley.edu/~cs261/fa17/scribe/web-security-1.pdf
    • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

    (Be careful; I was testing my feature in Chrome Incognito tab; according to my chrome://settings/cookies; my settings were "Block third party cookies in Incognito", so I can't test Cross-site cookies in Incognito.)

    0 讨论(0)
  • 2020-11-21 22:34

    I've created an NPM module, which allows you to share locally-stored data across domains: https://www.npmjs.com/package/cookie-toss

    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!

    0 讨论(0)
  • 2020-11-21 22:35

    There's a decent overview of how Facebook does it here on nfriedly.com

    There's also Browser Fingerprinting, which is not the same as a cookie, but serves a like purpose in that it helps you identify a user with a fair degree of certainty. There's a post here on Stack Overflow that references upon one method of fingerprinting

    0 讨论(0)
  • 2020-11-21 22:38

    The smartest solution is to follow facebook's path on this. How does facebook know who you are when you visit any domain? It's actually very simple:

    The Like button actually allows Facebook to track all visitors of the external site, no matter if they click it or not. Facebook can do that because they use an iframe to display the button. An iframe is something like an embedded browser window within a page. The difference between using an iframe and a simple image for the button is that the iframe contains a complete web page – from Facebook. There is not much going on on this page, except for the button and the information about how many people have liked the current page.

    So when you see a like button on cnn.com, you are actually visiting a Facebook page at the same time. That allows Facebook to read a cookie on your computer, which it has created the last time you’ve logged in to Facebook.

    A fundamental security rule in every browser is that only the website that has created a cookie can read it later on. And that is the advantage of the iframe: it allows Facebook to read your Facebook-cookie even when you are visiting a different website. That’s how they recognize you on cnn.com and display your friends there.

    Source:

    • http://dorianroy.com/blog/2010/04/how-facebooks-like-button-works/
    • https://stackoverflow.com/a/8256920/715483
    0 讨论(0)
  • 2020-11-21 22:40

    As far as I know, cookies are limited by the "same origin" policy. However, with CORS you can receive and use the "Server B" cookies to establish a persistent session from "Server A" on "Server B".

    Although, this requires some headers on "Server B":

    Access-Control-Allow-Origin: http://server-a.domain.com
    Access-Control-Allow-Credentials: true
    

    And you will need to send the flag "withCredentials" on all the "Server A" requests (ex: xhr.withCredentials = true;)

    You can read about it here:

    http://www.html5rocks.com/en/tutorials/cors/

    https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

    0 讨论(0)
提交回复
热议问题