Current Focus: Django

[Craig Younkins]

Let's focus on analyzing and improving the security of the largest Python web framework: Django.

[1] is the wiki page for Django. As you can see, we already have a bunch of information. In particular, I've taken a look at the authentication and password storing scheme. Still, there is much work to be done:

• 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 [2] 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. [3] 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?

Craig Younkins

[1] http://www.pythonsecurity.org/wiki/django/

[2] http://www.pythonsecurity.org/wiki/django/#session-management

[3] http://www.pythonsecurity.org/wiki/django/orm/#django-orm

[Adam Baldwin]

Has anybody been in contact with any of the Django core developers? It would be nice to let them know about this project and so it's easier to have dialog if we find things that we feel should be addressed.

• Someone should comb through the Django scaffolding and admin application to check for CSRF vulnerability, leaking sensitive information through URLs, and unvalidated redirects

I would be up for assisting with this. In particular I can see the need to add in some clickjacking protections, possibly a x-frame-options middleware option?

• I'd like to take a closer look at Django's ORM. [3] 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?

Here are some notes I had about raw SQL statements and identifying them in code...

* Check for the use of raw sql statements
  grep -R ".raw(" *
  grep -R ".execute(" *
    Make sure that params are passed in as a list and that string formatting is not used.

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?

Another area that I think could use some interest is that of field validation. I know [1] that the ImageField could use some modification or documentation to make sure extensions are checked. I see this happening more than not.

[1] - http://ngenuity-is.com/blog/2010/apr/25/abusing-django-with-evil-avatars/

-Adam

[Craig Younkins]

"Has anybody been in contact with any of the Django core developers?"

I've been chatting with them on a few issues, and just sent an email [1] to their dev list explaining what we'd like to accomplish. They are ready to work with us. 

"In particular I can see the need to add in some clickjacking protections, possibly a x-frame-options middleware option"

That would be awesome. 

"Another area that I think could use some interest is that of field validation"

Definitely another area that needs to be looked at. I'll link to your post on the Django page, good stuff. 

Craig Younkins

[1] http://groups.google.com/group/django-developers/browse_thread/thread/6dfabef59504d45d#