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.

Reply via email to