pyramid_beaker, pyramid_redis_sessions, pyramid_session_redis

[Mike Orr]

Following up on my implementation of the 'samesite' cookie attribute
in sessions, I've been using 'pyramid_redis_sessions' in most
applications, but one uses 'pyramid_beaker' with Redis because it also
needs to support file-based sessions.

I thought 'pyramid_beaker had ended development with Pylons, but I was
surprised to see it has had several new commits over the past year and
has both 'samesite', 'secure', 'httponly, and a Redis backend, all
things I've needed.

'pyramid_redis_sessions' seems to be unmaintained, and a
'pyramid_session_redis' has appeared to supersede it. It also has a
bunch of features for high-volume usage that I don't understand. That
made me start thinking about switching from 'pyramid_redis_sessions'
to one of the other two. But I find that different applications have
different needs and may need different session libraries.

1) Restricted site with logins. This one changes the session timeout
dynamically. The default timeout is 1 minute for bots. The
unauthenticated timeout is 20 minutes for the user to complete the
single-sign in procedure on the authentication server. The
authenticated timeout is 2 hours after a successful login. I use a
'pyramid_redis_sessions; method to change the timeout.
'pyramid_beaker' odesn't seem to have this, and I haven't checked
'pyramid_session_redis' yet. But 'pyramid_redis_sessions' doesn't have
'samesite', which the other two do, and my IT department may insist on
it at some point.

2) A public site flexible for Redis sessions or file-based sessions,
with non-JSONable data in the session(i.e., it requires Pickle
serialization). It's currently using 'pyramid_beaker'. I asked earlier
on this list whether my Pickle-based sessions would still work under
Pyramid 2, and was told that JSON is just the new default, not a
requirement, so I could confinue using an a existing session library
that supports pickling. 'pyramid_session_redis' has a statement in its
documentation saying it's moving to JSO(N, and it's unclear to me
whether it would still sopport Pickle in some configuration, or if I'd
have to write my own plugin. Making the session data JSON-safe would
require rewriting significant parts of the application because it uses
nested objects.

3) A public site that just needs basic session support, and is
currently using 'pyramid_redis_sessions'. that doesn't support
'samesite', which I may need someday.

Do you have any advice on these tradeoffs?

--
Mike Orr <slugg...@gmail.com>

[Jonathan Vanasco]

Mike-

I maintain `pyramid_session_redis`.

The package allows for session data to be serialized with `pickle`.  I don't necessarily recommend it and prefer for `msgpack` myself, but it supports `pickle` and `pickle` is the default.

A recent-ish release dropped another usage of `pickle` in the library which was a potential security issue. Pyramid had finally removed it from one of the more recent branches.  The original behavior is still present in `pyramid_redis_sessions`:

https://github.com/ericrasmussen/pyramid_redis_sessions/blob/master/pyramid_redis_sessions/__init__.py#L284

cookieval = signed_serialize(session.session_id, secret)

Pyramid's `signed_serialize` was deprecated in 1.10 and has been removed from Pyramid 2.0

if you look at the legacy code from a PR ( https://github.com/Pylons/pyramid/commit/https://github.com/Pylons/pyramid/commit/133db09d179c3f5afe7e02dc13ab6687517db5a1#diff-66ef7a67eff67171f5600c8c2841a754L70)

You'll see this happens in the function:

pickled = pickle.dumps(data, pickle.HIGHEST_PROTOCOL)

The pyramid_session_redis behavior was to take a session_id, serialize it with pickle, then calculate a signature of that and use the pickled value + signature as a cookie value.

To retrieve a session, the signature of the cookie's value is checked, and it is deserialized if it passes. then that deserialized value is used to lookup the record in redis.

If your site's secret became compromised or decrypted, an attacker could compromise your servers by sending in carefully crafted payloads - as the value will be piped into pickle.loads().

The new behavior in my package is to leverage webob's `SignedSerializer` directly, and sign the session_id - as it is guaranteed by this library to be a string that can be fed into the serializer directly.

Since your concern is bots, something you may also consider is to use two different sessions or leverage other signed cookies into your session strategy. Usually I dedicate a browser cookie to 'session_status' of just being logged in or the user id -- either as a signed browser cookie or a primary session.  The more typical "session" stuff is then used via a server-side session that is only accessed when logged in.