I am troubleshooting a bug that involves a cookie that is sometimes missing from a cross-site POST request.
This page from The Chromium Projects (last updated Mar 18, 2021) describes a temporary intervention to SameSite cookie behaviour, whereby some cookies have a 2-minute window for certain top-level cross-site POST requests.
It is referred to as "Lax+POST".
It describes that this behaviour as a temporary intervention which would be removed.
I cannot find any reference that says it has been removed, nor any updates within the last year.
Is this 2-minute behaviour still in place today (Dec 16, 2022) ?
Related
I have a web application and we are calling a third party to process some data. Once it's done, the third party will redirect back to my application (It's a post redirection). To keep the session, we are using cookies. After the google chrome update, where the default values for samesite=Lax, I've updated our cookies to pass as samesite=None; Secure to overcome this issue. Now after google chrome version 91, this implementation is not working and I'm getting a session expiry issue. Can somebody help to fix this issue for google chrome version 91 and after? I'm using java
The best that we have been able to come up with is a client side meta refresh. When the third party posts back to our application, we have a page filter that will send it to a "refreshMeta" page similar to https://www.w3.org/TR/WCAG20-TECHS/H76.html. This has to happen without calling .getSession() anywhere because that will cause a new session to be created. This causes the page to refresh in the browser and send all original cookies back to the server because its coming from the same domain and a new session wasnt created.
I will say this worked for a while but it looks like there was change in Tomcat that's preventing this approach from working like it did on earlier versions, which is why I'm back looking for another solution.
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.
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.
Site https://sorada.gov.ua has WoSign Certificate.
Got "A" on https://www.ssllabs.com/ssltest/analyze.html?d=sorada.gov.ua
But when google chrome updated to v.57 we got NET::ERR_CERT_AUTHORITY_INVALID error. All other browsers are OK.
Does anybody meet same problems?
Given the behavior of WoSign certificates issued after 10/26/2016 where distrusted since Chrome 56. And it was announced that in further releases this CA would be distrusted fully. To cite from Distrusting WoSign and StartCom Certificates:
Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted. ... In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of these CAs.
According to https://news.ycombinator.com/item?id=13866234 Google now distrusted this CA more than in the last release. To cite from the commit mentioned in the post:
Restrict the set of domains for which WoSign/StartCom certificates
are trusted to the set of domains intersecting the Alexa Top 1M
whose certificates are unexpired and unrevoked.
The problem you see is a result of this change.
For a discussion of the problem see Chromium issue 685826.
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.