Lxstr
commented
3 months ago I noticed that flask-session-plus supports ability to store some sessions values on the client, I think this would be great to have in flask-session so that you could avoid filling up storage with things like next url and flashed messages. In that case we may still desire the signer, even though there wouldn't be much need to sign those kinds values, it may still prevent tampering.
Currently flask and most frameworks sign the client side session data to prevent tampering. Flask-session (since 0.2) also allows you to do this setting SESSION_USE_SIGNER = True. As all of the data is stored in server-side storage rather than on the client cookie, all that is signed is the session id.
Unsigned Flask-Session cookie (32bytes): Name: session, Value: uE8VW5JpjcNUdBJq6_3IGjSR5921D4avEevMeqhgYP0
Signed Flask-Session cookie (32bytes + 20byte signature): Name: session, Value: uE8VW5JpjcNUdBJq6_3IGjSR5921D4avEevMeqhgYP0.o3z8TVoQJEeyubuxg6ojQbfiDGg
While an attacker could guess the session id it would be very rare or take an extremely long time. See https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-entropy.
With the addition of a signature it not clear how this adds more security compared to just increasing the session ID length say by 20 bytes using SESSION_ID_LENGTH. It would seem to be simply another value that may be guessed by a brute force attacker.
Currently no other Python frameworks that I'm aware of allow for signing a server-side session.
The only mention of why this was added in Flask-Session is in #2, which says it is to prevent brute forcing. At the time (before 0.6.0) Flask-Session was using uuid4 rather than secrets.token_urlsafe, which was less than ideal (#198).