session fixation

[firdausmaarof]

Pre-check

• Do not use the issues tracker for help or support, try Stack Overflow.
• For bugs, do a quick search and make sure the bug has not yet been reported
• If you found a security bug, do not report it through GitHub. Please send an e-mail to [email protected] instead.
• Finally, be nice and have fun!

Environment

• Ruby [2.4.10]
• Rails [5.1.6]
• Devise [4.4.3]

Current behavior

After i login, i copy the session id in the cookies. Open a new browser, and use the session id. it logged the user in.

Expected behavior

It supposed to not logged the user in using the same session id that i copied from a different browser.

[eliascaceresy]

I have the same problem!! Any solution?

[carlosantoniodasilva]

Please read #5348 and https://guides.rubyonrails.org/security.html#replay-attacks-for-cookiestore-sessions. There's basically no way to avoid this for a valid session / cookie that's just copied and reused somewhere else. Thanks.

[patleb]

I was looking at how devise mitigates the attack and to my surprise.. it didn't. Actually, one way to prevent this family of attacks is to keep a timestamp in the session and verify that :confirmed_at (or adding another field in the db to reset sessions) is before the current session timestamp.

This is actually a big deal to ignore scenarios like someone creating an account in advance with another user email, save the session. Then, the real user, at some point, confirms the account or resets the password or whatnot and, from that time, the malicious user could use the account at will.

[mcgha]

A solution I found while working on this:
As you mentioned, Devise doesn't do anything to prevent this, contrary to the Rails documentation. Calling reset_session will provide you a new session_id but it doesn't make the old one invalid.
I managed to mitigate the issue by setting an expiration date on the cookie in the session store. Devise will not authenticate an expired cookie. It doesn't quite fix the issue, but it's just mitigation.