I agree that it's more intuitive to tie messages to sessions. I remember reading many articles on PHP sessions and about session hijacking, etc. Has Django's sessions been looked at from this perspective or can Django's sessions have similar issues?
Some reference material by Chris Shifflett, one of the leading security guys working on PHP: The Truth about Sessions: http://shiflett.org/articles/the-truth-about-sessions Session Fixation: http://shiflett.org/articles/security-corner-feb2004 Session Hijacking: http://shiflett.org/articles/security-corner-aug2004 In one of those articles, he describes the "impersonation" scenario, which is what I wonder if Jeremy is referring to: 1. Good Guy visits http://www.example.org/ and logs in 2. The example.org Web site sets a cookie, sessionid=12345 3. Bad Guy visits http://www.example.org/ and presents a cookie, sessionid=12345 4. The example.org Web site mistakenly believes that Bad Guy is in fact Good Guy Looking at the Django code, the session_key seems to be quite random using the settings.SECRET_KEY as salt. Could the Django session also add in checks against impersonation, which it doesn't appear to do currently? For example, if the sessionid cookie was issued from a certain IP address, it must come back from the same IP? Or if extra HTTP headers are present they must also be present on subsequent requests (eg: the User-Agent string)? These can be combined so sessions use everything available as a fingerprint that is hashed, as suggested in one of the articles and that hash must match on every request? It looks like there is some tamper checking in the sessions code but I don't quite understand what it's doing on first glance. This code checks that they are the same string? pickled, tamper_check = encoded_data[:-32], encoded_data[-32:] if md5.new(pickled + settings.SECRET_KEY).hexdigest() != tamper_check: from django.core.exceptions import SuspiciousOperation raise SuspiciousOperation, "User tampered with session cookie." He also raises some points on why it might be good to provide an API to the developer to regenerate IDs, or to regenerate a new sessionid in certain scenarios. This is something the model currently doesn't have that might also be useful. In another thread I was asking why it seemed some people were avoiding sessions. Is it security related? Or simply that it requires cookies? Or something else? I'm going to need to rely on sessions on a planned site in the future, so I'm curious why some people avoid sessions in case there's something I don't know about. :) -Rob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
