On 02.10.2011, at 06:26, Paul McMillan 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.
You may be right about users screwing things up once in a while but that's entirely unrelated to the fact that the sessions app expects every backend to handle any (read: pickle-able) data you hand it. At least that's the status quo on how every session backend I've seen works. That's why we haven't used the JSON encoder but instead opted to a pickled encoder in the session backend, which was already a deviation in the related signed cookies code which does indeed use JSON. So, long story short, I don't think you made a convincing argument to me in proposing to ship a non-conforming session backend. Hence I propose to instead promote the section about SECRET_KEY in the session docs to a "big fat warning" and let the users decide how and when they use it. Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
