Security Review
Craig Younkins
- Someone should comb through the Django scaffolding and admin
application to check for CSRF vulnerability, leaking sensitive information
through URLs, and unvalidated redirects
- 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?
- 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?
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?"
If you have knowledge of any of the above topics, please see the links below to help us speed the review process.
Jacob Kaplan-Moss
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
secu...@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 <cyou...@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
Alex Gaynor
Bzzz :), we do flush the entire session here:
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L84
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@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
Jacob Kaplan-Moss
> Bzzz :), we do flush the entire session here:
> http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L84
Ah, you're right - thanks. Looks like it's been that way for a while:
http://code.djangoproject.com/changeset/8343
Jacob
Craig Younkins
"As far I can determine, only badly-written user code could result in SQL injection."
Sergej dergatsjev eecho
>> "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.
Well, python and django are for easy / rapid development.
-1 for "hard for developers to do something" :)
--
Sergej Dergatsjev
E-mail: sergej.d...@gmail.com
Skype: SergejDergatsjev
Site: http://www.eecho.info