[Webkit-unassigned] [Bug 208049] Javascript can't access a SameSite=Strict cookie after page is loaded after a redirect from a third party site

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 24 01:11:44 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=208049

--- Comment #6 from Aleksei <alekseipetrov at spotify.com> ---
(In reply to John Wilander from comment #5)
> > 4. Yes, Google Chrome behaves as expected. Latest Firefox though also has
> > this bug.
> 
> When you say “as expected,” do you mean by spec? I was a long while since I
> read the particulars of SameSite cookies. Two engines doing it one way and
> one doing it another may otherwise imply the opposite of what you’re saying.

AFAIK the spec (https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05) doesn't explicitly set the behavior of Document interface in browsers. The RFC a) defines the difference between "same-site" and "cross-site" requests and the algorithm to distinguish between them b) defines whether a Cookie header should be sent along with requests or not based on "SameSite" attribute.
I dunno about any spec regarding JS access to cookies based on `SameSite` attribute (plz point them out if you know).

However, if we look at the sequence of requests:
1. Request: GET https://some-integration.com HTTP/1.1
2. Response: HTTP/1.1 302 Found
Location: https://accounts.spotify.com/authorize?client_id=<client_id>&redirect_uri=https%3A%2F%2Fsome-integration.com%2Fsuccess 
   Request: GET https://accounts.spotify.com/authorize?client_id=<client_id>&redirect_uri=https%3A%2F%2Fsome-integration.com%2Fsuccess HTTP/1.1
3. Response: HTTP/1.1 200 OK https://accounts.spotify.com/authorize?client_id=<client_id>&redirect_uri=https%3A%2F%2Fsome-integration.com%2Fsuccess HTTP/1.1
   ... (for example) Request: POST https://accounts.spotify.com/authorize

and apply the algorithm from the RFC, the 1->2 will be a "cross-domain" request (I don't expect any Strict cookies to be sent to the backend with this request), however 2->3 is a "same-site" so there should not be any limitations on cookies (I don't consider using `iframe` in my statement).

The current Safari behaviour makes it impossible to use `SameSite=Strict` cookies for us, because you never know how this page gonna be opened (via redirect or not). And I don't think it's only for us: any internet page using SPA and Double Submit Cookie CSRF pattern (https://owasp.org/www-chapter-london/assets/slides/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf) for form submission can't have `csrf` cookie being strict (or can't use strict cookies at all).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200224/329b1563/attachment.htm>


More information about the webkit-unassigned mailing list