Discourage the use of Stateless Sessions (and therefor the usage of JWT for session)

[bitnesswise]

I want to propose two changes/additions in chapter 3 about Session Management:

1. Add a section about Stateless Sessions 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:

• When the server is not aware of the state, it's impossible to properly invalidate a session. If an attacker manages to compromise a session and gets hold of the token then the victim would never be able to 'log out', because the server relies on what the client sends. Also note that if a pentest is conducted, this will (should) also be flagged and marked as an issue.
• Architectures where the client needs to keep track of the session often lead to developers storing the session in insecure ways. For example in session storage or cookies without the http flag, where javascript can also access them (which is dangerous from an xss perspective for example)
• It's an architecture that makes it difficult to deal with session timeouts. In practice you often see that as a result, the session is very long-lived - often too long. When the duration is made shorter, it will require code on the server-side to generate replacement tokens with a new validity, which is complex.

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.

2. In section 3.5 (Token-based Session Management), refer to the section about Stateless Sessions to point out that using JWT for sessions suffers from all the drawbacks mentioned there and is therefor discouraged