rlipscombe / cowboy2_session Goto Github PK

rand:bytes/1 (PRNG) is probably hard to predict. It would be better to use a CSPRNG to be sure, though. Use crypto:strong_rand_bytes/1 instead.

Allow setting Secure, HttpOnly, expiry, etc.

Anonymous sessions should probably be ephemeral. But if you want "remember me" to work, you're gonna need to update the expiry on the cookie (and in the db).

When deployed behind a load-balancer, or in K8s, we get spammed on the /health endpoint. We don't want to create a new session in the ETS table for each of those requests, so provide a filter function that can skip session creation.

Or, alternatively, implement #13, but that might have other complications.

That is: don't send the cookie in the stream handler; wait until the first call to put_session.

ErlangLS in VS Code complains about the same thing.

You might want to use different session tables for different cowboy endpoints, for example.

If an attacker gets a copy of the session ID database, they'll be able to use one of the stolen session IDs to impersonate an authenticated user.

I think that this is only really relevant if using a persistent session store, so this depends on #8.

Mitigations are:

1. short session lifetimes.
2. periodic ID refresh; maybe that goes with #6. What I mean by that is: the session could be relatively long-lived ("remember me"), but if the ID is rotated frequently, the stolen database becomes useless.

See https://security.stackexchange.com/questions/221841/hashing-session-id

Avoids session fixation. For example:

1. Attacker visits the site; gets a session ID that refers to an anonymous user.
2. Attacker somehow puts that cookie on the victim's computer.
3. Victim logs in (or otherwise escalates their privileges).
4. If the session ID is reused, it now refers to the escalated session.
5. Attacker now has an escalated session on their own browser.

See, for example, https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#renew-the-session-id-after-any-privilege-level-change

Consider options for remembering the client IP address, etc.

ETS storage is great, but it can't be shared across nodes behind a load-balancer, and it's not persistent in case of server restart. Make it pluggable and provide, e.g., a redis backend.

Hacking on something at work; uses Github OAuth, and it stopped working. As far as I can tell, it's because session cookies don't work reliably over a 302 redirect (some SameSite shenanigans).

So: look carefully at how sessions are done over redirects. This probably means that #13 needs to be WONTFIXED, and that #6 needs looking at -- if you're doing it and then redirecting, stuff might break.

Currently it's an empty dictionary. You might want to use something different.