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>
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. 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/ed1eb5e1-c650-48c3-99f3-f55334373709%40googlegroups.com.

Reply via email to