Summary: | ITP treating TLD+1 and TLD+2 matched domains as cross-site trackers. | ||
---|---|---|---|
Product: | WebKit | Reporter: | Lakshman <lakshman.nittala> |
Component: | WebKit Misc. | Assignee: | John Wilander <wilander> |
Status: | NEW --- | ||
Severity: | Critical | CC: | webkit-bug-importer, wilander |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 15 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=233902 |
Description
Lakshman
2021-11-18 12:54:54 PST
Hi! Thanks for filing. ITP does not block cookies for same-site, cross-origin content. However, it does make use of the Public Suffix List to find out what the sites or registrable domains are. It’ll be easier to investigate if you share an example of the top frame’s host name (full domain with subdomains) and the iframe’s host name. Hi John, Thanks for the response. Below are the examples of the URLs: patientportal.patientportal.example.com accessing patientportal.example.com failed patientportal.differentpath.example.com accessing differentpath.example.com failed sometimes and worked sometimes. (In reply to Lakshman from comment #2) > Hi John, Thanks for the response. Below are the examples of the URLs: > > patientportal.patientportal.example.com accessing patientportal.example.com > failed > > patientportal.differentpath.example.com accessing differentpath.example.com > failed sometimes and worked sometimes. Have you tested with those exact URLs, i.e. with *.example.com, or are you using example.com as a placeholder for the real domain that goes there? I'm asking because of the Public Suffix List (https://publicsuffix.org/list/public_suffix_list.dat) and the possibility that what you have in place of example.com is on that list. Also, can you share these details on the cookies that are being blocked: 1. How are you accessing the cookies – in HTTP requests or through document.cookie? 2. Are all cookies or just some cookies being blocked at any one time? 3. How are the cookies configured? I'm thinking of attributes such as secure, domain, path, and SameSite. 4. Are there any redirects involved when you load the resources where cookies are blocked? I'm especially interested in any redirects to different registrable domains. Thanks! Have you tested with those exact URLs, i.e. with *.example.com? example.com is a placeholder. We mainly create .org sites. 1. How are you accessing the cookies – in HTTP requests or through document.cookie? We retrieve cookies in server sites requests. 2. Are all cookies or just some cookies being blocked at any one time? We were unable observe this on our tld+2 failures (the sites have since been updated to working domains), but for the case where the domains do not match, no cookies are applied. As our authentication should be the first thing the iframed site does, I would expect that the tld+2 failures would behave the same. 3. How are the cookies configured? I'm thinking of attributes such as secure, domain, path, and SameSite. Our cookies include Domain: .<tld+1> Path: / Secure: Yes HTTP Only: Yes Same Site: None 4. Are there any redirects involved when you load the resources where cookies are blocked? I'm especially interested in any redirects to different registrable domains. Our authorization checks for a cookie with a matching tld+1 domain (mentioned above). If that cookie is not present, it will redirect to an IDP with a different domain. However, we should not expect to hit this workflow for successful iframe authentication. This would not be so odd if it was failing universally, for all of our .org urls. The fact that we can modify a +2 or +3 url component and have it work seems like there are other rules around the cookie blocking that we have been unable to identify. I'm adding basic tests for these kind of duplicate sub domains in https://bugs.webkit.org/show_bug.cgi?id=233902. The logic in WebCore::RegistrableDomain seems to do the right thing. Would it be possible for you to provide a reproducible test case with domains you control? Thanks! |