To reinforce the already commented issue: Werkzeug suffers from the same problem, since it's SecureCookie implementation pickles data by default.
https://github.com/mitsuhiko/werkzeug/issues/60 (See proof of concept added) To unpickle data from an untrusted client by default is a big potential remote code execution exploit, and a leaking SECRET_KEY shouldn't lead to such a compromise. There's no reason to not use JSON by default since it's adequate for most cases where you need to store lightweight data client-side, since it's most useful to use with FormWizard and such, where the fields are easily serialized as strings. If it can't be a drop-in replacement to the other session storage, just document it and offer a PickleSignedSessionStorage, but don't push a possibly insecure default. On 2 out, 02:26, Paul McMillan <[email protected]> wrote: > We recently committed changes to 1.4 that added signed cookie based > session storage. Session data is pickled, signed, and sent to the > client as a cookie. On receipt of the cookie, we check the signature, > unpickle, and use the data. We could use JSON instead of pickle, at > the expense of longer cookies. > > I believe that our signing implementation is secure and correct. > > However, I know that users of Django screw up from time to time. It's > not uncommon to see SECRET_KEY in a git repository, and that value is > often used in production. If SECRET_KEY is compromised, an attacker > can sign arbitrary cookie data. The use of pickle changes an attack > from "screw up the data in this application" to "arbitrary remote code > execution". > > In light of this, we should be conservative and use JSON by > default instead of pickle. > > -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
