You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am reporting on some inconsistencies discovered while researching browser/server compliance with rfc6265bis.
rfc6265bis-04 changed the cookie parsing algorithm to support nameless cookies, i.e., Set-Cookie: token should create a nameless cookie with value token. The commit that introduced the change is 0178223, which followed the discussion at #159.
The relevant parts are in Section 5.4: The Set-Cookie Header Field, point 3.
If the name-value-pair string lacks a %x3D ("=") character, then
the name string is empty, and the value string is the value of
name-value-pair.
Otherwise, the name string consists of the characters up to, but
not including, the first %x3D ("=") character, and the (possibly
empty) value string consists of the characters after the first
%x3D ("=") character.
If the cookies' name is not empty, output the cookie's name
followed by the %x3D ("=") character.
If the cookies' value is not empty, output the cookie's
value.
If there is an unprocessed cookie in the cookie-list, output
the characters %x3B and %x20 ("; ").
Conflict with the BNF syntax
These changes seem to be incompatible with the Set-Cookie BNF syntax in Section 4.1.1, where the = symbol is considered mandatory in the cookie-pair definition: cookie-pair = cookie-name BWS "=" BWS cookie-value.
Inconsistent browser behavior
According to my tests, recent versions of Chrome and Firefox follow the latest rfc6265bis, while Safari deviates from the intended behavior. Setting a cookie via document.cookie = "test" on example.com results into the following:
Browser
Cookie Name
Cookie Value
document.cookie getter
HTTP request header
Chrome
test
'test'
Cookie: test
Firefox
test
'test'
Cookie: test
Safari
test
'test='
Cookie: test=
Client/Server confusion: cookie tossing
Major server-side programming languages and web development frameworks are not compatible with nameless cookies as specified in rfc6265bis. For instance, PHP and Flask-based applications would treat the request header Cookie: test as a cookie named test with an empty value.
This discrepancy between browsers and servers has real-world security implications. Consider a site at https://example.com that relies on the integrity of __Host- cookies to, e.g., implement CSRF protections:
Assume that https://example.com sets the cookie __Host-xsrf=foo
An attacker controlling http://sub.example.com (either directly or via an XSS) sets a cookie in the victim's browser via document.cookie = '__Host-xsrf; Domain=example.com; Path=/folder'
Subsequent requests to https://example.com/folder will contain the HTTP request header Cookie: __Host-xsrf; __Host-xsrf=foo
The PHP backend will populate the $_COOKIE associative array as Array([__Host-xsrf] => ), effectively ignoring the legitimate cookie in favor of the malicious one.
The attack flow described above defeats double-submit CSRF protections relying on __Host- cookies for additional security against same-site attackers.
Notice that:
Safari is not affected by this attack since the restrictions of cookie name prefixes apply
PHP seems to reject nameless cookies in the form Cookie: =foo
Proposed solution
Difficult to say since there are discrepancies at multiple levels (specs, browsers, servers). If nameless cookies must be supported for backward compatibility, the specification could mandate the presence of the = symbol in the name-value-pair produced by the retrieval algorithm. This change should hopefully make the Cookie header easier to parse, clarifying potential ambiguities at the server-side.
The text was updated successfully, but these errors were encountered:
lavish
changed the title
Nameless cookies, client/server inconsistencies
[rfc6265bis] nameless cookies, client/server inconsistencies
Aug 8, 2022
Thank you for your (well researched) issue. As you've found out, nameless cookies are quite the footgun.
These changes seem to be incompatible with the Set-Cookie BNF syntax in Section 4.1.1
Section 4 describes what a well behaved server should do. Unfortunately not every server is well behaved which is why Section 5 describes a parsing algorithm that accepts it. #1018
Inconsistent browser behavior
I'm not sure if this is intentional, #159 (comment) is ambiguous and I don't have access to the radar issue. @johnwilander What was the intended implementation?
Client/Server confusion: cookie tossing
This is a big problem when it comes to cookie prefixes. I can say that Chrome is already aware and has a fix in the works.
Proposed solution
Yep, this isn't an easy problem to solve.
Nameless cookies are a footgun and servers are strongly advised to never use them or accept them.
There was a previous discussion around appending all nameless cookies with = but such a sweeping change is likely to cause breakages and was rejected.
I realized another (more severe) security implication. To avoid disclosing the issue publicly, I filed 2 identical reports to Firefox (#1783982) and Chrome (#1351601). Safari does not seem to be affected.
I am reporting on some inconsistencies discovered while researching browser/server compliance with rfc6265bis.
rfc6265bis-04 changed the cookie parsing algorithm to support nameless cookies, i.e.,
Set-Cookie: token
should create a nameless cookie with valuetoken
. The commit that introduced the change is 0178223, which followed the discussion at #159.The relevant parts are in Section 5.4: The Set-Cookie Header Field, point 3.
And in Section 5.6.3: Retrieval Algorithm, point 4.
Conflict with the BNF syntax
These changes seem to be incompatible with the Set-Cookie BNF syntax in Section 4.1.1, where the
=
symbol is considered mandatory in thecookie-pair
definition:cookie-pair = cookie-name BWS "=" BWS cookie-value
.Inconsistent browser behavior
According to my tests, recent versions of Chrome and Firefox follow the latest rfc6265bis, while Safari deviates from the intended behavior. Setting a cookie via
document.cookie = "test"
onexample.com
results into the following:document.cookie
gettertest
'test'
Cookie: test
test
'test'
Cookie: test
test
'test='
Cookie: test=
Client/Server confusion: cookie tossing
Major server-side programming languages and web development frameworks are not compatible with nameless cookies as specified in rfc6265bis. For instance, PHP and Flask-based applications would treat the request header
Cookie: test
as a cookie namedtest
with an empty value.This discrepancy between browsers and servers has real-world security implications. Consider a site at https://example.com that relies on the integrity of
__Host-
cookies to, e.g., implement CSRF protections:https://example.com
sets the cookie__Host-xsrf=foo
http://sub.example.com
(either directly or via an XSS) sets a cookie in the victim's browser viadocument.cookie = '__Host-xsrf; Domain=example.com; Path=/folder'
https://example.com/folder
will contain the HTTP request headerCookie: __Host-xsrf; __Host-xsrf=foo
$_COOKIE
associative array asArray([__Host-xsrf] => )
, effectively ignoring the legitimate cookie in favor of the malicious one.The attack flow described above defeats double-submit CSRF protections relying on
__Host-
cookies for additional security against same-site attackers.Notice that:
Cookie: =foo
Proposed solution
Difficult to say since there are discrepancies at multiple levels (specs, browsers, servers). If nameless cookies must be supported for backward compatibility, the specification could mandate the presence of the
=
symbol in the name-value-pair produced by the retrieval algorithm. This change should hopefully make theCookie
header easier to parse, clarifying potential ambiguities at the server-side.The text was updated successfully, but these errors were encountered: