Adding a sequence diagram showing how one attack scenario can exploit this to bypass a CSRF defence based on double-submit cookies (verified with an AngularJS app and csurf middleware in cookie-mode on Node.js)

Deleted: mitm-set-cookie-sequence.png 89.5 KB

	mitm-set-cookie-sequence.png 89.5 KB View Download

https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01

Launch bug: https://bugs.chromium.org/p/chromium/issues/detail?id=568188 suggests that this should be on-by-default as of Chrome 58:

commit a26e439d02baa9514b09c63 was:
  initially in 58.0.2995.0

The status page: https://www.chromestatus.com/feature/4506322921848832 notes that this feature was enabled behind a flag in Chrome 52.

Can you try reproducing your issue on the latest Chrome Unstable build?

I'm not able to reproduce the finder's report on Chrome 59 using this demo: https://fiddlerbook.com/test/cookie/LeaveSecureAlone.aspx

Just tried on Chrome Version 58.0.3029.19 dev (64-bit), and it's true that I no longer can set the cookie on a more specific path, so it seems fixed in that regard.

However, I discovered that the opposite is possible, e.g., if the secure cookie is set for Path=/submit, I am able to later set a cookie with the same name for Path=/ from a non-secure origin. Attached a screenshot showing these.

Note that this also applies to the stable release (56.0.2924.76) mentioned in the initial report. Although this may not be as severe since the secure cookie would take precedence for the specific path it was set, I'm still not sure if this is the intended behavior or a bug?

Deleted: chrome_unstable_cookie_shadowing.png 18.2 KB

	chrome_unstable_cookie_shadowing.png 18.2 KB View Download

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

FWIW, Firefox appears to do the same in this case, e.g., a broader path attribute can be specified for a cookie from a non-secure origin for an existing secure cookie having a more specific path.

I believe this is working as expected. From the spec:

  4.  The "path" of the newly created cookie path-matches the
      "path" of the existing cookie.

  Note: The "path" comparison is not symmetric, ensuring only
  that a newly-created non-secure cookie does not overlay an
  existing secure cookie, providing some mitigation against
  cookie fixing attacks.  That is, given an existing secure
  cookie named "a" with a "path" of "/login", a non-secure
  cookie named "a" could be set for a "path" of "/" or "/foo",
  but not for a "path" of "/login" or "/login/en".

In Chrome's code:

// Checks a looser set of equivalency rules than 'IsEquivalent()' in order
// to support the stricter 'Secure' behaviors specified in
// https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone#section-3
//
// Returns 'true' if this cookie's name matches |ecc|, and this cookie is
// a domain-match for |ecc| (or vice versa), and |ecc|'s path is "on" this
// cookie's path (as per 'IsOnPath()').
//
// Note that while the domain-match cuts both ways (e.g. 'example.com'
// matches 'www.example.com' in either direction), the path-match is
// unidirectional (e.g. '/login/en' matches '/login' and '/', but
// '/login' and '/' do not match '/login/en').
bool IsEquivalentForSecureCookieMatching(const CanonicalCookie& ecc) const;

I agree, it is working as expected in Chrome 58+, no fix required. 

My report originated in a misunderstanding that strict secure cookies was enabled in Chrome 52+, but the updates on https://www.chromestatus.com/feature/4506322921848832 now makes it clear that it's enabled from 58.