On Thu, Feb 21, 2013 at 9:16 AM, Toran Billups <[email protected]> wrote:
> I was talking about basic django session authentication with a co-worker > recently and the idea of "cookie tampering" came up. I know rails will > digitially sign the data in your cookie but I'm unsure of django 1.4+ > > http://alindeman.github.com/2013/02/18/decoding-rails-session-cookies.html > > Thank you in advance > Essentially, the answer is you're safe by default; but it is possible to shoot yourself in the foot if you try :-) There are two pieces to this puzzle. -- sessions and cookies. First - cookies. HTTP provides cookies, and so Django provides access to set, retrieve and delete them. Django also provides tools to cryptographically sign (but not encrypt) those cookie values. However, it's up to you to use signed cookies - you can still use vanilla unsigned cookies if you want. https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponse.set_cookie You can use the raw cookie interface to handle session data if you want -- but thankfully, Django has wrapped up common session behaviour into a library that makes it easy to use sessions. Django's session backend is pluggable, so sessions can be handled in multiple ways. The default storage is database backed - so what is passed around in the session cookie is actually just a key that allows you to retrieve the session data from the database. This session data isn't signed or encrypted -- because it can't be tampered with (it's not stored anywhere that the end-user can modify it). Django also ships with a signed cookie backend. This means that the session cookie contains the session data. This cookie data is signed, but not encrypted, so it's safe from tampering. There are also settings you can enable to ensure that the cookie storing the session identifier isn't prone to session capture attacks (SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY) https://docs.djangoproject.com/en/dev/topics/http/sessions/ So - by default, Django session data is safe from tampering. It's certainly possible to build Django apps that *aren't* safe (e.g., it's possible to put sensitive data into an unsigned cookie) but Django gives you all the tools you need to avoid those problems, and uses safe options by default. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
