Cookie jar accepts Secure/__Host-/__Secure- cookies from non-secure origins in HTTP.jl

Description

setcookies! stored every parsed Set-Cookie after only checking that the response scheme was http or https, with no protection symmetric to the read path (shouldsend, which already withholds Secure cookies from non-secure requests). A plaintext (http) origin could therefore plant a Secure cookie, plant a __Secure-/__Host--prefixed cookie, or overwrite/delete (via Max-Age=-1) an existing Secure cookie set over https, enabling cookie fixation against hosts that mix http and https.

Impact

A network attacker or malicious http origin could set, overwrite, or delete security-sensitive cookies in the client's cookie jar, enabling cookie fixation.

Patches

Fixed in HTTP.jl v2.4.0. Per RFC 6265bis, setcookies! now drops any Secure cookie arriving over a non-secure scheme, enforces the __Secure- and __Host- name prefixes (evaluated ASCII case-insensitively on the raw attributes), and refuses to overwrite or delete an existing Secure cookie of the same domain;path;name identity from a non-secure origin. Behavior over https is unchanged.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.