-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discourage the use of Stateless Sessions (and therefor the usage of JWT for session) #1790
Comments
To open issue was recommended by me from Slack channel. I duplicate here also worth reading blog post for a starter: I think there we need to be clear to not mix 2 different topics:
Entire point of REST is to be stateless. So the option 1 should have it's own valid use-cases. Option 2 is the problem to solve here. I have seen many times in pen-tests usage of JWT without any need to use it - and then it provides just over-engineering nightmare and extra set of problems. For this, again, there is relatively old blog post to cover that: |
Let's take those requirements - are those actually setting the "no go" for using stateless solution for session?
|
CWE-613, to which they are all linked, is itself setting a no-go for a stateless solution in my opinion. All of these points rely on a central mechanism to revoke or verify the session, but a stateless solution doesn't provide that; in fact it's whole aim is to not have that. So it will cause a violation of all of these points you listed |
From NIST SP 800-63B version 4 (not released) 7.1.2 Access Tokens An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens, MAY be valid long after the authentication session has ended and the subscriber has left the application. |
What is the suggested action at the requirements level here @bitnesswise? We are not going to rule out JWTs although we do need some form of session revocation mechanism. This gets easier if the JWT has a short lifetime. |
The suggested action is pretty much what I described in the issue description: 1) add a section about stateless sessions and what the issues are (@elarlang already listed an overview) and then update 3.5 to point out that if JWTs are used for sessions, it means that without additional mitigations it will have the same issues.
With the proposed changes JWT is not ruled out. But I would explicitly discourage its usage for this purpose, instead of letting the readers come to this conclusion themselves.
It's more than just the revocation mechanism in my opinion. Anyway, I'm not sure that I understand the comment why a short lifetime makes this easier? Did you mean that it becomes less of a risk? And are you suggesting that with a short lifetime it is OK to use? |
Sorry I think I was not clear enough when I said "What is the suggested action at the requirements level here @bitnesswise?" My point was that ASVS is a standard made up of requirements. We cannot easily recommend, discourage or otherwise advise, that is more a job for the Session Management cheatsheet (which to be honest looks like it could do with some love and attention...). What we can do is define requirements of things that app implementers have to do, such as implement allow invalidating sessions or allow a user account to be suspended. As such, my question was more around if there are specific requirement changes you propose. |
Besides requirements, I think the documentation should be clear on terminology. I personally don't agree with the term 'stateless session', but if the rest of the community is happy with that term, it should be explained what it is to avoid confusion. As for requirements:
Personally I think we're putting requirements for something that is broken by design, so I would prefer to discourage this usage, but if that's not possible I guess it's better than nothing :-) |
Require that stateless sessions build state on the server side (so, make them stateful) and adhere to the requirements already pointed out in 3.3. Please note that then it's no longer a stateless session by the definition most people use, but that is part of my issue with using that term.This is the correct term when using JWT’s. All stateless session mechanisms have some state for revocation and more. The entire thing does need to be stateless just the individual token and house services process them. --Jim ***@***.***/manicodeSecure Coding EducationOn Mar 4, 2024, at 2:54 PM, BitnessWise ***@***.***> wrote:
Besides requirements, I think the documentation should be clear on terminology. I personally don't agree with the term 'stateless session', but if the rest of the community is happy with that term, it should be explained what it is to avoid confusion.
As for requirements:
Require that stateless sessions build state on the server side (so, make them stateful) and adhere to the requirements already pointed out in 3.3. Please note that then it's no longer a stateless session by the definition most people use, but that is part of my issue with using that term.
Address other concerns that might be the result of implementing JWT for sessions. I've seen ASVS point out possible issues that need to be verified in other places, that should be done here as well:
a. Verify that the JWT is not stored in a place where javascript can access it
b. Verify that the JWT does not contain personal data
c. Verify that the application still has a short session-timeout (due to inactivity) that is appropriate for the application.
In my experience these are the most important issues I often see implemented wrong.
Personally I think we're putting requirements for something that is broken by design, so I would prefer to discourage this usage, but if that's not possible I guess it's better than nothing :-)
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
I proposed (#1917) to clean-up entire "V3.5 Token-based Session Management" as there is nothing session-specific there.
I think this part is covered in general with section "V3.8 Session Termination" It is not possible to achieve session termination without revoking the mechanism. There is also a line now: For stateful session mechanisms, this should just require invalidating the session at the backend. If a stateless session mechanism with signed tokens is being used, a way to revoke these tokens will be needed.
2.a - for SPA we can not require it In case #1917 finds support and V3.5 gets cleaned up, I think it is more clear. |
Some more quotes to the discussion from https://oauth.net/articles/authentication/ . Worth reading in full, but I point out one section from
|
In translation - I'm not going against JWT, but I want to send a clear message to not use access token as session token or OAuth as replacement for the session management. |
In translation - I'm not going against JWT, but I want to send a clear message to not use access token as session token or OAuth as replacement for the session management.
I hear you Elar and agree with that statement 100%. Thank you! 👍🏼
|
I want to propose two changes/additions in chapter 3 about Session Management:
Personally I'm not so happy about the term Stateless Session as I (personally) think a session is always stateful, but it seems most of the internet uses this term to indicate an architecture where the server relies on the client keeping track of the session.
Having that defined, the dangers of these stateless sessions should be pointed out. This list might not be exhaustive, but for example:
In short: to overcome the drawbacks of Stateless Sessions, you would have to implement a lot of logic on the server-side and ultimately even add state (in order to know if a token was made invalid). This means the advantage of having a stateless session has been nullified and in return you have a lot of extra complexity where things can go wrong.
A good security practice states that you shouldn't try implementing your own sessions, but better to rely on proven techniques. Building your own (stateful) stateless session goes against that.
Therefor, stateless sessions should be avoided.
The text was updated successfully, but these errors were encountered: