1964945 - Nameless cookie can impersonate HttpOnly cookie that has the same domain, host-only-flag, path

Status: RESOLVED DUPLICATE of bug 1964767

(Core :: Networking: Cookies, defect, P2)

Description

[Uku Sõrmus]

Steps to reproduce:

1. Go to https://response.ee/data/SFRUUC8xLjEgMjAwIE9LDQpTZXQtQ29va2llOiBhPWI7IEh0dHBPbmx5OyBTZWN1cmU7IFBhdGg9Lw0KDQo
   This returns the following HTTP response and thus sets an HttpOnly cookie named a.

HTTP/1.1 200 OK
Set-Cookie: a=b; HttpOnly; Secure; Path=/

2. Open devtools; verify that the HttpOnly cookie is set (Storage > Cookies)
3. Try to override the HttpOnly cookie from non-HTTP context by executing the following JS in the devtools Console tab:

document.cookie = "a=X; Path=/"

4. Observe that the cookie is NOT set (Storage > Cookies)
5. Try to impersonate the HttpOnly cookie with a nameless cookie by executing the following JS in the devtools Console tab:

document.cookie = "=a=X; Path=/"

6. Observe that the nameless cookie is set (Storage > Cookies)
7. Make a request by executing the following JS in the devtools Console tab:

fetch("/")

8. Observe that the impersonating cookie is attached to the request (Network tab > click on request > Headers > Request Headers > Cookie), as the Cookie header now has the value a=b; a=X

Actual results:

A cookie with the HttpOnly attribute set can be impersonated by a nameless cookie that has the same tuple (domain, host-only-flag, path), as the serialization of both cookies is the same.

Expected results:

This should be forbidden, as is a workaround for restrictions set by RFC6265bis-20 (see below).

Note that:

• the direct security impact of this particular issue is limited, because attackers can usually impersonate an HttpOnly cookie anyway by changing the Path or Domain attribute (this seems to be intended); there can be some edge cases where the attacker needs the Path to stay the same (e.g. /, because the action is e.g. POST /) and Domain cannot be set, e.g., the host is an IP address, or a public suffix hosting content like uk.com, or an internal hostname
• cookies with the name prefixes __Host- and __Secure- are not impacted by current issue, because of forbidding nameless cookies having a value that starts with such a prefix (also see issues linked below that have sparked this patch to spec & implementations)

This is a scenario not reported under a group of issues related to nameless cookies in: https://issues.chromium.org/issues/40060605

This is also a semi-publicly known fact, from the publicly accessible comment from Mozilla's Daniel Veditz https://bugzilla.mozilla.org/show_bug.cgi?id=1779993#c13 (emphasis mine):

For example, normally an attacker can't overwrite an HttpOnly cookie from a non-HTTP context (e.g. document.cookie), and we don't let a non-secure cookie overwrite a secure cookie. This trick [using nameless cookies] doesn't literally overwrite them, but it can create spoofing copies.

---

Relevant section from RFC6265bis-20 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-20#section-5.7-3.23.1:

23. If the cookie store contains a cookie with the same name, domain, host-only-flag, and path as the newly-created cookie:
1. Let old-cookie be the existing cookie with the same name, domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.)
2. If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps and ignore the newly created cookie entirely.

---

Firefox Nightly 140.0a1 (2025-05-02) (64-bit)

Comment 1

[Daniel Veditz [:dveditz]]

I don't see how this isn't a duplicate of bug 1964767. The impersonated cookie in the PoC has different attributes, but the target cookie's attributes are irrelevant. The underlying bug is "a nameless cookie with '=' in the value can impersonate a named cookie".

Comment 2

[Uku Sõrmus]

I filed these two separately because of different assumptions in different steps in RFC6265bis-20 that they break:

• this current bug here (1964945) about HttpOnly breaks assumptions of step 23 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-20#section-5.7-3.23.1
• the other bug (1964767) about Secure breaks assumptions of step 16 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-20#section-5.7-3.16.1

For example, according to the algorithm outlined in these steps:

• if there's an HttpOnly cookie on /, it is OK to create an otherwise same, non-HttpOnly cookie on /foo (paths are not exact match => OK)
• if there's a Secure cookie on /, it is NOT OK to create an otherwise same, non-Secure cookie from insecure connection on path /foo (the path of the newly-created cookie path-matches the path of the existing cookie => NOT OK)

Hence the fixes would touch different checks in code.

But if there's going to be a more general fix to end this nameless cookie misery (to spec, Firefox, or both), I guess the issues can be safely merged :-)