I have one strange issue, one of the site I have developed returns Anti-Forgery cookie while requesting login page. When I check response in chrome network tab it contains header
Set-Cookie: .AspNetCore.Antiforgery.w5W7x28NAIs=xxx; path=/; samesite=strict; httponly
But when I check cookie value in Application tab (Under cookie section), I cant find any cookie set in browser. I have also checked cookies with chrome extensions like EditThisCookie but it is also not displaying there.
Network Tab:
Application Tab:
Am I missing some simple thing, or this is some kind of chrome (Version 66.0.3359.181 (Official Build) (64-bit)) bug?
I've got similar issue, solved it by setting withCredentials = true for every requests.
For angular, this basically means:
this.http.get(url, { withCredentials: true });
Related
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 have three applications in my solution, all built in asp.net core 1 MVC 6.
App 1 is an MVC app used for authenticating a user.
App 2 is an Angular SPA app and is the main app in the solution.
App 3 is an MVC web api application.
In app 3, I have the usual asp.net core SignInManager and UserManager code (the same code as you get by default when you start a new MVC 6 template - only different is, it exists in my web api here). And the login/logout/register etc is exposed via web api methods in my AccountController. This allows me to lock down the web api, so only authenticated requests get processed (using the [Authorize] attribute).
When I call the "Login" method in my AccountController, if login is successful - it returns a Set-Cookie directive with the following name: ".AspNet.Microsoft.AspNet.Identity.Application" (this is used for authentication)
The login app then forwards the user from App1 to App2. All subsequent requests to the web api (App3) are then Authenticated and allowed to be executed. NOTE: By subsequent requests - specifically I mean, within App2, angular calling to ask for data from the web service.
All of this works fine - well, it works in IE fine. Which brings my to my question, why would this not be working in Chrome? I see the "Set-Cookie" directive coming back from the response of the web api Login in chrome, but subsequent requests do not have this cookie attached.
What am I doing wrong?
NOTE:
My Http Response from the login method looks like this:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Kestrel
Set-Cookie: .AspNet.Microsoft.AspNet.Identity.Application=CfDJ8FWIuvXs-TxKoIYE8259iAY52B_VZDPTTvYwZ-WAo8hhPCdLhmUfxNZD1wjxEt0sqqnZl6NomwHPNTNFkBxsq4cw_WkQYklnj_dK79wodIguLdPXAbKu6UbS6HKRBxFxjOKVAfIdyxZJ6xA2CtnR9nJC_CSg7v1vFSzgDEiSBso8D3aDNjzFk8
7oIJodC7WLVxWUqdUpjaGRCXqHTYjTwgL9DCihnajAlB921_oEPinUwIPP8g_ugCQmqbFq6kgQ-GwPTifBKRlbtwNsDwbetynl1gIqzELyjgEUAKgtpD9SX7FSjl1grxoGRjbPiXJe-k1SSdnUIHR7wYPkFpiis_c_P1pGkmSyeiDG-lf0xftTlXlnC3BWMbgXeWZn_hsDzbW_Tek3qiq_NB-T0IMGaJgjRnr5DARNcOACWbzwGvHFjsn7n0u7-UZOfzgQJ76d3ra-hjra
-aNcHLgbfDef3TK6z_CKt2iIlnTkyEJXC-3OSGnfWDRvofvQ216UApEPiKoJxiCjWSvGAQCzvf9P1TtKuwAQVxfWz8pL077E-Wfc-4ybtrT6Ivz2VbdFng5Ze5IQ5YWfYYTpDhLSHGKnpFgxVf96f7JwoXlgRq0gs7yEWdWFZs6d18pw-El5sLJr7g; path=/; secure; httponly
Access-Control-Allow-Origin: *
X-SourceFiles: =?UTF-8?B?QzpcVXNlcnNcUm9iZXJ0XERlc2t0b3BcSEJFIE1hbmFnZXJcTUFJTlxCbHVlem9uZSBXZWJBcGlcc3JjXEJ6LkFwcGxpY2F0aW9uXEJ6LkFwcGxpY2F0aW9uLkFwaVx3d3dyb290XGFwaVxhY2NvdW50XExvZ2lu?=
X-Powered-By: ASP.NET
Date: Wed, 04 May 2016 10:39:57 GMT
Content-Length: 16
Hi I had this problem too.
While my localhost environment in VS worked fine and my user could be logged in this didn't worked in the published environment for chrome.
This began when I was trying some self-signed-certificate stuff in IIS on my pre-production-environment by turining on https with configured bindings. And after that I went back to http.
What you could try in Chrome is this: Open the developer-tools goto tab Application and in the left pane choose Clear storage. Under the diagram on the right click Clear site data even if the usage shows 0 Bytes used. Do it anyway.
Finally I got my application with login features back.
Hope that this will help someone, too.
In my case, we had a C# ASP.NET Core 2.1 MVC application which was working fine when I launch in Google Chrome. But one fine day it stopped working.
In Google Chrome Developer Tools I saw below
First, I noticed that Application -> Cookies .AspNetCore.Session was missing.
Second, in Console I noticed below warning.
A cookie associated with a resource at
http://myapplication.company.net/ was set with SameSite=None but
without Secure. It has been blocked, as Chrome now only delivers
cookies marked SameSite=None if they are also marked Secure. You can
review cookies in developer tools under Application>Storage>Cookies
and see more details at
https://www.chromestatus.com/feature/5633521622188032.
I did below to fix it.
In our application, in Startup.cs I had like below
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.None;
});
}
We changed like below
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.Strict;
});
}
It solved the issue. I also noticed that in Developer Tools now I can see Application -> Cookies .AspNetCore.Session
I had the same problem, it worked in IE, Edge but not in Chrome, Firefox and Opera.
It seem a cookie size problem, and I solved reducing the data in the cookie.
See this for size limits: chrome cookie size limit
I am working on a spring MVC app and found a strange issue that only happen on chrome. The logic is:
user request a list of items
user click on add new button and a bootstrap dialog popup allow user type in the name
on submit, a post request sent to the server
server create an new item and save it to db
server store the new item id to cookie and send a redirect response to browser
browser request item view page
server pick up the item id from cookie and render the page
The above logic runs good on nearly all browsers (I didn't test on IE) except chrome. I found the root cause is chrome will store previous cookie with a different item id and at step 6 chrome send duplicate item id cookies to the server.
Any idea how to resolve this issue?
Chrome[Version 32.0.1700.41 m Aura]
Opera[Version 20.0.1353.0]
Firefox[Version 29.0a1 (2013-12-10)]
Safari[Version 5.1.7 (7534.57.2)]
No screen capture. But it works
Restart Chrome!
At some point (even today this happened to me) Chrome is getting confused on what cookies a domain has in its memory vs cached on disk. This confusion leads to cookies being added but not removed from what I can tell. In my case, I'm Suspecting McAfee locking files for scanning. Restarting Chrome rebuilds the cache and then works.
https://bugs.chromium.org/p/chromium/issues/detail?id=17855
https://bugs.chromium.org/p/chromium/issues/detail?id=273873
I had something along this stored in my Chrome cookies :
1st cookie : (it was set to expire)
Site : dashboard.app.localhost
Value : access-token=123456; Domain=.app.localhost; Path=/; HttpOnly; SameSite=Strict
2nd cookie : (session cookie that shouldn't be there, I had to dig in the Chrome settings to find it)
Site : dashboard.app.localhost
Value : access-token=invalid; Domain=api.app.localhost; Path=/
Apparently the second cookie appeared due to an error on my side. However, Chrome sent it alongside the first one, creating this header :
Cookie: access-token=invalid; access-token=123456
The solution I found :
Manually delete the second cookie in the Chrome settings.
I try to play some mp3 files via the html5 audio-tag. For the desktop this works great (with Chrome), but when it comes to the mobile browsers (also Chrome (for Android)), there seem to be some difficulties:
I protected the stream with some password an therefore the streaming server needs to find a special authentification cookie (spring security remember-me). But somehow the mobile browser doesn't send this cookie when it accesses the mp3-stream via the audio tag. When I enter the stream URL directly to the address bar everything works just fine.
While I searched for the lost cookie I found out, that the mobile browser still sends some cookies (e.g. the JSESSIONID) but not all. Further investigations (quick PoC with PHP) revealed that the mobile browsern seems to refuse to send cookies via the audio-tag which have the HttpOnly Flag set. So my question is:
Is this a specified behaviour, why are there differences between the mobile and the desktop versions (of Chrome) and is there a way control the behaviour from the client side?
By looking more deeply into the HTTP packages I found out, that the Android browser doesn't request the mp3-stream itself, but delegates this to stagefright (some android multimedia client). A quick search revealed, that for the old Android versions (before 4.0) stagefright cannot handle cookies:
https://code.google.com/p/android/issues/detail?id=17553 <-- (Status: spam) WTF...
https://code.google.com/p/android/issues/detail?id=17281
https://code.google.com/p/android/issues/detail?id=10567
https://code.google.com/p/android/issues/detail?id=19958
My own tests confirmed this. The old stagefright (Android 2.3.x) doesn't send any cookies at all, the stagefright from a european S3 (android 4.1.2, stagefright 1.2) sends only the the cookies which do NOT have the httpOnly flag.
So I think that everybody has to decide himself which solution he wants to use:
enable httpOnly: android has no access at all but its secure
disable httpOnly: less secure against XSS, but works for Android >4.0
disable cookie authentication at all: insecure but works for all
Note: The problem with simply disabling httpOnly is that you make your whole application vulnerable to cookie hijackers. Another possible solution would be to have a special rememberme cookie for the stream (without httpOnly) and another rememberme cookie with httpOnly enabled.
I had the same problem and disabling HttpOnly or Secure flags on cookies didn't solve the problem on Android 4.2 and 4.4 chrome browser.
Finally I figured the cause. I had a cookie with its value containing special characters colon ( : ) and pipe ( | ), etc. After disabling that cookie with special characters the videos play fine in Android 4.2 and 4.4.
Hope this helps someone.