I agree with you on some of your points. Security can be improved if people would email the support team INSTEAD OF filing a bug report (this goes for any project), so that the teams know about security bugs before anybody else finds them.
However, if there's a default setting or commonly set configuration choice that may be questionable for security, the best course of action would be to educate the Django developers and site maintainers on why it is or is not a good idea to implement. The Rails community has mentioned the Homakov vulnerability to the Rails team, to which their stance has been configuration over convention (you're responsible for your own security). If there's a similar situation with the Django code, and it's something that's been put in intentionally by the Django team, then why not educate people about this? Better to have a resource somewhere where at least one Django developer on a team might have read a good security tip and share it with his team, than to have a potential attacker figure it out and exploit all of the Django sites that may have overlooked it. To put it in real life terms, you don't combat identity theft by not talking about it, you combat it by providing resources to educate the general public about how to protect themselves. Literally three days ago I found a potential vulnerability (a pretty stupid one too) on a large site built on another similar platform (not Django), so I emailed the support team and informed them of the possible security hole. It happens, but it's better to make sure people can be educated and learn. -- Joey "JoeLinux" Espinosa* * <http://joelinux117.blogspot.com> <http://twitter.com/joelinux117><http://about.me/joelinux> On Tue, Mar 6, 2012 at 6:16 PM, Russell Keith-Magee <russ...@keith-magee.com > wrote: > > On 06/03/2012, at 8:31 PM, Joey Espinosa wrote: > > > In light of all the recent talk about Egor Homakov's commandeering of > GitHub by exploiting a default Rails setting, are there any such "gotcha" > security defaults or common settings/conventions in Django you can think of > that could cause unsuspecting site maintainers to suffer a similar fate? If > you have a good one (or better yet, a list), sound off! This could help > other developers/administrators, and I could collect these into a blog post > if I get enough responses. > > Perhaps the biggest lesson the open source community can learn from this > entire exercise is *how to report security issues*. > > If you find -- or even *suspect* that you have found -- a security > vulnerability in Django, *please* don't file a bug, write a blog post, or > deface a known Django site. You should mail security@djangoproject.comand > describe in detail the problem you have found. > > The same goes for "insecure-by-default" defaults -- if you think Django > has a default option that has the potential to leave Django sites > accidentally vulnerable, *please* don't post a blog explaining how to > identify and exploit the problem. Mail secur...@djangoproject.com and > describe the problem. This class of problem is harder to protect against, > because we can't always protect against how someone will use a library. But > if it's in our power to provide a secure default, or provide better > documentation to encourage best practice, or even just document that a > potential gotcha exists, we would like to do so -- without the fireworks > that the Rails and Github communities were forced to endure this week. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
