We have a webapp that embed another webapp on a different site in an iFrame. This had been in place for a few years already. Last week we started to get error reports from some users. After investigation we found that on Chrome 84.0.4147.125, released Aug 10, 2020, the cookies in the iFrame are not sent back to the server. The issue only occurs since this chrome version. Older versions and other browsers are working fine.
What has changed in this release that could have this impact?
Thanks #Eyal.D for pointing to the solution.
As stated in https://stackoverflow.com/a/45095345/1401409 :
Chrome now blocks cookies without SameSite set, so you need to
explicitly set it to samesite=none.
I was able to fix this by adding the following in my httpd configuration:
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=None
I would add, as stated in https://stackoverflow.com/a/57874184/1401409 :
If you own the somesite.com you can opt-out of this policy by setting
SameSite policy to None and deal with the risk of CSRF attacks by a
doing Double Submit Cookie.
Related
I am using the standard OIDC .NET library to make a challenge request to ADB2C. From my understanding, this automagically attempts the sign in with the refresh token in cache and gains an authorization without re-asking for credentials.
This seems to work absolutely fine, except on 1 browser - Chrome on Android. No matter what I try, this browser seems to to lose the refresh token, so after around 1 hr, it starts asking for credentials again. I have cross checked this on Chrome web/mac, edge, IE, safari, FF and they all behave as expected to maintain a constant logged in state.
Any ideas? This should be browser independent from what I understand, but maybe I'm missing a trick?
Update
This seems to be similar behaviour even when accessing a web app protected by AD. Again, Chrome loses the refresh, but other browsers are fine.
Update
I see this in Fiddler when trying to access the site after the expired token
Chrome
Set-Cookie: x-ms-cpim-csrf=XXX; domain=auth.mywebsite.com; path=/; SameSite=None; secure; HttpOnly
Edge
Set-Cookie: x-ms-cpim-sso:mytenant.onmicrosoft.com_0=XXX; domain=auth.mywebsite.com; path=/; SameSite=None; secure; HttpOnly
So yes there is a difference, but why and how to fix?
It could be the issue with SameSite cookies in Chrome that causes he cookies to not be sent as you expect. Here's a few pointers to help you out:
How To Prepare Your IdentityServer For Chrome's SameSite Cookie Changes - And How To Deal With Safari, Nevertheless
Upcoming Browser Behavior Changes: What Developers Need to Know
But I think first of all you should verify if this is a SameSite issue, by using a tool like Fiddler to capture the traffic and verify that the cookies are indeed lost. Do compare in Fiddler your different browsers and see if there's some differences.
Do try to login using a incognito mode, so that you start with no cookies in the browser. Then you should see the cookies being set both by your identity provider and your application.
In Fiddler you can under the Filter tab enable the first item in the picture to flag responses that set cookies, to make it even easier to detect when cookies are set.
I ran into such a problem.
When I run the application on my laptop (Linux/Ubuntu 18) in the developer console in the Chrome browser, I have this message
A cookie associated with a cross-site resource at
http://pubsub.rtschannel.com/ was set without the SameSite
attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with SameSite=None and Secure.
You can review cookies in developer tools under
Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
On another laptop (Linux/Ubuntu 16) in the Chrome browser, when the application is launched locally, there is no such message.
I tried to find at least some information on this subject, but alas I couldn’t. The only thing I could find was the link inside the message that it was a browser bug and in Chrome version number 80 it should be fixed and this setting would be added by default.
Please tell me, does it depend on the browser settings, or can I somehow influence this message programmatically? Can I clean it somehow?
On the project, I use angularjs if this can help.
Thanks.
These warnings are purely informational at the moment and do not affect site functionality. This behaviour will not be enforced until Chrome 80 which is due to hit stable in Feb 2020.
You can simply turn off the messages by setting chrome://flags/#cookie-deprecation-messages to Disabled. However, that is purely affecting the display of the messages.
If the pubsub.rtschannel.com is not your domain, e.g. it's a third-party service you use, then it's that domain that will be responsible for updating the cookies.
If it is your domain, then you need to review the cookie usage and set an appropriate value for the SameSite attribute on the cookie. You can find more context and guidance on https://web.dev/samesite-cookies-explained.
I notice that certain cookies saved in my chrome browser are getting deleted automatically without any manual intervention. I have the some extensions installed in chrome. I want to know if anybody has faced the same issue. Do certain extension delete cookies on a regular basis? Any information would be helpful
I think I know the answer! Google chrome has a cap on the number of cookies it allowed per domain . Once the total number of cookies in that domain exceeds that count, it deletes cookies! Verified!
It must be due to some extension that you have installed. Extensions can have access to clear the cookies.
So, If you have not deleted the cookies manually, then the other extensions installed, are the responsible for clearing the cookies.
I have also observed something similar. After updating to Chrome 67 stable about two weeks ago some cookies disappeared. No matter if I set them again, after restarting chrome they are not there. Like the blocking cookie of web statistics/hit counter.
I don't know details, but looks like it may be related to http/https issue, I see in the site info that for some of the http pages background data is not synced in Chrome.
Or, if the cookie has no expiration time.
They're still being deleted without my consent and it's not due to extensions.
I have created several virtual hosts for my development processes. They were working just fine till yesterday. But in my chrome app, today they stopped working. Chrome shows: NET::ERR_CERT_AUTHORITY_INVALID
All my vhosts end with .dev. I changed one .dev to .work and its again working. But I can not do this for all vhosts as there are too many of them. What do I do?
PS:
They are working fine in firefox.
The error remains same in chrome incognito mode.
I tried clearing cache and hard reload, deleted my history and cache, restarting chrome even windows multiple time, nothing works.
In one solution, I found an exception can be included in chrome://net-internals/#hsts. I tried deleting domain in there but somehow it still appears in Query Domain search.
Chrome have switched the .dev sub domain to HTTPS only.
They have done this by turning on HSTS for this top level domain, but by preloading this in the Chrome code rather than sending the HSTS header. This means it cannot be switched off in the chrome://net-internals/#hsts screen.
More info:
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
So you’re only options are:
Update you’re vhosts to a different TLD (e.g. .test). And yes this might be painful because you have so many.
Move to HTTPS by creating a certificate and updating your URLs. A self signed certificate that you can create yourself will do, however note that HSTS not only blocks accessing the site over plaintext HTTP, but also prevents you clicking through certificate errors. So you’ll need to manually accept any certificate to your trust store before it can be used.
The chrome team have been pushing HTTPS more and more and certain features are now HTTPS-only so even dev envs will need it now. So maybe it’s finally time take the effort to make the switch.
I was doing some research on how Firefox and Chrome are implementing HSTS (HTTP Strict Transport Security) in detail.
Turns out that they have a predefined list with some sites that already implement HSTS. This can be seen here here and/or here.
And these list seems to be somehow linked to the sourcecode itself which makes somehow sense...but how do Firefox and Chrome handle my own HSTS headers? How and where do they store my URL, my max-age and whether I includeSubDomains or not?
I wasn't able to find this in about:config or likewise....
So maybe somebody knows more about this issue than me, I'm just curious (:
Thx!
See http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/netwerk/protocol/http/nsHttpChannel.cpp#l1072 and then http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l249 which calls http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l147
So the data ends up stored in the permission manager, which is the normal place per-host information gets stored in Firefox. The permission manager stores its state in permissions.sqlite, I think.
Sites that want HTTP Strict Transport Security (HSTS) enforced send a header in response - Strict-Transport-Security: max-age=31536000
max age being time for it to expire. It is sent on each request so that it gets updated to that much more time every time it is requested.
Browser (I have tried only Firefox) stores this data with it and will use it every time the site is accessed. This is true even for incognito mode. If you have ever accessed the site before in non incognito mode then the details of that site is saved and used even if you try to open it now in incognito mode.
For firefox this data is stored in a file called SiteSecurityServiceState.txt which is in your firefox profile folder. You can enter about:support in browser and then select "Show in folder" to open your profile folder where you can locate this file.
I am not sure about predefined sites but above is the file where normal site HSTS details are updated for firefox.
More details - Understanding HTTP Strict Transport Security (HSTS)
PS: Above link goes to my personal blog that has more details on HSTS.