Is a chrome extension affected by SameSite cookie policy?
I use method chrome.cookies.get to retrieve a cookie from a website open in a tab.
What happens if this cookie has a SameSite attribute set to strict?
Thank you
SameSite will not impact access to a cookie.
The cookie SameSite value only affects the browsers behaviour on request it makes outbound, whether on not to include the cookie on the request being made.
For SameSite strict - the browser will only include the a cookie from the same domain. So if your browser location is currently on myDomain.com and you make a request to any path still on MyDomain.com the cookie will be included with the request. But if you make a cross site request (request from myDomain.com to someOtherSite.com) the browser will not include any myDomain.com cookies that are set as strict or lax.
This link is quite detailed on the cookie same site subject if you're interested.
https://web.dev/samesite-cookies-explained/
From https://www.chromium.org/updates/same-site/test-debug#TOC-Testing-Chrome-extensions
Chrome extensions must also abide by the new SameSite cookie behavior. Extension pages, which have a chrome-extension:// scheme URL, are generally considered cross-site to any web page (https:// or http://). There are certain scenarios where an exception is made (this is accurate as of Chrome 80, but behavior may change in the future):
If an extension page initiates a request to a web URL, the request is considered same-site if the extension has host permission for the requested URL in the extension’s manifest. This could happen, for example, if an extension page has an iframe embedding a site that the extension has host permission for.
If the top level frame (i.e. the site shown in the URL bar) is an extension page, and the extension has host permission for the requested URL, and the requested URL and the initiator of the request are same-site to each other, and the extension has host permission for the initiator origin, then the request is considered same-site. For example, this could happen if an extension has host permission for “*://*.site.example/”, and an extension page loads a.site.example in an iframe, which then navigates to b.site.example.
The chrome.cookies API is able to read and set any kind of cookie, including SameSite cookies. However, a web page embedded in an extension page is considered to be in a third party context for the purposes of document.cookie (JavaScript) accesses. For content scripts, the behavior of SameSite cookies is exactly the same as if the request were initiated from the page on which the content script is running.
Related
I have been working on a uni project and I'm getting really stuck on why the cross site authentication cookie from our backend isn't set when I do a CORS request to it from our backend.
Our setup is as follows:
A frontend on https://frontend-domain.com sends a CORS request to https://backend-domain.com with credentials in the post body, expecting a Set-Cookie: auth-token header in the response, if credentials are correct.
The fetch to the backend has credentials: 'include' set.
The backend response includes Access-Control-Allow-Credentials: true and explicitly states Access-Control-Allow-Origin: https://frontend-domain.com. The Allowed Methods header is also correct.
The token cookie in the Set-Cookie header has the attributes SameSite=Noneand Secure, it's domain attribute is Domain=backend-domain.com.
As far as I could find on the mozilla docs or here on stack overflow, these are all the requirements for cross site cookies to work. I expected the Set-Cookie header would make the browser set the cookie, which would then be sent along with all further requests to https://backend-domain.com, given credentials: 'include' is set.
However, the cookie is never set.
Can anyone help me? I am absolutely clueless by now.
Thank you very much for reading and helping!
Edit
I am using Firefox right now.
Here is a screenshot of the request:
And here is the response:
All of the Set-Cookie headers you can see in the response dont result in an actual cookie.
The SameSite attribute of a cookie controls whether this cookie is included in
subrequests (such as the ones made by an <img> or <iframe> element or a Javascript fetch command) to a different origin
top-level navigation requests (which load a new page into the current or a new browser tab).
Details are given here. Note especially the subtly different treatment of navigation with GET and POST ("Lax-Allowing-Unsafe").
Cookies in subrequests (but not top-level navigation requests) may be additionally restricted based on browser settings if they are third-party cookies, that is, if the top-level domains of their origin and the sending web page differ. In other words: Cookies from backend-domain.com count as third-party cookies when a request is made by an HTML page from frontend-domain.com, and this is what caused the issue in your case.
I have recently Pushed by Server and Webapp to the cloud. It is still in the testing phase and we're working with the default links given for both the server and Website. These links are normal HTTP and not Secure. I'm setting some cookies when the user logs in, but the client is not saving the cookies now. It's throwing an error stating Set-cookie was blocked because sameSite is empty so it has been set to Lax.
Questions :
I have tried setting the sameSite to None. But this also requires me to set secure as true. Which is not possible as the links are still HTTP only.
If I do not set the SameSite, It moves it by default to Lax. So it blocks my cross site cookie.
Is there anyway I can get this to work by someway completely avoiding SameSite or making it to none and still bypass the secure parameter?
Note : [ There server and Website have different URLs and these links are of EC2 (server) and S3 static host (website) ]
I noticed that when Prevent cross-site tracking is checked in Safari, I am unable to set the secure cookies. I described this issue in great detail in this question.
Then how do you set the secure cookies in Express with that setting enabled?
From MDN:
Values
The SameSite attribute accepts three values:
Lax
Cookies are allowed to be sent with top-level navigations and will be sent along with GET request initiated by third party website. This is the default value in modern browsers.
Strict
Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites.
None
Cookies will be sent in all contexts, i.e sending cross-origin is allowed.
None used to be the default value, but recent browser versions made Lax the default value to have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
None requires the Secure attribute in latest browser versions. See below for more information.
It says in this article that Apple is phasing out third party cookies with Safari. I'm reading online that third party cookies are generated by a different domain than the one user is visiting, for cross-site tracking, retargeting, and ad-serving.
I am working on a project where the frontend is served on Netlify and the backend is from Heroku. Since the backend has a different domain than the front-end, the cookies generated from the node express backend are considered Third-party cookies?
Does that mean that I should have both frontend and backend on the same server going forward following this security practice?
Netlify allows you to proxy requests to your backend on a different hostname.
https://docs.netlify.com/routing/redirects/rewrites-proxies/#proxy-to-another-service
I'm not sure if it will let you set the cookies that way, Netlify might strip all headers, you should try.
If for some reason that does not work for you then you should either serve frontend and backend from the same hostname or set the cookie with JS on the client-side (which I don't recommend), also you can't set HttpOnly cookie from JS side.
I have a site with mixed HTTP / HTTPS. When the user logs in, she gets two cookies:
a regular cookie with her (signed) username, login expire time, and an "insecure" flag
a secure cookie with her (signed) username, login expire time, and a "secure" flag
note that if you don't have the secure/insecure flag within the signed content, an attacker can intercept the regular cookie and then send it as the secure one (my first implementation made this mistake)
I use the regular cookie on HTTP pages (just for showing her name while she browses the marketing portion of the site). Then I use the secure cookie when she's on HTTPS pages (any user-specific pages).
I got the idea from Secure cookies and mixed https/http site usage.
Everything works great, except that when the user navigates from an HTTPS page to an HTTP one, all of the secure cookies get deleted - which means that they can't go back to HTTPS pages after visiting even a single HTTP page. I should mention that there is a "301 Moved Permanently" that redirects the user to from HTTPS to HTTP.
My site isn't clearing the secure cookie. I know that the browser shouldn't send me the secure cookie while the user is looking at an HTTP site, but I expected the cookie to stick around for its lifetime, and get sent if the user ends up on an HTTPS page again.
I'm getting this same behavior on Chrome, Firefox, and IE. Any tips? I hope this isn't the expected behavior...
Welp, that's embarassing. Here's what my problem turned out to be.
When the user tried to visit an HTTPS site from an HTTP one, their request would start as HTTP
I would check their login credentials (which would fail, because the secure cookie wasn't there), then redirect them to HTTPS. My "require login" and "require HTTPS" systems were separate (a bad design now, but it was convenient in the bad old days where the login cookie wasn't secure)
I thought my secure cookie was being deleted because the Chrome cookie browser doesn't show secure cookies when the page being shown is HTTP. The cookies were there all along.
Working on troubleshooting an interface consumed by 3rd parties. The quick overview:
3rd party sends the user out our site example.com/login to let the user authenticate with us
After signin we redirect the user back to thirdparty.com
thirdparty.com consumes a dynamic JS file on our site used to return information about the logged in user example.com/dynamicJs.js
Since this request is made against example.com it should include the cookies dropped during login (they are required for it to serve its purpose)
for IE, they are no longer being included in the request
In researching:
the cookies themselves don't appear to have changed, and manually navigating IE to the URL of dynamicJS.js results in the necessary cookies being transmitted.
example.com has P3P policies in place and is not generating any visible warnings/errors with IE
other browsers include the cookies
So, what other variables could be influencing IE and resulting in it omitting the example.com cookies when loading example.com/dynamicJS.js?
After much research we identified the root of the issue was within IIS's Custom HTTP Response Headers.
Previously we had configured the site to return a P3P header, but in diagnosing this issue we found that somehow the header was now being returned as 3P. Returning the key to P3P resolved out issue.
In researching the actual cause of this change we found that the bad header originated in the web.config, within the <httpProtocol><customHeaders> element -- however it appeared to have been placed there some time ago and remained dormant until the AppPool was stopped/restarted for maintenance.