[Webkit-unassigned] [Bug 196375] New: Safari doesn't send Lax cookies after a cross-site redirection

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 28 15:10:31 PDT 2019


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

            Bug ID: 196375
           Summary: Safari doesn't send Lax cookies after a cross-site
                    redirection
           Product: WebKit
           Version: Safari 12
          Hardware: iPhone / iPad
                OS: iOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: flavio at vinta.com.br
                CC: beidson at apple.com

Safari doesn't send Lax cookies after a cross-site redirection.
This breaks very common web application workflows, like clicking a tracker link on GMail.

Even though this seems related to #188165 and to #194906, please check this, as the problem still happens in MacOS 10.14.4 and iOS 12.2.

Simple steps to reproduce:

- Open https://safari-samesite-issue.herokuapp.com/target/ to set some Lax cookies
- Open https://safari-samesite-issue-other.herokuapp.com/redirect/ - Note that domain is different. That site performs a CROSS-SITE REDIRECT to https://safari-samesite-issue.herokuapp.com/target/
- Check that cookies set by /target/ aren't sent after /redirect/

Detailed steps to reproduce:

- Open https://safari-samesite-issue.herokuapp.com/target/
- If it's your first visit, you should see something like:

    request.session.session_key: None 
    request.session['obj']: a916f354195a4a45b6933ef41b26bdda 

    request.META['CSRF_COOKIE']: 
    CSRF cookie (from JS): NHaGQEiZ0PofLDqOG0vgYi7mD4kpBFvcEsxRQdLssjpaxG6hKixjT8iKaIOAau2g 

- What we're seeing above is:
  * those values are related to two cookies, sessionid and csrftoken. Both have the flag SameSite: Lax
  * request.session.session_key is None because request was sent without a sessionid cookie, since it was the first request
  * request.session['obj'] shows a value because that was set into the session whose sessionid cookie was set by the response
  * request.META['CSRF_COOKIE'] is empty because request was sent without a csrftoken cookie, since it was the first request
  * CSRF cookie (from JS) shows a value because the csrftoken cookie was set by the response

- Refresh https://safari-samesite-issue.herokuapp.com/target/ and you'll see values for request.session.session_key and request.META['CSRF_COOKIE'], meaning their cookies were well set
- Go to https://safari-samesite-issue-other.herokuapp.com/redirect/ - Note that domain is different. That site performs a CROSS-SITE REDIRECT to https://safari-samesite-issue.herokuapp.com/target/
- Now, at the same URL we first saw, we see something like:

    request.session.session_key: None 
    request.session['obj']: 5a0d196943c6447582720cc1582bdb61 

    request.META['CSRF_COOKIE']: 
    CSRF cookie (from JS): null 

- That's wrong. Lax cookies should be sent after a cross-site redirection. Other browsers don't behave that way. Tested on Chrome and Firefox for Mac.
- Issue seems even more serious because not only Safari doesn't send the cookies after the redirect, but it also can't read the cookies set by the response after the redirect. That's why "CSRF cookie (from JS)" is null.

Safari versions tested:

- BROKEN on MacOS 10.14.4 (18E226), Safari 12.1 (14607.1.40.1.4)
- BROKEN on iOS 12.2
- FIXED on Safari Technology Preview Release 77 (Safari 12.2, WebKit 14608.1.7.3) - as stated before
- FIXED on Safari Technology Preview Release 78 (Safari 12.2, WebKit 14608.1.9.1)

Steps to reproduce (other issue?). A similar problem that happens only on iOS 12.2, but not on MacOS 10.14.4:

- Open GMail
- Send a email to yourself with the following link on body https://safari-samesite-issue.herokuapp.com/target/ 
- Note the link above is /target/ directly, not a cross-domain redirection...
- ...but GMail adds it's own tracker link at onclick, so redirect happens from https://www.google.com/url?q=...
- When you reach /target/, you'll see empty values for request.session.session_key and request.META['CSRF_COOKIE'], meaning again that Lax cookies weren't sent

Workaround for both problems described above:

- Don't use SameSite: Lax. Remove SameSite attribute from your cookies.

Application code available at: https://github.com/vintasoftware/safari-samesite-cookie-issue

Possibly related issues:
- "Same Site Lax cookies are not sent with cross-site redirect from client-initiated load" - https://bugs.webkit.org/show_bug.cgi?id=194906
- "iOS 12 Safari breaks ASP.NET Core 2.1 OIDC authentication" - https://bugs.webkit.org/show_bug.cgi?id=188165
- "Microsoft Security Advisory: iOS12 breaks social, WSFed and OIDC logins #318" - https://github.com/aspnet/Announcements/issues/318
- "Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default" - https://code.djangoproject.com/ticket/30250
- "Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave" - https://code.djangoproject.com/ticket/29975
- "Safari 12 redirects back to /accounts/login" - https://github.com/IronCountySchoolDistrict/django-python3-saml/issues/1
- (Despite the link aboving says ITP is related, it doesn't seem to be. Even disabling it, issue is persistent)

-- 
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/20190328/1e76ae78/attachment.html>


More information about the webkit-unassigned mailing list