Impact
The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only Secure handling is on retrieval, where a Secure cookie is not sent over plaintext.
So anyone who can answer a plaintext request to a site can set, replace or delete the site's Secure cookies, and the next HTTPS request carries the attacker's value back inside TLS:
http://example.com -> Set-Cookie: SID=attacker-value; Secure; Path=/
https://example.com -> Cookie: SID=attacker-value
This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:
http://insecure.example.com -> Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/
https://bank.example.com -> Cookie: SID=attacker-value
A plaintext Set-Cookie of the same name, domain and path overwrites a Secure cookie, and one with Max-Age=0 deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.
Affected versions
- 3.x: up to and including 3.0.13
- 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1
Patches
Fixed in 3.0.14 on the 3.x line. A cookie with the Secure attribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete a Secure cookie.
When several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host's own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own.
Plaintext requests to localhost, or to an address literal that is a loopback address, count as secure, so a development server that sets Secure cookies over http://localhost gets them back. This is limited to the cookies such a server set itself: a Secure cookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as 127.0.0.256, and names under localhost are not treated as loopback, because the client resolves them as names.
The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.
Workarounds
Do not share one CookieStore between plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it.
Details
ThreadSafeCookieStore.add(Uri, Cookie) reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. get(Uri) does read it, but only to leave Secure cookies out of plaintext requests.
A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext SID for Path=/ is legitimately stored beside a Secure SID for Path=/account, and both match a request under /account. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (RequestBuilderBase.addCookieIfUnset), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it.
The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a __Host- cookie name prefix prevents that, and the client does not enforce cookie name prefixes.
Attribution
AI-assisted tools were used to support discovery and analysis.
References
Impact
The cookie store ignores the scheme a
Set-Cookiearrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with theSecureattribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The onlySecurehandling is on retrieval, where a Secure cookie is not sent over plaintext.So anyone who can answer a plaintext request to a site can set, replace or delete the site's
Securecookies, and the next HTTPS request carries the attacker's value back inside TLS:This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:
A plaintext
Set-Cookieof the same name, domain and path overwrites a Secure cookie, and one withMax-Age=0deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.Affected versions
Patches
Fixed in 3.0.14 on the 3.x line. A cookie with the
Secureattribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete aSecurecookie.When several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host's own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own.
Plaintext requests to
localhost, or to an address literal that is a loopback address, count as secure, so a development server that setsSecurecookies overhttp://localhostgets them back. This is limited to the cookies such a server set itself: aSecurecookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as127.0.0.256, and names underlocalhostare not treated as loopback, because the client resolves them as names.The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.
Workarounds
Do not share one
CookieStorebetween plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it.Details
ThreadSafeCookieStore.add(Uri, Cookie)reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie.get(Uri)does read it, but only to leaveSecurecookies out of plaintext requests.A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext
SIDforPath=/is legitimately stored beside a SecureSIDforPath=/account, and both match a request under/account. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (RequestBuilderBase.addCookieIfUnset), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it.The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a
__Host-cookie name prefix prevents that, and the client does not enforce cookie name prefixes.Attribution
AI-assisted tools were used to support discovery and analysis.
References