-
-
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
SessionID new on each request (session mw) #2793
Comments
I used code from https://github.com/gofiber/recipes/tree/master/csrf-with-session to demonstrate You can go to Though it won't affect those using MVC architecture (like example on recipes) because cookie(s) on storage will be updated automatically
|
Are you running the example code over https, eg behind a reverse proxy? |
No, not over https |
for both csrf and session. |
and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes You can't use __Host- with non-https. |
The example is running https. https://github.com/gofiber/recipes/blob/master/csrf-with-session/main.go |
Also because you are exempting csrf cookie, but not session it's encrypting the cookie value for session. Although the id of the session only changes on auth (per example), it is stable once logged in. It's just the cookie encrypted value that's changing, because it's setting a new cookie each request [even though the id is the same]. // app.Use(encryptcookie.New(encryptcookie.Config{ //<<== will cause sessionid to be updated/changed on each request
// Except: []string{csrf.ConfigDefault.CookieName},
// Key: "t+A2pNQ+GM117Uj7AhaHq/BwjWzZwBT9crgOSY6eWjA=",
// })) you could: app.Use(encryptcookie.New(encryptcookie.Config{ //<<== will cause sessionid to be updated/changed on each request
Except: []string{csrf.ConfigDefault.CookieName, "session"}, // except csrf and session cookies
Key: "t+A2pNQ+GM117Uj7AhaHq/BwjWzZwBT9crgOSY6eWjA=",
})) But I would ask, why are you encrypting cookies? There is no security value in encrypting session and csrf cookies. |
So what the idea of using encryptCookie if session id will not be encrypted I miss the point here. |
I do not recommend using encryptCookie for session and CSRF tokens or any other token, as it simply replaces one token with another while adding the overhead of encryption and decryption. Some might choose to use encrypted cookies in cases where they have a cookie whose value contains data they do not want the user to see. Old frameworks from the 2000s, like Ruby on Rails, used this technique to store login and role information in a cookie. However, this use case is no longer considered secure. I cannot think of a valid use case for encrypted cookies, particularly when the server has a database and cache available. |
You can see the behaviour here:
|
The reason for receiving new cookie values on every request where the cookie is set, despite the value string remaining the same, is that the EncryptCookie function is nondeterministic. It uses a random nonce (Number Used Once) each time it performs an encryption operation. The nonce is generated by reading from rand.Reader, which produces a sequence of random bytes. This means that encrypting the same value with the same key will produce different results every time, due to the different nonce used in each encryption operation. It is possible to write a deterministic encryption function by setting a fixed nonce instead of a random one and using that function in the middleware. However, using a fixed nonce with the same key and value in AES-GCM mode is a serious security risk, as it can lead to the same ciphertext being produced for the same plaintext, which can reveal patterns to an attacker. So this is not recommended for real-world use due to the security implications. |
Thanks it's clear now, Kindly close it |
I would like to amend my previous statement that encrypting tokens has no security value. Encrypting tokens could help randomize them and mitigate side channel attacks like BREACH from exploiting the compression of HTTP responses. However, this is not the intended use of the encrypt cookie middleware, and there are other ways to defend against such attacks, such as rate limiting and turning off HTTP compression. Finally, I want to mention that the reissue of cookies per request with csrf and session is not intentional, but a result of how the middleware interact. This may change when we fix the main issue for this one. Hence, I still do not advise encrypting these tokens. |
Originally posted by @rngallen in #2741 (comment)
@rngallen can you please post a sample of your code here? The session mw should not be creating new session id for each session.
The text was updated successfully, but these errors were encountered: