New issue
Advanced search Search tips

Issue 698839 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Mar 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Set-Cookie response header does not supersede the old cookie if "Secure" is set

Reported by pedro.fe...@aralink.com, Mar 6 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. The server returns a set-cookie header using HTTPS

    Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

2. User connects with HTTP, the server returns a set-cookie header with the same cookie name (Secure is missing)

    Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

What is the expected behavior?
In both cases, the cookie should be set

What went wrong?
In the second case, the cookie is not set

See RFC2109 (https://www.ietf.org/rfc/rfc2109.txt) 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 ookie, the new cookie supersedes the old."

Did this work before? Yes 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 10.0
Flash Version: 

It works according to RFC in Firefox and Edge

Comment 1 by mef@chromium.org, Mar 6 2017

Components: Internals>Network>Cookies
Status: WontFix (was: Unconfirmed)
In your example first cookie is named JSESSIONID and second is named SESSIONID, but I assume that this is a typo. 

This is working as intended, and secure cookies are set separately from insecure to avoid possibility of attacker replacing secure cookie by setting one on insecure connection.

Comment 2 by jsre...@gmail.com, Mar 8 2017 

Facing an issue when storing a cookie in secure and insecure mode.

Lets say I access a secure URL which returns back a secure session cookie. The secure cookie is persisted and it is sent for further requests. Now, connect to the same URL in non-secure mode. The secure cookie is not sent (correct behavior), and the server now sends back the same cookie, but without secure flag set (since its an insecure call). In this case, the insecure cookie is not persisted and further calls do not send the cookie.

Switching back to secure url send the older secure cookie, which confirms that the secure cookie is still present and is stored separate.

Comment 3 by elawrence@chromium.org, Apr 12 2017 

Re #2: This is an intentional change; see https://www.chromestatus.com/feature/4506322921848832
►

Sign in to add a comment