-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
🐛 [Bug]: Inconsistency in Session and CSRF Middleware Handling of Timeout and Expiration #2741
Comments
@ReneWerner87 @gaby @efectn @nickajacks1 I would appreciate your input on this. |
Inconsisties were noted when working on: https://github.com/sixcolors/gofiber-react-session-csrf-example |
@sixcolors I totally agree, the inconsistency was made worst when the fixes for csrf were done. The session middleware needs a full refactoring. It would make sense to make these two consistent given how CSRF depends on Sessions as so do other middlewares. |
yes agree |
Is this fixed yet? |
No. V3 fix. Breaking change required. |
@rngallen did you have a solution or input in how to address? |
@sixcolors Currently no solution for this, I was trying to use session store with csrf, but I discovered session expiration and session id was updated on each request. I though session id should remain constant throughout the session (before expiration) but should have option on config if user want session expiration to be updated upon each request. |
@rngallen Ah I see. Actually this issue is probably unrelated; I'll assume you're using EncryptCookie? If So: it is technically possible (although not necessarily beneficial) to use Session and CSRF with encrypt cookie. It's just matters what order you use them in. |
Encrypt cookie not in use, |
Okay, let's move the discussion to #2793 as I think there is some config/setup/session use issue. |
Bug Description
Inconsistency in Session and CSRF Middleware Handling of Timeout and Expiration
The current behaviour of both the session and CSRF middlewares introduces a notable inconsistency in handling expiration, sometimes as a timeout, deviating from established standards such as those outlined in NIST Special Publication 800-63B.
TD;DR for NIST guidelines:
Expiration refers to the overall validity period of a session and may be extended by reauthentication, while timeout is associated with inactivity and requires user activity within a defined period to prevent session termination.
Session Middleware
The session middleware currently has a predetermined endpoint for session expiration. However, there is an unexpected side-effect when
sess.Save()
is called, which extends the session as if it were a timeout. This behaviour is not intuitive and needs to be reviewed to comply with NIST SP 800-63B guidelines. The guidelines make a clear distinction between timeout and expiration, and the session middleware should be updated accordingly to follow these guidelines. Alternatively, developers should have some mechanism to control which actions extend a session expiration and which do not.CSRF Middleware
The CSRF middleware treats expiration as a timeout and extends it with every request. This behaviour aligns with a specific use case but deviates from the principles outlined in the NIST documentation, which separates Timeout and Expiration.
After every request, if this middleware is used with a session, the
createOrExtendTokenInStorage()
function is called. This function, in turn, callssessionManager.setRaw()
which callssess.Save()
, extending the session as if it too had a timeout and not an expiration.Recommendation
We should evaluate how expiration is handled in middlewares, eliminate inconsistencies, and align with best practices.
Additional Considerations
How to Reproduce
Use middleware
Expected Behavior
Expiration and Timeout act is described in issue description
Fiber Version
<= 2.51.0
Code Snippet (optional)
No response
Checklist:
The text was updated successfully, but these errors were encountered: