search

OWASP / ASVS

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

v3.2.1 identifier rotating for a stateless mechanism #2112

Closed tghosth closed 3 weeks ago

tghosth commented 1 month ago

This requirement says:

# Description L1 L2 L3 CWE NIST §
3.2.1 [MODIFIED] Verify the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. ✓ ✓ ✓ 384 7.1

How should this requirement be applied for a stateless mechanism?

tghosth commented 1 month ago

@ryarmst

elarlang commented 1 month ago

This requirement is for mitigating session fixation. If you generate a stateless token, it satisfies the requirement "by design".

Token can be also just a "package" for delivering the session identifier information.

tghosth commented 1 month ago

So do you think this chapter would be better structured as stateful and stateless? @elarlang

elarlang commented 1 month ago

Personally, I think there must be a clear definition, of what we mean by the word "Session". If for some people "Session" means one thing and for another something else, there can not be any agreement and understanding on that.

I feel we are going in the wrong direction here. Too often I can see people talking about a "stateless state" and over-engineering simple things to be fancy and using the latest technology, which they actually don't need to use. The problems to address are written here: https://github.com/OWASP/ASVS/issues/1790

If this is clear, then we can decide, how to divide requirements to different chapters. By concept, the requirement "to avoid session fixation" is valid in any section.

ryarmst commented 1 month ago

I think to the extent possible, requirements should focus on what should be expected (required) of a secure system regardless of the precise implementation approach/details (stateful vs. stateless, for example). I agree with @elarlang that the first step should be shared definitions (hence #2100).

Regarding 3.2.1, my instinct is that the requirement is best not to distinguish between mechanism types. As a side note: I think the requirement can mitigate more than session fixation (though they would be rather obscure attacks).

I am still putting together thoughts (in conjunction with ongoing discussion) around organization of V3 broadly, but I think consensus should be reached on a few items first.

TLDR: I think the requirement is OK as is.

tghosth commented 1 month ago

Any further action here @elarlang @ryarmst or should I close?

elarlang commented 1 month ago

At this point I can not see the need for further action.