move (and re-org) V3.4 cookies

[elarlang]

V3 is now getting scoped to have session functionality without being dependent on any technical solution - such as cookies or any-kind-of-token.

We are going to move V3.5 away. If we leave V3.4 Cookies, then it may feel like it is the only acceptable solution for session managament - so part of the moving away V3.5 is also moving away V3.4.

Another reason is, that V3.4 by content belong clearly to front-end security. Also, cookies as technology is wider topic than only managing session cookies.

For both moved away section - we need to provide strong link - if you use this mechanism for your sessions, take a look / take into scope that section etc.

edit: proposal is to move V3.4 into V50 Web Frontend Security.

---

Requirements as they are at the moment:

#	Description	L1	L2	L3	CWE
3.4.1	Verify that cookie-based session tokens have the 'Secure' attribute set.	✓	✓	✓	614
3.4.2	[MODIFIED] Verify that cookie-based session tokens are not readable by client-side scripts. The session token cookie should have the 'HttpOnly' attribute set and the session token value should only be transferred to the client via the Set-Cookie header field.	✓	✓	✓	1004
3.4.3	Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.	✓	✓	✓	1275
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

Requirements should be written to be "need specific". The struggle here is, if to make cookie requirements more abstract, how to send a clear set of rules that are expected for session cookie.

To just describe or validate the idea, changed requirements:

#	Description	L1	L2	L3	CWE
3.4.1	Verify that cookies have the 'Secure' attribute set.	✓	✓	✓	614
3.4.2	Verify that if the cookie is not meant to be for client-side scripts (such as cookie for session token), the cookie must have the 'HttpOnly' attribute set and the same value (e. g. session token) must only be transferred to the client via the Set-Cookie header field.		✓	✓	1004
3.4.3	Verify that cookies have the 'SameSite' attribute set according to the purpose of the cookie. For example, if the cookie is not meant to be sent from cross-site party, it must have SameSite attribute with value Lax or Strict to limit exposure to cross-site request forgery attacks.		✓	✓	1275
3.4.4	Verify that if the cookie is meant to be used only by the same host, the cookie has "__Host-" prefix for the cookie name.		✓	✓

---

Additional requirement (or coverage) proposal: Partitioned attribute for cookies:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#partitioned
• https://developer.mozilla.org/en-US/docs/Web/Privacy/Privacy_sandbox/Partitioned_cookies
• https://caniuse.com/mdn-http_headers_set-cookie_partitioned

[tghosth]

Do you want to open a PR or should I comment on the wording first?

[randomstuff]

Additional potential cookie requirements/considerations (not a wording proposition):

• Authentication and/or encryption of the cookie content (when the cookie is self-contained and its content must be protected). Basically the considerations of V3.5 should apply to cookies as well when it makes sense (this is not necessary if the cookie is storing my preferred theme). Do we just need to say "Note that the requirements for self-encoded token apply for the cookie content when the cookie if self-encoded"?
  • eg. Flak sessions by default are implemented by a MAC-ed self-encoded cookie. They are protected by a MAC (and include a timestamp) but are not encrypted which means that the session content can be inspected by the user.
• Entropy of the cookie when it is a reference cookie (see Add requirements for random value entropy #2411).
• For self-encoded cookie make sure that the user cannot do bad things by replaying old cookies.
  • eg. Flask sessions are by default implemented by a MAC-ed self-encoded cookie. This means that if someone manages to steal your session cookie logging out won't help because the cookie will still be valid for some time. Moreover if for example you session contains a limit (eg. max number of attemps for some action), you can "rewind" the previous state to bypass the limit.

[randomstuff]

so part of the moving away V3.5 is also moving away V3.4.

Do you intend to move V3.4 into the same chapter as V3.5? Or do you intent to have separate chapters?

[elarlang]

Response to @tghosth

Do you want to open a PR or should I comment on the wording first?

The first layer is to get feedback on the idea. If the direction is agreed upon, then we can talk about wording. Given wordings are just a bit random wording to show that cookies do not need to be session-specific.

---

Response to @randomstuff

In short - I watch cookies as a separate information-transfer technology, it is not related to any specific functionality and I have a feeling, that your proposed requirements are more specific functionality-related and not cookie-related. Using the same logic, I proposed to move away V3.5 from sessions, because it is a separate, independent, and underlying technology.

so part of the moving away V3.5 is also moving away V3.4.

Do you intend to move V3.4 into the same chapter as V3.5? Or do you intend to have separate chapters?

No, if agreed, then cookies will be moved to V50 - those requirements are valid only if browser is involved.

Authentication and/or encryption of the cookie content (when the cookie is self-contained and its content must be protected).

I don't think we need to duplicate this part to cookies. If the content is self-contained, you need to validate it the same for every delivery method.

Entropy of the cookie when it is a reference cookie

Cookies do not require entropy. Maybe the session identifier does, but the cookie is just an underlying technology that transfers the information.

For self-encoded cookie make sure that the user cannot do bad things by replaying old cookies.

We can not have a requirement of "do not replay a cookie". It must be the content in the cookie and probably belong to some more specific section.