Remove session-jacking vulnerability
See original GitHub issueDescribe the feature
The current session system models very closely the base PHP session which is to say a map of SESSION_ID -> SESSION_DATA
. This, as noted in the documentation of the package, is a quite the vulnerability.
One of the ways to counter that is to change the mapping to be (SESSION_ID, USER_IP) -> SESSION_DATA
. This allows:
- To be unable to get session-jacking by stealing the session ID cookie
- To keep sessions independent by browser sessions when sharing the same IP on the same network
However, this requires two things:
- Access to the user’s IP address (GDPR compliance + I think it’s slightly complicated to get in Nuxt 3?)
- Proper IP forwarding if the app is “hidden” behind a proxy
Moreover this brings out a number of issues:
- Quid of the user’s IP changing (e.g. moving a lot using a mobile network)
This is not a perfect solution, it is right now just a proposition and I think people can add other solutions to expand our horizons. Something akin to Laravel’s session driver might be a good thing too.
I’ll try and figure out how to get the IP-restricted session system working and make a proper PR, unless someone beats me to it.
Additional information
No response
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:9 (4 by maintainers)
Top Results From Across the Web
What is Session Hijacking and How Do You Prevent It? - Blog
Unfortunately there is a constant threat of session hijacking looming. Find out what can be done to prevent it.
Read more >What Is Session Hijacking, and How Can It Be Prevented?
Use strong passwords and multifactor authentication. These techniques protect accounts from being accessed by hackers if they manage to steal a user's session...
Read more >Session Hijacking - CodePath Cliffnotes
Session hijacking is an attack where the attacker steals a user's active session with a website to gain unauthorized access to actions and...
Read more >What is Session Hijacking and how can you Prevent it?
Use long random numbers or strings as the session ID. This will limit your vulnerability to brute force attacks. Regenerate the session ID...
Read more >Session fixation | OWASP Foundation
Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hey @Voltra, thanks for the proposal and the diagram! I think the concept of pining sessions to user IPs is a valid one, although, as you pointed out, might not be suitable for most users and would probably be optional due to:
If you still want to proceed, I suggest to introduce a new configuration flag, eg
ipPinning: false
to the default config 🙂Maybe it can also be optional check, but from my perspective it wouldn’t add much protection. The main difference between IP-pinning vs UA-pinning is that UA is coming from the same network actor as session id, while IP information is coming from the server, not user. Practically it means that having a “read” access to the communication is enough to pretend the same user with UA-pinning, while with IP-pinning the attacker should also be able to do requests (or “write”) from the user perspective.