While investigating the (just released) Chrome 80 cookie changes (required SameSite=None for cross-domain cookies), I noticed some strange behavior in one of my applications. The particular application is embedded in another site - the the content is located in www.domain1.com, but the embedded application authenticated and loads from www.domain2.com. We use cookie-based authentication at the moment.
Because of the Chrome 80 cookie changes, we ended up adding SameSite=None to our cookies so that they could be used to authenticate and transfer to www.domain2.com when we made requests via our API. This fixed the Chrome 80 bug we were anticipating, but we discovered that Safari would not work in either iOS (versions 12 and 13 were tested) or Mac OS (versions 10.15 and 10.15). We narrowed the issue down to a default setting in iOS and Mac OS - the "Prevent cross-site tracking" checkbox in Safari preferences. Whenever that box is checked, our cookies do not transfer from domain1 to domain to, even when SameSite=None is set. This seems like it could potentially cause issues for a lot of different platforms, as prior to recently most sites expected cookies to be able to transfer this way.
Is this intentional behavior, or do we have something set up wrong? I've read about other applications having this problem, but have not found any solutions other than hacks like redirecting to a page on domain2 prior to loading the content on domain1, which isn't really an option for us. Is there some way to get around this, or a way to correct our setup so that we can actually pass cookies as we need?
Here's an example cookie that we receive back from our API during authentication:
"thirdPartyBlocked=1; expires=Tue, 09-Feb-2020 01:59:04 GMT; path=/{our app path}/; Secure; HttpOnly; SameSite=none"
This cookie works and transfers as expected in every browser other than Safari. Any ways to fix this issue?
Related
I wonder if anybody encountered with this problem. I am storing some data about visitor in django session. It works as expected but only mobile safari (iphone and ipad) have strange behaviour.
When I visit my site from iphone or ipad(Safari ver. 14.3) session cookie is normally set. But when I close the browser then reopen, new session cookie is generated.
This behaviour can be seen only on mobile safari version. I was not able to reproduce it on macOS desktop safari.
To solve this problem I had to change setup for session cookie in django settings.py:
SESSION_COOKIE_SAMESITE = ‘None’
According to django doc. cookie is normally set as ‘lax’ and this introduce security risk in my app.
SESSION_COOKIE_SAMESITE
Default: 'Lax' The value of the SameSite flag on the session cookie.
This flag prevents the cookie from being sent in cross-site requests
thus preventing CSRF attacks and making some methods of stealing
session cookie impossible. Possible values for the setting are:
'Strict': prevents the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a
regular link.
For example, for a GitHub-like website this would mean that if a
logged-in user follows a link to a private GitHub project posted on a
corporate discussion forum or email, GitHub will not receive the
session cookie and the user won’t be able to access the project. A
bank website, however, most likely doesn’t want to allow any
transactional pages to be linked from external sites so the 'Strict'
flag would be appropriate.
'Lax' (default): provides a balance between security and usability for websites that want to maintain user’s logged-in session after the
user arrives from an external link.
In the GitHub scenario, the session cookie would be allowed when
following a regular link from an external website and be blocked in
CSRF-prone request methods (e.g. POST).
'None' (string): the session cookie will be sent with all same-site and cross-site requests.
False: disables the flag.
I guess that I had to cause security hole in my django app intentionally. I don’t like it but I am not sure how serious risk it is. I would love to know why only mobile safari behave like that.
Having a very hard time with cookies on iOS. This issue has plagued me for a month now. I have a problem where my cookies are not being returned by Safari on iOS. Other browsers are not a problem.
Unfortunately, in my testing, I haven't been able to reproduce this issue. I have a physical iPhone myself, and can't get the issue to manifest.
What's happening is users are reporting issues where they can't login. My server code has been logging incoming requests, and in the instances where people can't login, the cookies are absent.
I'm wondering if ITP is getting in the way, but as far as I can tell, I've done everything right to satisfy it.
Here's a screenshot of the debug tools. It shows my two cookies ('cvt' and 'h'), with the expected expiration date.
Couple of things I should note. This is for a site hosted on azurewebsites.net, so it's a subdomain cookie being set. Cookies are set to be httponly, secure, and SameSite=strict
We have an Ionic 4 (Cordova/Angular) app that makes requests to a REST API backend with HttpClient, using cookies for authentication.
The app runs fine on Android (which apparently proves that we've configured CORS correctly). We are now in the process of adapting it for iOS. We have found that when the Safari setting "prevent cross-site tracking" is turned on (which it is by default), WkWebView ignores the Set-Cookie header that is sent by the backend in response to a successful login request, causing all subsequent requests to fail.
Is there a way to avoid the problem without requiring all users to turn off this setting (which is definitely not an option)? We have considered switching to JWT authentication, but I'm afraid that it won't solve the problem, as our backend expects JSON, and according to the docs, "Content-Type: application/json" headers also cause the request to be considered as a CORS request.
Additionaly, we have come across another problem which seems to be related. The app won't run on the iOS simulator on macOS - the Set-Cookie headers are ignored, even if we switch the above setting off! Meaning we can debug the app only on a physical device, which is quite a hindrance.
After several hours of searching on the web, and not finding any similar complaints, I have the feeling that I'm missing something obvious.
This library has come to my rescue: ionic-native-http-connection-backend
Quoting from the docs:
This library adds #ionic-native/http (when available) as a connection backend to Angular's Http and HttpClient
Motivation
Now that Apple promotes/requires the use of WKWebView instead of the deprecated UIWebView, Ionic has switched newly created apps over via their cordova-plugin-ionic-webview (and Cordova offers it via their cordova-plugin-wkwebview-engine). That causes requests that used to work just fine to fail with CORS errors.
The real solution of course is to fix the CORS issues server side - but this may not be possible with e.g. 3rd party APIs.
Even though there is a way to solve CORS issues without changing server's response header by using #ionic-native/http, this only works on device and doesn't provide all the power of Angular's Http and HttpClient.
How it works
The library provides a HttpBackend interface for Angular's HttpClient
This HttpBackend interface tries to use #ionic-native/http whenever it is possible (= on device with installed plugin)
If HttpBackend finds it impossible to use #ionic-native/http, it falls back to standard Angular code (HttpXhrBackend, which uses XmlHttpRequest)
This strategy allows developers to use Angular's HttpClient transparently in both environments: Browser and Device.
Although I still find it strange, that the developer only mentions the library's intended use for situations where CORS can't be configured server-side, but not the 2 problems that it solves for me, namely 1) having to require all users to allow cross-site tracking, and 2) not being able to use the simulator.
I have a mobile app that is using ODIC authorization code flow. Our server implementation is using Identity Server 4.
The mobile app opens a browser window and I can login to a 3rd party provider just fine, it then redirects to /signin-adfs on our identity server, which sets some idsrv.external cookies and returns a 302 to /External/Callback. The browser redirects to /External/Callback but doesn't send any of the idsrv.external cookies with it so Identity Server throws an exception because the result from HttpContext.AuthenticateAsync is not successful.
I'm kind of stuck at this point because I'm not a mobile developer. I deployed and have customized Identity Server slightly in other areas but not this part of the code.
I believe the mobile app is opening a Safari session to do the auth. Is this an issue with the cookies that the browser doesn't like (domain, path, https, secure)? or something else? The cookie size is chunked to 4KB a piece. I'm not sure what could be causing this issue.
To make things even weirder... if the browser is refreshed (/External/Callback) then the request works and the iOS app gets the code and can make the follow up request to get the token.
Was digging through the IS4 source and saw a link to this issue on github. Looks like it was fixed in source but hasn't been released yet. There are some workarounds in the github issue if you need it sooner than the release. The problem is specific to iOS 12.
I switched to the iPhone user agent during which time I visited Google, then I changed back to the default Firefox one again. I cleared all of my history, cache and cookies but Google still thinks I am on a mobile device and insists on directing me to the mobile site. I have checked my user agent and it is definitely the correct one and I have removed every single cookie in Firefox.
How is Google remembering this information? Is there some other sort of mechanism apart from cookies that remembers user settings? It doesn't do it in any other browser.
I've seen some issues such as this on Firefox. Which add-on are you using to change the UA?
To be absolutely sure what the UA String you can Check you User Agent String
Also you can check for cookies using the Fire Cookie Add-On
Normally i can fix this issue by Closing the web browser and starting up a new instance of Firefox.
My other issue with Firefox is that it caches HTTP redirection rules from a website, so if i change a HTTP redirection rule on the server Firefox does not immediately pick this up - This problem is also fixed by closing the web browser.
I solved this problem in firefox by resetting my default agent:
Tools->Default User Agent->Default User Agent
and then going to:
Tools->Clear Recent History->Cache