I have a flask application hosted in heroku embedded as an iframe to one of my website.
Let's say a.com renders this <heroku_url>.com as an iframe.
When user visits a.com, <heroku_url>.com is rendered and session is created.
from flask import session, make_response
#app.route("/")
def index():
session['foo'] = 'bar'
response = make_response("setting cookie")
response.headers.add('Set-Cookie', 'cross-site-cookie=bar; SameSite=None; Secure')
return response
In Chrome dev tools, I see the cookie getting blocked. Works fine in firefox though.
Am I setting the cookie properly?
I understand this is due to chrome80 update, but not sure about the workaround
Setting samesite attribute in the session cookie to None seems to have solved the problem.
Had to update werkzeug (WSGI web application library which is wrapped by flask) and update the session cookie.
i.e
app.config['SESSION_COOKIE_SAMESITE'] = 'None'
app.config['SESSION_COOKIE_SECURE'] = True
However, this also depends on the user's preference in 'chrome://settings/cookies'.
Chrome will block the session cookies even if samesite is set to None if one of the below options is selected
Block third-party cookies
Block all cookies
Block third-party cookies in Incognito (blocks in incognito mode).
You can check your browser is treating the cookies as expected by checking the test site at https://samesite-sandbox.glitch.me/
If all the rows contain green checks (✔️) then there it's likely there is some kind of issue with the cookie and I would suggest checking the Issues tab and Network tab in DevTools to confirm the set-cookie header definitely contains what it should.
If there are any red or orange crosses (✘) on the test site, then something in your browser is affecting cookies. Check that you are not blocking third-party cookies (chrome://settings/cookies) or running an extension that may do something similar.
Im working on a .NetCore MVC project.
As the title suggests my goal is to store a cookie that will eventually be accessible through an iframe.
In order to achieve that this is what I did -
Startup.cs -
app.UseCookiePolicy(new CookiePolicyOptions
{
MinimumSameSitePolicy = SameSiteMode.None
});
Using the actual CookieOption class -
public void SetCookie(string key, string value, int? expireTime, HttpResponse Response)
{
CookieOptions option = new CookieOptions();
//allow cross-site cookies for iframes
option.SameSite = SameSiteMode.None;
if (expireTime.HasValue)
option.Expires = DateTime.Now.AddMinutes(expireTime.Value);
else
option.Expires = DateTime.Now.AddMilliseconds(10);
Response.Cookies.Append(key, value, option);
}
Doing the above It seems like it doesn't always work as intended.
Iv'e tested lots of browsers both desktop and mobile.
Just found out that sometimes the cookie is stored successfully like so -
Send for:
Any kind of connection
Accessible to script:
Yes
And sometimes on the same exact chrome version just a different computer its stored like so -
Send for:
Same-site connections only
Accessible to script:
Yes
Which basically means it won't be accessible using iframes.
The problem isn't a specific computer issue as I was managed to duplicate the problem on 3 different computers running the same chrome version which works fine on other computers.
The example above was produced using this chrome version (last version):
Version 80.0.3987.149 (Official Build) (64-bit)
Anyone have an idea how can I overcome that ? gotta make sure cookies will always be accessible using an iframe.
Thanks!
Edit - Attempt with Secure and HttpOnly flag
So iv'e adjusted my code to set the HttpOnly and the Secure flags to true.
The computers that usually worked fine had this cookie settings -
Send for
Secure connections only
Accessible to script
No (HttpOnly)
And it works fine with iframe.
The computer which didn't work before had this cookie settings -
Send for
Secure same-site connections only
Accessible to script
No (HttpOnly)
Which obviously didn't work with an iframe...
Just updating of another approach that didn't work.
Edit 2 - Using fiddler to intercept the cookies response:
So using fiddler to read the cookie this is what it looks like -
Set-Cookie: __cfduid={randomvaluehere}; expires=Fri, 24-Apr-20 17:37:48 GMT; path=/; domain=.domain.com; HttpOnly; SameSite=Lax
Set-Cookie: mycookie=mycookievalue; expires=Fri, 24 Apr 2020 17:37:49 GMT; path=/; secure; httponly
So seems like the response is storing a cookie with is SameSite=Lax on the apex of the domain, which I don't care about.
I work on a sub-domain which is the second set-cookie that is shown above.
Looks like SameSite=None isn't explicitly presented, should it? if so why wouldn't it seeing the code above?
Also reminding you that exactly that works fine for other browsers or other computers with the same chrome version.
The sample above is exactly the same on computer where it worked and in one that it wasn't.
The new chrome versions 72+ does not send the requestHeaders .
there was a solution:
DevTools Protocol network inspection is located quite high in the network stack. This architecture doesn't let us collect all the headers that are added to the requests. So the ones we report in Network.requestWillBeSent and Network.requestIntercepted are not complete; this will stay like this for the foreseeable future.
There are a few ways to get real request headers:
• the crude one is to use proxy
• the more elegant one is to rely on Network.responseReceived DevTools protocol event. The actual headers are reported there as requestHeaders field in the Network.Response.
This worked fine with the old chromes but not with the last versions. here is a small summery I made for the versions a coulded test
a solution for chrome v67 was to add this flags to disable Site Isolation :
chrome --disable-site-isolation-trials --disable-features=IsolateOrigins,site-per-process --disable-web-security
Now all of this does not work with the last chrome v73
maybe it is caused by this:
Issue 932674: v72 broke devtools request interception inside cross-domain iframes
you can use Fetch protocol domain that is available since m74
the solution gaven does not work neither, the Fetch.requestPaused does not contain the request headers...
I found some info that maybe causes that:
DevTools: do not expose raw headers for cross-origin requests
DevTools: do not report raw headers and cookies for protected subresources. In case subresource request's site needs to have its document protected, don't send raw headers and cookies into the frame's renderer.
or it is caused when it is an HTTP/2 server?
Does the HTTP/2 header frame factor into a response’s encodedDataLength? (Remote Debugging Protocol)
...headersText is undefined for HTTP/2 requests
link
1- How can I get the Request Headers using the Chrome Devtool Protocol with chrome v73+?
2- Can a webextension solve that?
3- Is there another way which will be stable and last longuer? like tshark+sslkeylogfile which I'm attempting to avoid. thank you
I've been investigating the implementation of CTAP2 protocol with Google Chrome (protocol between Fido Authenticator and Fido Client (e.g. Chrome)), which should be supported in Chrome since version 69.
So I dumped the chrome request to the authenticator in two cases:
1. U2F (CTAP1) with yubico demo website.
Here everything goes as expected and chrome follows the CTAP1 protocol.
2. FIDO2/Webauthn (CTAP2) with webauthn.org
And the browser has a strange behaviour:
It starts by following the CTAP2 protocol by sending a AuthenticatorGetInfoRequest
The Authenticator replies with AuthenticatorGetInfoResponse
But then Chrome switches to the CTAP1 protocol by sending a Registration Request Message (U2F_REGISTER)
Is it a problem with Chrome implementation: CTAP2 is not enabled entirely yet (it seems to be implemented in Chromium sources)?
Or is the problem coming from the authenticator: sending a response that makes Chrome switch to CTAP1?
Or something else entirely?
In AuthenticatorGetInfoRequest, the authenticator must respond with a string list of the supported versions among "U2F_V2" and "FIDO_2_0". Note also in case of NFC or CCID, a "FIDO_2_0" (CTAP2) only authenticator shall anwser directly "FIDO_2_0" on the SELECT command. I don't know about HID and BLE.
So maybe your authenticator is listing "U2F_V2" in the protocol versions list in AuthenticatorGetInfoRequest.
I also imagine the Chrome code base about this was moving fast and can be partial or not strict. To my tests in early 2020, the Chrome CTAP capabilities seem now stable and compliant.
I noticed recently, that when I reboot my Tomcat web server, that the Chrome browser can no longer store cookies. i.e. tomcat uses cookies for http sessions, and the browser can no longer get its http session, also the cookie we use to store the logged in user fails, and the user does not remain logged in.
This seems to be a new issue with Chrome, perhaps from a recent update, I do not remember seeing it before. If I close the Chrome browser, then reopen it, it is fine again (until the server is rebooted again).
The issue does not happen on Firefox, seems like a bug in Chrome.
Has anyone else noticed this issue, or know of a solution?
I found some posts about Chrome/tomcat cookie issues and the suggestion to set,
sessionCookiePathUsesTrailingSlash=false in the context.xml
but this does not fix the issue.
It seems it might be related to the website supporting both https and http, and switching between the two (although it did occur on a website that did not support https as well...)
Okay, I can now recreate the issue, steps are.
connect to website via https
logout / login
connect to website via http
Tomcat JSESSIONID cookie can no longer be stored (oddly user/password cookies are stored)
This only happens on Chrome, and only since the Chrome update that add the "insecure" flag on login pages that use http
Okay I added this to my web.xml
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
This did not fix the issue, but made the issue always occur through http, i.e. make http no longer able to store the JSESSIONID cookie.
I tried <secure>false</secure> but still get the old issue.
So, it is related to this setting at least. Anyone have any ideas?
Logged bug on Chrome,
https://bugs.chromium.org/p/chromium/issues/detail?id=698741
I was able to reproduce your problem with Chrome: Just it is needed to create HttpSession from HTTPS zone. Any subsequent HTTP request will not send the session cookie and any attempt to Set-Cookie:JSESSIONID= through HTTP is ignored by chrome.
The problem is localized when the user switch from HTTPS to HTTP. The HTTPS session cookie is maintained even if server is restarted and is working properly. (I tested with Tomcat6, Tomcat 9, and using an apache proxy for SSL)
This is response header sent by Tomcat when session is created from HTTPS
Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly
and this one for HTTP (note Secure is missing)
Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly
Chrome ignores the second set-Cookie. On the other hand Firefox and Edge replace the Secure cookie with the not-secured. To determine what the correct behaviour should be I have reviewed RFC2109
4.3.3 Cookie Management
If a user agent receives a Set-Cookie response header whose NAME is
the same as a pre-existing cookie, and whose Domain and Path
attribute values exactly (string) match those of a pre-existing
cookie, the new cookie supersedes the old.
So, It is clear is a chrome bug, as you supposed in the question: The HTTP cookie should replace the one setted by HTTPS
Removing cookie manually from Chrome or invalidating the session at server side makes it work again (if after these actions the session is created using HTTP)
By default the JSESSIONID cookie is created with Secure when is requested from HTTPS. I guess this is the reason that Chrome do not allow to overwrite the cookie. But if you try to set <secure>false</secure> in web.xml Tomcat ignores it and the Set-Cookie header is sent with Secure
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
Changing cookie name, setting sessionCookiePathUsesTrailingSlash or removing HttpOnly has had no effect
I could not find a workaround for this issue except invalidating server session when logged user switch from HTTPS to HTTP.
Finally I opened a bug in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=698839
UPDATED
The issue is finally marked as Won't Fix because it is an intentional change. See https://www.chromestatus.com/feature/4506322921848832
Strict Secure Cookies
This adds restrictions on cookies marked with the 'Secure' attribute. Currently, Secure cookies cannot be accessed by insecure (e.g. HTTP) origins. However, insecure origins can still add Secure cookies, delete them, or indirectly evict them. This feature modifies the cookie jar so that insecure origins cannot in any way touch Secure cookies. This does leave a carve out for cookie eviction, which still may cause the deletion of Secure cookies, but only after all non-Secure cookies are evicted.
I remember seeing this a couple of times and as far as I can remember this was the only recommendation on the matter, as you mentioned:
A possible solution to this might be adding sessionCookiePathUsesTrailingSlash=false in the context.xml and see how that goes.
Some info on the matter from here
A discussion here (same solution)
Hope I didn't confuse the issues and this helps you, let me know with a comment if I need to edit/if worked/if I should delete, thanks!
There is a draft document to deprecate the modification of 'secure' cookies from non-secure origins (submitted by Google). It specifies the recommendations to amend the HTTP State Management Mechanism document.
Abstract of the document:
This document updates RFC6265 by removing the ability for a non-
secure origin to set cookies with a 'secure' flag, and to overwrite
cookies whose 'secure' flag is set. This deprecation improves the
isolation between HTTP and HTTPS origins, and reduces the risk of
malicious interference.
Chrome already implemented this feature in v 52 and same feature is also implemented in Mozilla few days back.
To solve this issue, I think you should connect to website via https only.
The bad way I think is to set sessionCookieName = "JSESSIONIDForHttp" in context.xml
Let Browser's cookie know:
If secure https condition use default "JSESSIONID".
If not secure http condition use "JSESSIONIDForHttp".