# How to fix Session Fixation for Universal Login?

**URL:** <https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502>\
**Category:** Get Help\
**Tags:** security-compliance, security-question-concern\
**Created:** [September 6, 2024, 12:53pm UTC](https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502 "2024-09-06T12:53:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Denis\_Maliutenko](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/denis_maliutenko/32/30290_2.png) [@Denis\_Maliutenko](https://community.auth0.com/u/Denis_Maliutenko)\
**Post date:** [September 6, 2024, 12:53pm UTC](https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502/1 "2024-09-06T12:53:37Z")

</div>

As far as I can tell from the pentesting report, the main problem is that Auth0 doesn’t invalidate the existing session cookie after a new login. Could you please explain how I could fix Session Fixation invulnerability?

Here is the pentest’s report:

> We used the original cookies after login to generate a new set of session cookies with the same structure. We injected those in the browser and logged in again.
> 
> The server did not change the session cookies after this new login. Therefore, the forged cookies could still be used to continue accessing the account potentially.
> 
> The forged cookies used were:
> 
> connect.sid=…&3Ad
> 
> Risk description:
> 
> The risk is that an attacker might be able to fixate or set a user’s session ID to one known to them, perhaps through social engineering or by leaving a fixated cookie on a shared or public computer. When a victim logs in using the fixated session ID, they attach the attacker-set session to their authenticated account.
> 
> Recommendation:
> 
> Ensure a new and cryptographically secure random session ID is generated post-authentication. After a successful authentication, invalidate the user’s previous session tokens.

 ![pentest-report](https://global.discourse-cdn.com/auth0/original/3X/3/0/307f7a340a67c8060b74344d9a05e1cdc36c478b.png)

---

<div class="post-metadata">

**Author:** ![smendoza88](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/smendoza88/32/15135_2.png) [@smendoza88](https://community.auth0.com/u/smendoza88)\
**Post date:** [December 13, 2024, 12:49am UTC](https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502/2 "2024-12-13T00:49:57Z")

</div>

Hello,

I came to ask the same question as our audit revealed the session fixation issue too.

---

<div class="post-metadata">

**Author:** ![Denis\_Maliutenko](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/denis_maliutenko/32/30290_2.png) [@Denis\_Maliutenko](https://community.auth0.com/u/Denis_Maliutenko)\
**Post date:** [December 13, 2024, 9:31am UTC](https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502/3 "2024-12-13T09:31:11Z")

</div>

I was wrong about the origin of the `connect.sid` cookie. It turned out that it was created by `express-session` nodejs library and the purpose of it was to keep track of unauthorized users. For that reason the pentests could find that session. The issue was solved by setting `saveUninitialized: false` in the `express-session`’s settings.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\
**Post date:** [December 27, 2024, 9:32am UTC](https://community.auth0.com/t/how-to-fix-session-fixation-for-universal-login/145502/4 "2024-12-27T09:32:03Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.