Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

[Tom Christie]

I don't know how much of an issue it really is (or not), but I haven't 
really seen it being done right.
Of all the examples I've found of devs implementing session authentication 
on top of piston and tastypie, (See 
here,
 
hereand
 
here)
 
none have re-enabled CSRF protection. (As far as I can tell.)

Having said that, I really just wanted to:

1. Get the core devs opinion on if would ought to actively do anything 
about this in core, since it's pretty easy to shoot yourself in the foot.
2. Raise the issue, so that there's at least more awareness that devs 
really should be making sure that any same-site AJAX driven APIs *do* get 
CSRF protection. [*]

I fall into the camp of "you should understand what you're doing when
> you turn CSRF protection off". If the framework authors want to
> support session based authentication, I believe they're capable of
> doing it correctly. Until then, if users want to hack session based
> auth onto the frameworks, they should be careful and understand what
> they're doing.


I'm happy with that.

Thanks for the feedback,

  Tom

[*] Only relevant to APIs that support POST/PUT or DELETE operations of 
course.  Read-only APIs will be just fine.

On Saturday, 17 March 2012 03:24:04 UTC, Paul McMillan wrote:
>
> >> One idea to mitigating this in Django core that I've considered would be
> >> introducing a '@csrf_defered' decorator
>
> > Practically speaking, I think this might be ok and would cover the
> > majority of real cases. But at the very least it means that this
> > decorator should live in contrib.sessions, not in the core CSRF code.
>
> I would be opposed to this code in any shipped part of Django. It
> certainly could be built as a third party module (if we don't have the
> hooks necessary to do this, we can discuss them). My main objection is
> that CSRF is not a topic which should be deferred, or maybe on, or
> anything except absolutely positively explicitly on or off.
> Introducing a deferred format encourages developers to ignore it,
> until it causes problems, at which point they will do exactly the same
> thing as they do now, and turn it off. It's easy enough to screw up
> already - adding a "maybe on" is going to bite developers even more
> than the current format, since it will be even easier to write code
> that works most of the time, for most users, but not all of the time,
> for all users.
>
> I fall into the camp of "you should understand what you're doing when
> you turn CSRF protection off". If the framework authors want to
> support session based authentication, I believe they're capable of
> doing it correctly. Until then, if users want to hack session based
> auth onto the frameworks, they should be careful and understand what
> they're doing.
>
> For readers who have not inspected it yet, Django's CSRF
> implementation is quite instructive:
>
> https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py
>
> -Paul
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Dq4aUlP24nAJ.
To post to this group, send email to django-developers@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.

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

[Paul McMillan]

>> One idea to mitigating this in Django core that I've considered would be
>> introducing a '@csrf_defered' decorator

> Practically speaking, I think this might be ok and would cover the
> majority of real cases. But at the very least it means that this
> decorator should live in contrib.sessions, not in the core CSRF code.

I would be opposed to this code in any shipped part of Django. It
certainly could be built as a third party module (if we don't have the
hooks necessary to do this, we can discuss them). My main objection is
that CSRF is not a topic which should be deferred, or maybe on, or
anything except absolutely positively explicitly on or off.
Introducing a deferred format encourages developers to ignore it,
until it causes problems, at which point they will do exactly the same
thing as they do now, and turn it off. It's easy enough to screw up
already - adding a "maybe on" is going to bite developers even more
than the current format, since it will be even easier to write code
that works most of the time, for most users, but not all of the time,
for all users.

I fall into the camp of "you should understand what you're doing when
you turn CSRF protection off". If the framework authors want to
support session based authentication, I believe they're capable of
doing it correctly. Until then, if users want to hack session based
auth onto the frameworks, they should be careful and understand what
they're doing.

For readers who have not inspected it yet, Django's CSRF
implementation is quite instructive:
https://code.djangoproject.com/browser/django/trunk/django/middleware/csrf.py

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

[Carl Meyer]

Hi Tom,

Thanks for raising this.

On 03/14/2012 11:20 AM, Tom Christie wrote:
[snip]
> One idea to mitigating this in Django core that I've considered would be
> introducing a '@csrf_defered' decorator, that would act like
> '@csrf_exempt', but wrap request.session in a lazily evaluated
> '@csrf_protect'.  That'd give developers an easy way to generically do
> "Don't CSRF protect this view unless/until it accesses session
> information.".  API frameworks could then use '@csrf_defered' instead of
> '@csrf_exempt', and know that they'll get the correct
> behavior whether the API uses session authentication or not.

This would be specific to Django's session implementation, so it would
tie the CSRF protection to use of django.contrib.sessions, which is
something we've otherwise avoided (in the new CSRF implementation). It
also wouldn't help anyone who has their own session implementation or
cookie-based authentication of some sort.

Practically speaking, I think this might be ok and would cover the
majority of real cases. But at the very least it means that this
decorator should live in contrib.sessions, not in the core CSRF code.

Carl



signature.asc
Description: OpenPGP digital signature