feat: Add IP pinning option

[Voltra]

• Add IP pinning as an option/mode
• Add logic for proper handling of IP pinning (cf. Diagram)
• Tweak the way sessions are deleted to de-duplicate work, avoid session destruction via session-jacking attempts
• Document usage of IP pinning

Closes nuxt/nuxt#11733 .

[valiafetisov]

The approach of not deleting a session is questionable since we expect that ip address changes will happen naturally. If we don't delete them here, we might end up with a memory leak.

My suggestion: let's keep deletion logic as it was (deleting it on top of the newSession), since it's getting out of scope of this particular PR (implementing ip-pinning). We should discuss and implement changes to the deletion separately to not blow this PR

[Voltra]

This I think, as you suggested, just highlights a flaw in the session deletion system itself, not with the corrections made to the existing one made in this PR. As mentioned, deleting on session-jacking attempts (or any kind of IP changes) will risk remote session deletions.

The current system deletes sessions when trying to access them and they're expired, or when getSession fails. But that doesn't change the memory leaks caused by users just not using the platform anymore on a device they had a session open on.

It just shows that, in another PR, the session deletion system should be augmented with a task (à la CRON) to delete expired sessions periodically. That would allow to eliminate expired sessions eagerly instead of lazily.

[valiafetisov]

just highlights a flaw in the session deletion system itself
It just shows that, in another PR, the session deletion system should be augmented with a task (à la CRON) to delete expired sessions periodically.

Agreed. The cleanup can happen periodically and independently from the requests. This is out of scope of this PR.

As mentioned, deleting on session-jacking attempts (or any kind of IP changes) will risk remote session deletions.

From the security perspective, if the attacker already stole/guessed sessionId (which is hard in the first place) it will be much easier to guess ip address (especially if the approximate area/provider is already known and there is no rate limiting applied). So, I would say, especially in the case of the attack the session should be deleted to prevent session-jacking. In the other case, when IP address change happens naturally, we would need to delete it as well (although this can be done by other means as we agreed above). But I don't see the case for keeping it. Otherwise, can you bring an argument/use-case to keep it?

[Voltra]

Guessing the IP changes nothing, you can't just change your IP to the one you want even on networks that reuse recently freed IP addresses. The scenario that lead me to keep it is to prevent remote session cleanup when the cookie has been stolen.

Only the case where an attacker steals the cookie and (with extreme luck) gets reassigned to the actual user's IP after it's been freed (all that before session timeout) would be an exploitable scenario.

So it's a choice between attackers having the ability to freely clear sessions if they have access to the cookie, versus an extremely unlikely scenario of successful hijacking.

I'll take the no-breach-allowed approach and consider remote session cleanup less important. This can be reverted back anyway

[valiafetisov]

Please resolve conflicts and address or answer #16 (comment). Then we're ready to merge!

[valiafetisov]

Thanks @Voltra for the issue and awesome contribution 🖤

I assume @BracketJohn will do next release once #7 is merged as well.

[BracketJohn]

Yup will do - unless you need it urgently @Voltra?

Thanks for the contribution- it was a great idea and will be an awesome addition to the library.