Hi Craig -- Once again, thanks for this work; I can see it paying off big. And I know you know this, but for the benefit of anyone else reading this thread:
**PLEASE report any security issues — potential or otherwise — to secur...@djangoproject.com.** (More on our security policy: http://docs.djangoproject.com/en/1.2/internals/contributing/#s-reporting-security-issues) On Mon, Jul 26, 2010 at 12:22 PM, Craig Younkins <cyounk...@gmail.com> wrote: > - Someone should comb through the Django scaffolding and admin > application to check for CSRF vulnerability, leaking sensitive > information > through URLs, and unvalidated redirects You might have a better run of things of you don't refer to "scaffolding" <grin>. We don't have anything we call "scaffolding"... In all seriousness, though, this would be well-worth the time spent. CSRF, though, is handled framework-wide by the CSRF framework (which is newly revamped and hardened in Django 1.2). So anything you might find in the admin would probably be a bigger issue affecting the whole framework. > - An investigation of session management is needed. Update [5] with the > specific settings that are referenced there for the cookie timeouts, > etc. > When a user logs out, is the session invalidated? IIRC no, not currently. I'd have to double-check, though. > - I'd like to take a closer look at Django's ORM. [6] Does it use bound > parameters for all backends? Can developers write raw SQL with bound > parameters, or is it just using string interpolation? What escaping > mechanisms are provided in this case? Yes, Django uses bind parameters everywhere. Django allows raw SQL in a number of places -- QuerySet.extra(), QuerySet.raw(), and of course via raw database cursors -- but we make a point of forcibly encouraging bind parameters in our documentation every time we discuss raw SQL. I've personally audited Django for SQL injection a number of times. As far I can determine, only badly-written user code could result in SQL injection. > I think our efforts towards securing Django could culminate in a > single-page > handout on hardening Django. Such a handout would cover many of the same > topics that the wiki page covers, but keep it brief and focus on what is > needed to secure applications in Django. Comments?" Are you looking to write a TODO list for us (Django's core developers) or a handout for users wanting to write the most secure applications? While both would be extremely useful, I would *really* love to have a short and sweet guide to writing secure applications in Django. Such a document would make a great addition to our official docs, and I would love to have it. Some years ago I took at stab at it myself; it ended up being the last chapter of the book Adrian and I wrote on Django: http://djangobook.com/en/2.0/chapter20/. I'm fairly happy with the content there, and as the book is GFDL licensed you should feel free to adapt any content as you see fit. > If you have knowledge of any of the above topics, please see the links below > to help us speed the review process. One suggestion would be to add timing attacks to your review list. I'm fairly we have a few places we should be improving security by using constant-time hash comparisons. [For anyone unfamiliar with timing attacks, I've collected some reading material at http://jacobian.org/tags/timingvulnerability/.] > I'm sure questions will come up as we're doing our review. We'll bring those > questions here unless otherwise requested. > I also don't want the issues I raised about contrib.auth [3] to be > forgotten. I think we opened #13969 as the only non-controversial, actionable item out of that list. Tickets are the way we keep things from "getting lost", so the other ares could benefit from some specific proposals; we could then (re)open tickets as appropriate. Thanks again! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
