store session in signed/encrypted cookies

[brianmay]

This crate is suppose to replace the axum-sessions crate - which is now deprecated. But as far as I can tell, axum-sessions supports storing sessions in signed cookies (https://docs.rs/async-session/latest/async_session/struct.CookieStore.html), but this library does not.

My axum application does not have any kind of database, and uses oidc to authenticate. Adding a database just to keep track of the login would appear to be an overkill.

At the present, it would appear that the MemoryStore is my only solution, but presumably that will lose all sessions on restarting my program.

[maxcountryman]

tower-sessions doesn't provide signing because no data is stored in the cookie. In other words, the cookie value is a pointer to the data stored server side.

MemoryStore is not intended to be used in production. Instead, for an in-memory cache, I would suggest MokaStore. If you need persistence then you can use a database or implement SessionStore for any arbitrary persistence method.

[jokeyrhyme]

I think to accommodate this use case, the save() function in the SessionStore trait would have to return at least the session identifier (or an Option wrapping one), and for the middleware to use the Set-Cookie header whenever the implementation returns such a session identifier

That would allow a client-side storage implementation to fit the trait, by serialising and signing the session data into a new identifier

[maxcountryman]

That would allow a client-side storage implementation to fit the trait, by serialising and signing the session data into a new identifier

I think this is in conflict with a core design consideration of tower-sessions: it's intentional that the cookie doesn't carry session data with it.

[jokeyrhyme]

There are use cases where the design and operation of the server-side is much simpler if client-side sessions are a possibility, i.e. if there is no DB and having server-side sessions is the only reason a DB would be needed

But, it's understandable if such use cases are firmly out of scope for this project

[maxcountryman]

i.e. if there is no DB and having server-side sessions is the only reason a DB would be needed

SessionStore needn't be implemented exclusively for a database. For instance, Django provides a file store. The key capability is loading and saving and so long as you can do that then your store can be anything you like. Redis might be a reasonable compromise for folks in this situation: it should require less ops overhead (hopefully) compared to a fully-fledged RDBMS which you otherwise don't need.

Returning to Django for a moment, it does provide serialization to the cookie, but it's discouraged: it represents a serious security risk and comes with other caveats, like cookie size. Looking back on axum-sessions, I think it was a mistake (and at least one other person agreed) to encode data in the cookie. I understand that it can be convenient and there may be use cases where it's absolutely fine to do so, the trouble is it's not generally the right solution.

[brianmay]

For the record, the Elixir session frame work recommends storing sessions in cookies, and it is the default: https://hexdocs.pm/phoenix/1.3.0-rc.1/sessions.html#cookies

If this is a security issue or not, not sure. I guess it depends on what the session is used for, and what the consequences would be if an attacker got access. e.g. the risk of somebody stealing a not-expired token from a logged out session in order to access my web site that allows turning on/off my lights is pretty remote IMHO.

But perhaps it is risky that the Pheonix docs don't even mention any of the limitations of the default method. So I could imagine people are using it inappropriately without realising. e.g. if I logged out of my bank on a shared computer, I would be somewhat stunned and surprised if somebody could still access my bank account using the already obtained token.

Regardless, I plan to upgrade my app to use a database. At least attempt to do so :-). If this bug report is closed with "working as designed" I would be slightly sad, but this is OK with me.

[0xpr03]

how does elixir handle session invalidation ?

what I'm currently searching for is a method to invalidate sessions and list them - so far it doesn't look like that's possible with signed/encrypted cookies (and also harder with this crate, as you don't own the database)

[maxcountryman]

and also harder with this crate, as you don't own the database

Note that you can implement additional methods on your session store, for example a method to list or filter sessions. I'm not entirely sure what you mean by owning here, but nevertheless presumably you can connect to it which should mean you can query it arbitrarily.

However this is not the case with signed cookies: It's impossible with (stateless) signed cookies to do this. Once issued, you don't know what's out there anymore. Expiry is challenging too: you generally have to rotate your signing key and invalidate all session cookies at once.

[0xpr03]

this is not the case with signed cookies

Right, you could only do this by storing a key in the signed cookie, which you then look up in a database of valid login keys, creating one more indirection.

It would be nice if I could have some way to say "give me all valid sessions for user X, delete this session". You can emulate this (for example with the mentioned way above), but having this built-in would be really nice.

[maxcountryman]

Right, you could only do this by storing a key in the signed cookie, which you then look up in a database of valid login keys, creating one more indirection.

At this point, I can't see why you wouldn't simply store the session in the database (which is also what OWASP requires anyway).

It would be nice if I could have some way to say "give me all valid session for user X, delete this session". You can emulate this (for example with the mentioned way above), but having this built-in would be really nice.

tower-sessions doesn't have a concept of a "user" (beyond what we call a site visitor). If you want that, you would need to use something like axum-login, where we explicitly manage user sessions.

More broadly, this is absolutely something that we expect would be layered on tower-sessions in various ways. (You don't have to use axum-login, that just one example of the user session management use case.)

[maxcountryman]

I haven't really looked at this closely, but async-session implemented a cookie store. We might be able to do the same. (I'm not sure it should be baked into this crate, again regarding security.)

[benwilber]

Session state via signed/encrypted cookies is pretty common and very useful since it's stateless (ie, no need for a backend storage). Django has warnings about it because that's specific to their own implementation where, by default, the cookies are only signed, not encrypted. There's nothing inherently insecure with encoding session state in a signed/encrypted cookie. The implementer just needs to understand what they're doing. Hence the warning in Django's docs. It's not "discouraged".

I would love to be able to use signed/encrypted cookies for session storage instead of a dedicated session storage backend.

[maxcountryman]

I think this would also require updating the session key (i.e. ID) such that it's either a more flexible type (specifically one that can hold binary data, like a base 62 encoded string) or an arbitrary type. That seems like an acceptable change to make in my view.

With that, a cookie store implementation would then update the session ID with a signed representation of the session state a la the Django implementation.

[maxcountryman]

OWASP seems pretty clear about not storing session data on the cookie directly. See this heading: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-content-or-value

Cookie stores have other downsides, like the fact they can't be expired centrally and increase the size of requests, plus have an upper limit on how much data they can store.

[lcmgh]

Not having a cookie store means that frontends that do not ship own backends or other attached storage resources are not able to persist some session data. In my case I need an encrypted and signed CookieStore to persist the user's identifier.

Storing some session content signed and encrypted only on the cookie can be convenient that on server side one does not need to cleanup anything.

[maxcountryman]

It's still possible to use tower-cookies to set signed or encrypted cookies directly if your application needs additional cookies.

That said, I'm a bit confused: if you're using this crate then presumably you have a backend (of which this would be a part). That being the case, you can persist things like user identifiers in the session without the need to access them directly from the cookie. When the frontend needs some session data, like to render a view etc, that can be retrieved via an endpoint managed by backend.

[lcmgh]

you can persist things like user identifiers in the session without the need to access them directly from the cookie.

I got a kind of wrong understanding of that. I totally agree.

[mcheshkov]

There's another aspect of not signing session id in cookie: DB leak.

In some sense, session cookie is like a password in single factor auth: if you can get/craft a copy of valid cookie for some user, then you can impersonate them. If attacker could get a copy of DB, and there's straight up session ids inside, then attacker could impersonate any user with active session. Imagine storing raw passwords.

There's at least two ways of solving this, both rely on MAC to implement peppering of sorts.

One is "usual": sign cookie value before setting it and validate signature in cookie before accepting. Signature could be as simple as attaching HMAC-SHA256, computed on separate secret. Now attacker needs to forge HMAC as well, and secret for it should not be present in DB.

Other is reversed: cookie values are not signed, but we avoid storing them "raw" in DB, and instead store hash, just like with passwords. For example, to verify incoming session id from cookie one could split that id in half, use one part to locate record in DB, calculate HMAC on another part using separate secret, and check if that matches hash in DB in constant time. Here's useful post on that technique: https://paragonie.com/blog/2017/02/split-tokens-token-based-authentication-protocols-without-side-channels

I've just checked PostgresStore, and it uses session id directly. I did not check other stores, but I guess it's the same.
https://github.com/maxcountryman/tower-sessions-stores/blob/51cc75817cb98e875d8cf3975363f746857ad0b2/sqlx-store/src/postgres_store.rs#L177
Another issue here is that it uses id text primary key, meaning that there will be a B-tree index on id column, and that makes timing attacks for session enumeration possible. That's mostly out of scope of this discussion, but I'll touch that later.

So, I think that some way of protecting against DB leaks must be implemented, or even both (to allow crate users to choose their own adventure).

Signed cookies could be implemented in a single place, somewhere around part that generates Set-Cookie, that's SessionConfig::build_cookie ATM.

tower-sessions/src/service.rs

Line 34 in 060790d

let mut cookie_builder = Cookie::build((self.name.clone(), session_id.to_string()))

Hashes in DB would require either to implement support in every store, or to change SessionStore trait. That's where timing come into play: possibility of timing attack can be considered non-issue, if that would only lead to "some part of cookie is now valid" leak, and would still require enumerating sufficiently high amount of inputs. So, given that cookie is just an random token by design, maybe it is worth the hassle to double down on that, and change SessionStore to force every store to be a bit more resilient.

Just to be clear: I'm not against stateless sessions per se, or their support in this crate. Even if public API for session is same, they are two different things design-wise, and session manager would be very different. For example there's no "store" at all in stateless sessions. There's a need for signing even for stateful sessions, just like they are implemented today.

I'm looking for a way to use stateful sessions in one of my projects. I'm interested in using tower-sessions, and as a workaround, I could just copy existing store and add support for hashing inside load and save. I could propose specific design and implementation in an issue or PR, if @maxcountryman is interested.

[maxcountryman]

If attacker could get a copy of DB

If this happens, we've well and truly lost.

Taking a step back, I think the least of our worries would be access to sessions as it's quite likely the entire system is compromised at this point.

I could propose specific design and implementation in an issue or PR

I think this would be great provided it's behind a feature flag: I see signing or encrypting as having value mostly as a "defense in depth" measure, which should most likely be opt in (it comes with overhead to consider).

As it stands, nothing prevents session store implementors from encrypting column values before storing them, for example, so I would like to ensure we maintain flexibility and offer better controls as additional options which users can select if it fits their security posture.

Edit: one more thing to add here, I'd like to make sure we adhere to Django's session design as much as possible--if there are good, and verified, reasons to deviate that's okay but otherwise it's a goal of this crate to follow that design.

[maxcountryman]

I've put together a PR that enables signing and encryption via feature flags. It's a bit gross to gate a property of the session manager struct behind a feature flag like this, but I couldn't immediately think of a better way that wouldn't involve having to implement Service multiple times. Feedback about this design or suggestions for better approaches are appreciated.

[sbking]

Signing the session ID cookie would allow the app to avoid making a database query when the cookie contains a value that has been tampered with. That alone should be a good enough reason to allow signing the cookie even though it only contains a random identifier.

[maxcountryman]

It's not really so clear cut: already we don't talk to the session store unless the session is actually accessed in your code. If the session ID fails to parse, then we generate a new one, while issuing a warning (a la the OWASP guidelines)--none of this requires talking to the session store. On the other hand signing adds overhead: session IDs are longer and will require additional encoding and decoding not currently required. It's not obvious this is objectively better. That said, I've opened a PR which allows folks to opt into this if they want. Please do leave your feedback on that PR.

[lcmgh]

Use case for client side session: Currently my server creates a new session also for machine side calls (such as kubernetes health checks) which leads to an continous increase of memory.

Is there a way to work around that or ideas how we could prevent such behavior in future? For simplicity the layer covers all my routes.

[maxcountryman]

Is there a way to work around that or ideas how we could prevent such behavior in future?

A session is only created in the store when you actually use it (e.g. by inserting data into it). Otherwise, the session is not created at all (apart from a transient in-memory representation which is discarded after the request completes).

This is orthogonal to "client" sessions, since they would be loaded into memory the same way anyway.

Currently my server creates a new session also for machine side calls (such as kubernetes health checks) which leads to an continous increase of memory.

I have a very similar set up and do not observe this. Are you sure you don't have some leaky memory elsewhere in your app? Let's move this discussion to a separate thread if the issue persists.

[lcmgh]

Ok, it seems my problem is that I am always saving the "last visited url" prior any login activity. This means k8s health checks etc. trigger that as well.

[maxcountryman]

That would create a session per request, if it's not being sent with the request, yes.

Can you conditionalize that for the health check?

[lcmgh]

Yes it's an issue within my "userland". Sorry for disturbing you.

[maxcountryman]

No need to be sorry. Please feel free to ask questions--that's what we're here for. 🙂