AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS

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.