search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.77k stars 671 forks source link

move (and re-org) V3.4 cookies #2410

Closed elarlang closed 1 day ago

elarlang commented 4 days ago

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:

tghosth commented 4 days ago

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

randomstuff commented 4 days ago

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

randomstuff commented 4 days ago

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 commented 3 days ago

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.

randomstuff commented 2 days ago

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.

Yes, I agree. It makes sense to only include cookie-as-a-technology-only considerations in the cookie section and let everything which is about the cookie payload (but could apply as well to other means of transporting the same payload) in other sections.

It would probably deserve to have good references from the cookie section to other important/relevant section. Something as simple as: "See as well section W.X and Y.Z which would usually apply to the cookie payloads."

elarlang commented 2 days ago

It would probably deserve to have good references from the cookie section to other important/relevant section. Something as simple as: "See as well section W.X and Y.Z which would usually apply to the cookie payloads."

Yes, as I wrote in initial issue: https://github.com/OWASP/ASVS/issues/2410#issue-2691931036

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.

But I think the focus for links should be vice versa. In the section text for cookies we can list the classical use-cases (e.g. sessions), but for the technologies or functionalities that are use cookies (again, sessions) as underlying technologies there is need to highlight that "in case you use cookies, you need to take into account cookie section from X.Y"

elarlang commented 1 day ago

I'll move it to V50 as it is after #2384. After that we will discuss each requirement how to have non-session-specific version of it.

elarlang commented 1 day ago

PR #2418 moves requirements from V3.4 to V50.2 as they are. I'll open a separate issue for each requirement separately to find new suitable wording for them.

elarlang commented 1 day ago

List of opened new issues: