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 secur...@djangoproject.com and 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.
