On Nov 7, 2007 5:22 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I have quite a different view about the severity of this. Out of the > box, Django has a CSRF vulnerability if you use admin. I'm not inclined > to dismiss this as a nothing event that you can work around by somehow > magically divining that you need to include an optional package if > you're using admin.
Well, I've been thinking about it since we got the original report (we *did* get a report well before the SecurityFocus post, though it didn't quite make it through the official channels), and I'm not convinced it's of high severity. The number of things an attacker has to know or get right by chance, all at the same time, in order to mount a successful exploit, is something of a barrier to making it practical. And even if the attacker *does* manage it, there's no chance of compromising the user account whose password was changed, because the attacker doesn't obtain the username in the course of exploiting this; in order to obtain that, the attacker has to resort to some other means which likely would have compromised the account anyway, which renders the CSRF moot. Which means that this basically boils down to an annoyance attack, changing a user's password without their knowledge. But that's already exposed to anyone who can guess the user's email address, so anyone who simply wants to cause this sort of mischief already has a much easier route to accomplish it. > Now, it's very disappointing that the original reported to SecurityFocus > didn't report it to us first, but that only makes the original reporter > irresponsible and unprofessional, not wrong. Again, it was reported to us, but when the reporter was made aware of the CSRF middleware he seemed to think that the middleware made the whole thing moot. Which is why I am a bit surprised at the SecurityFocus post and the CVE candidate. At any rate, this conflates multiple issues, which is always problematic: the original reporter suggested that we should begin enabling the CSRF middleware by default, and I'm starting to lean that way, especially since it seems we're going to start enabling output escaping by default. I bring them up together because it seems that if we're going to change Django to mitigate one common class of security problem out of the box, we should probably cover the other big obvious one while we're at it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
