Browsers ignore Set-Cookie response header if we try to set a cookie which was Secure before

Question

I've found a weird issue and have no clue what workaround needs to be applied.

One of the easiest security improvements is to set all cookies as HttpOnly and Secure. I know that if you open a web-site with a Secure cookie in non-secure mode (i.e. the scheme is HTTP) then the cookie is ignored. But our case is the following.

Let's say there is a URL which can log you in: contoso.com/AutoLogin/

If I open it in HTTPS-mode then the AUTH cookie is set and it's secure:

GET https://contoso.com/AutoLogin/<user token>
Response: Set-Cookie: .ASPXAUTH=<cookie is here>; expires=Fri, 11-Oct-2019 14:51:40 GMT; path=/; secure; HttpOnly

That's absolutely fine. I can see the cookie in Dev Tools. Now, the same browser session and I'm trying to open the same URL but in HTTP-mode. Request Cookies do not have AUTH cookie anymore - that's clear and predicted due to the nature of Secure cookies.

GET http://contoso.com/AutoLogin/<user token>
Response: .ASPXAUTH=<here comes the cookie>; expires=Fri, 11-Oct-2019 14:54:07 GMT; path=/; HttpOnly

• no Secure flag this time - OK.

However, the cookie is not set and all subsequent requests do not have the AUTH cookie. Confirmed the behavior at least in Chrome and Firefox (didn't check in other browsers).

As you might noticed the back-end is implemented using ASP.NET MVC. Perhaps, the fact that GET requests are AJAX requests might be helpful.

Thanks for your help.

Answer 1

I found i perfect article about this problem. In short:

This situation happens when website serves requests over both http (port 80) and https (port 443) and has a secure flag for https cookies.

If user comes to https first, site sets secure cookie. Then, with request to any non-secured script, server receives no session cookie since request travels through non-https connection. If the endpoint has session mechanism, it starts new session which is sent via header but not stored in browser (since the browser already has this cookie with this name - it just does not send it)

Author states for different browser behaviour - some browsers allow overriding of secured cookies via unsecured ones, some not.

Both Chrome 71, and Firefox 64 prevent a secure cookie from being overwritten on plain http. I tested Edge 42 and it does not work the same way, it will overwrite the secure cookie with the non-secure cookie. Safari 12 works similar to Edge.

I guess the only solution is to use website only one desired way - secured or not.