We are working on Chrome extensions that
reads cookies from a domain which was set without SameSite attribute
writes cookies to a domain without SameSite attribute
We have added permissions to both the domains in manifest.json
We enabled the following flags in Chrome browser,
SameSite by default cookies
Enable removing SameSite=None cookies
Cookies without SameSite must be secure
Questions
Even after enabling the flags, we are able to read the cookies that were set with following values from other domain. Is that expected and if so why??
without SameSite attribute
with SameSite=strict
Say an extension sets cookies without SameSite attribute in a site with a domain X.com. What happens when the site (X.com) is
consumed via iframe by another extension
consumed via iframe by another site with domain Y.com.
Will the cookie be rendered with the response in both the cases??
Are requests from extensions considered as cross site request??
How does cookies set by extensions in a domain behaves?? Is that similar to what happens when a web site from a different domain sets a cookie??
Does extensions with permissions to a domain in manifest.json be able to read cookies from the other domain irrespective of the SameSite value??
howdy i'm pretty sure this isn't going to work due to the way chrome extensions operate outside the cookie store. It won't be able to read/write those values..
Related
I know the behavior about cookie is changed from chrome 80.
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
This blog says, "When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections."
Is this meaning that the cookie whose SameSite=None and Secure=False will be rejected by Chrome? Can't we set such a cookie?
I couldn't read that way.
However, in the test way which is written in this blog also indicates,
the description says "it will be rejected".
Cookies without SameSite must be secure
If enabled, cookies without SameSite restrictions must also be Secure.
If a cookie without SameSite restrictions is set without the Secure
attribute, it will be rejected. This flag only has an effect if
"SameSite by default cookies" is also enabled. – Mac, Windows, Linux,
Chrome OS, Android
Is this correct behavior?
Correct. If you are setting SameSite=None it must always be Secure. If you do not set Secure, the cookie will be rejected.
Chrome makes two flags available for early testing:
chrome://flags/#same-site-by-default-cookies - this flag will treat cookies without a SameSite attribute as if they had SameSite=Lax.
chrome://flags/#cookies-without-same-site-must-be-secure - this flag will cause cookies with SameSite=None but missing Secure to be rejected.
While these are two separate changes from a Chrome implementation point of view, developers should look to address this as one change. Review existing cookies and set the appropriate SameSite and Secure attributes where possible.
Since with Chrome 80(upcoming change in Feb2020), they are enforcing SameSite and Secure attributes to be set in a cookie to access that on a third party context. What happens to the existing cookies that are already in the browser which does not have SameSite and Secure attribute. Once Chrome rolls out its changes, will those legacy cookies sent on third party context?
Existing cookies without a SameSite attribute will be treated as if they are SameSite=Laxand restricted to a first party context. If you have existing cookies that need do not currently have the attribute and will need to be sent in a third-party context you should be actively refreshing them now.
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.
Visit a random site, for example example.com
Open dev tools, application -> cookies
Make sure that it's empty
Open console tab, make a fetch request to a random website, for example fetch('https://api.chucknorris.io/jokes/random')
Open application -> cookies again and notice cookies from the domain from step 4.
Many times a day I clear a website's cookies for debugging purposes. But in Chrome clearing one website's cookies affects clearing other sites' cookies as well and it clears my sessions on other websites, which is not what I want.
Is it a bug or a feature in Chrome? I think that it's a bug and cookies from other domain shouldn't be shown, but maybe I miss something.
P.S. Firefox don't show cookies from other domains.
What I have observed is that the list of URLs under the 'Cookies' entry is the page that made a request to the origin server for the cookies shown. If you look in the network traffic you can see the the URLs in the 'Cookies' list are the referer of the requests to the origin servers, whose response sets the cookie. This is a common method for tracking cookies to be set. A.com in the 'Cookies' URL list will have some page with lots of IMG or Script or iframe elements that make requests to the domains in the list of cookies and the responses from those domains set the cookies. What I found confusing is that the Chrome documentation (https://developers.google.com/web/tools/chrome-devtools/storage/cookies) refers to the list of URLs under the 'Cookies' entry as 'Origins'. They are not the cookies origin as defined in RFC 6265, they are the referer page that made the requests to the cookie origin servers.
I set the HSTS header on my site and i want to test that the different browsers (chrome, Firefox, IE, Opera) do enforce the header.
I set a trusted certificate, connect to the site and I can see the the header at the HTTP response. but i want to validate that the browser do enforce the protocol.
In Chrome it's easy and it works:
- I can query the site at chrome://net-internals/#hsts
- When trying to connect with HTTP i get 0kb response with status 307.
- If i change back self-signed cert i can't connect the site and there is no proceed option.
The other browsers behave differently, i can't query the HSTS list, the response status and size is different and when changing to self-signed cert (after first trusted connection) i do have proceed option.
So how can i validate that the protocol is enforced on each browser?
Although Chrome's ability to query the HSTS cache and see the fake 307 redirect is handy, you can just check whether HSTS is enforce.
HSTS offers you two options:
Automatically load HTTP resources over HTTPS
Prevent click through of cert errors.
You are concentrating on the second option, but why not use the first option as the test? Just load the site up with the HTTP and check whether it is redirected (i.e. loads HTTP URL and so is not using a HSTS rule) or if it just loads HTTPS URL immediately (i.e. is using HSTS).
So in Firefox for example open network tools click on "Persist logs" option (and let's do "Disable Cache" to avoid any confusion). Then go to a site which has an HSTS header over HTTP (e.g. http://stackoverflow.com) and you'll see a 301 redirect if this is your first visit:
Next time you go to it (after it has cached the HSTS header) it should go directly to the HTTPS URL even though you typed the HTTP URL in address bat:
If you've already been on stackoverflow.com then you can clear the HSTS cache to try this again.
Once you've confirmed that HSTS is being used or not, you can then investigate the click-through issue. Browsers should not allow click through when HSTS is in place, including for self-signed certs, but maybe there's a bug, or it's still cached your old cert in some places, or the HSTS policy has expired or something else...