On Mon, Jul 26, 2010 at 2:57 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > 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. >
Bzzz :), we do flush the entire session here: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L84 >> - 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
