> > "As far I can determine, only badly-written user code could result in > SQL injection."
And with that statement you define the world of application security. Nearly all the exploits and vulnerabilities we see are not because the security controls don't exist - it's because they aren't used consistently or are misused. A smaller number of vulnerabilities are because the controls are broken. In this vein, most of our job here at OWASP is not to make and distribute controls. Decent controls are out there and provided. No, most of our job rests with automating security, getting developers to actively think about security, and getting people to consistently use the controls. Users will write bad code. I guarantee it. OWASP recommends HTML entity escaping all non-alphanumerics less than 128 for use in HTML attributes. Why not just the regular 5 characters you ask? While it's true the only way to break out of a quoted attribute is with a matching quote, we've seen way too many applications with user-supplied data in unquoted HTML attributes, which can be broken out of with many characters not typically escaped. Now you can say, as I once did, "What?! Why the heck would the developer do that?! That's their fault!" and yet, that does nothing to enhance the security of the application. Much of the time it's these user errors that result in vulnerabilities, so we've got to do something about them. We don't want to just make it easy to secure applications, we want it to be hard for developers to do something that will compromise their application. Craig Younkins On Mon, Jul 26, 2010 at 3: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. > > > - 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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
