V50.2.4 (v4.0.3-3.4.4) - cookie __Host- name prefix

[elarlang]

Current requirement, moved from V3.4.4 to V50.2.4 via #2410:

#	Description	L1	L2	L3	CWE
50.2.4	[MOVED FROM 3.4.4] Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie.	✓	✓	✓	16

As the requirement is now a general cookie security requirement, the wording must be non-session-cookie specific.

Proposal:

Verify that if the cookie is meant to be used only by the same host from where it is written, the cookie has the "__Host-" prefix for the cookie name.

updated proposal from #2422 (comment)

Verify that the cookie has the '__Host-' prefix for the cookie name unless it is explicitly designed to be shared with other hosts.

level: from easy to implement point of view, level 1. can be level 2

[randomstuff]

Alternative "stronger" wording:

Verify that the cookie has the "__Host-" prefix for the cookie name unless it is (explicitly) designed to be shared with other hosts.

Optional sentence at the end of the requirement:

In this case, it must have the "__Secure-" prefix instead.

If we don't include this extra sentence, we should probably have a requirement which says "user either __Host- or __-Secure-".

[elarlang]

I don't agree with that. Those prefixes are different things and address different problems

• __Host- avoid competitive cookies (over)written from same-site scope
• __Secure- basically enforce the usage of Secure attribute

[randomstuff]

Yes, I agree they serve different purpose. If you want to be strict about the goal of each requirement you should have the following requirements:

1. protect from https://other-host-name → "use __Host- unless you are sure you need to you cookie to be used cross-host"
2. protect from http://same-host-name → "use either __Secure- unless you use __Host-"

In both cases, this is about protecting from other origins (roughly) overwriting/setting the cookie in our stead.

Then maybe "__Secure-" is not that useful if HSTS is used …

[randomstuff]

I don't agree with that.

What about the first (main) part? (Verify that the cookie has the "__Host-" prefix for the cookie name unless it is (explicitly) designed to be shared with other hosts.)

[randomstuff]

__Secure- basically enforce the usage of Secure attribute

It prevents an adversary from setting the cookie from http:. This is not a problem when using HSTS unless the cookie is set before the browsers sees the HSTS.

[elarlang]

__Secure- basically enforce the usage of Secure attribute

It prevents an adversary from setting the cookie from http:. This is not a problem when using HSTS unless the cookie is set before the browsers sees the HSTS.

it can be still a problem when HSTS is not set to the main domain. Then any site from the eTLD+1 scope can write a cookie with the same name to the main domain which makes the cookie valid for everything in the same-site scope. Including when someone serves http: service from own-controlled network.

But it is not the topic for __Host-, it is for Secure. __Secure- can be part of 50.2.1 (#2419).

[randomstuff]

For me both "__Host-" and "__Secure-" prefixes are about making sure that adversaries do not define/overwrite the cookie for us and should be together in 50.2.4.

On the other hand, 50.2.1 would be about making sure that the data stored in the cookie is not exfiltrated. The "__Secure-" prefix does not help with that (the Secure attribute alone does).

But I can live with "__Secure-" being discussed in 50.1.2 😄

[elarlang]

For me both "__Host-" and "__Secure-" prefixes are about making sure that adversaries do not define/overwrite the cookie for us and should be together in 50.2.4.

__Secure- prefix does not provide that.

On the other hand, 50.2.1 would be about making sure that the data stored in the cookie is not exfiltrated. The "__Secure-" prefix does not help with that (the Secure attribute alone does).

They are not the same. __Secure- vs Secure :

• Secure - this cookie is can not be written and later sent over http: connection, but you can (over)write existing cookie (key: name+domain/host+path) without setting the Secure flag from http: connection (see V50.2.4 (v4.0.3-3.4.4) - cookie __Host- name prefix #2422 (comment))
• __Secure- - is it requires Secure to be set, it has the same as Secure PLUS - you can not write the cookie with __Secure- from http: connection.

If there is further need to explain those, I'll invite you to my training ;)

[randomstuff]

Note that "__Host-" prevents binding the cookie to a subpath.

Some people might want to support cookies bound to paths:

1. in order to have different cookies for different paths (eg. Keycloak uses Path=/realms/myrealm/ to scope each session cookie to its own realm);
2. in order to have different applications under the same host (and somehow hope they you will be able to isolate them this way → this does not work).

I don't think there are good reasons for not using __Host- because:

• For (1), use could include some info about the realm in the cookie name instead.
• For (2), your should probably not do that in the first place.
• The added value of __Host is important enough and can only be achieved this way.

To be clear, I still think this should be required but I am raising this point here for reference (and to let the opportunity to express a different opinion).

[elarlang]

Yes, __Host- provides that you can not write so-called competitive cookie (a cookie with the same name valid to the same scope) choosing different path or domain values. This is something that __Secure- does not provide.

For that reason, those Keycloak cookies are manipulatable from any site from the same-site scope. And for that reason I proposed:

V50.1.1 Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies.

[Sjord]

but you can (over)write existing cookie

It is no longer possible to overwrite an existing secure cookie.

In this case, it must have the "__Secure-" prefix instead.

I agree. I think it makes sense to put both prefixes in one requirement. __Host has the behavior of __Secure and more, and it is not possible to include both prefixes. So all cookies should have either the __Secure or __Host prefix.

[elarlang]

but you can (over)write existing cookie

It is no longer possible to overwrite an existing secure cookie.

Re-checked, that's correct. But you can still write a cookie with the same name to valid for the same request. That is the reason to use __Host-.

In this case, it must have the "__Secure-" prefix instead.

I agree. I think it makes sense to put both prefixes in one requirement. __Host has the behavior of __Secure and more, and it is not possible to include both prefixes. So all cookies should have either the __Secure or __Host prefix.

The only duplicating behavior is that you can not write a cookie with the same name from http: connection.

[tghosth]

Verify that the cookie has the '__Host-' prefix for the cookie name unless it is explicitly designed to be shared with other hosts.

I think this makes sense to me

Grammar:
Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts.