Case sensitive matching of the `__Secure-` and `__Host-` cookie prefixes leads to bypasses for insecurely implemented servers

[ddworken]

Cookie names are case-sensitive, which means that Foo and foo are different cookies. Many frameworks incorrectly treat cookie names as case-insensitive. This is a bug, but a seemingly common one (see below). This incorrect behavior is generally not noticed or not promptly fixed because it is unlikely that a service would have both a Foo and a foo cookie.

But the way that this buggy behavior interacts with cookie prefixes leads to a bypass of the protections offered by cookie prefixes. Specifically, suppose that a service uses a cookie __Secure-foo and relies on this cookie having the secure flag and being set by a secure page. An attacker can then set the cookie __secure-foo cookie without the secure attribute. This will be seen by a buggy backend as equivalent to a __Secure-foo cookie, thereby bypassing the protection that they were aiming to achieve.

It seems to me like this would be a relatively easy tweak to make to the spec. We could change it so that cookie prefixes are case-insensitive so that __Secure-foo and __sECuRe-foo are both treated as having the prefix (but are otherwise treated as different cookies). Cookie attributes are case-insensitive, so it makes sense to me that prefixes could be treated the same way.

As evidence of this being a common mistake, see:

• https://github.com/dotnet/runtime/issues/62778
• https://github.com/dart-lang/sdk/issues/11011
• https://docs.oracle.com/javase/8/docs/api/java/net/HttpCookie.html#equals-java.lang.Object-
• https://github.com/laravel/framework/issues/1639
• https://github.com/curl/curl/commit/0336a548f1d969aae5fc92ce22ad177a36f971fc