On Fri, Apr 12, 2013 at 10:49 AM, <testbackupa...@gmail.com> wrote:
> Hi,
>
> I'm fairly new to web development and Django, and I'm trying to make sure
> my application is protected against CSRF attacks. I've read through
> https://docs.djangoproject.com/en/dev/ref/contrib/csrf/, but I'm not
> confident I'm understanding it fully. I'd be very grateful for some
> feedback on what I'm doing.
>
> I started by enabling CsrfViewMiddleware. Then I looked at my POST forms:
>
> 1) I have POST forms that go to internal URLs in templates, both in my own
> application and in the registration library I'm using. All of them use the
> csrf_token tag, so I think I'm set there.
>
> 2) I do POSTs to internal URLs from my client-side javascript. Some POSTs
> are already baked into this code, but one gets built on the fly.
>
> My first question comes from the beginning of the doc, where it says,"The
> first defense against CSRF attacks is to ensure that GET requests are
> side-effect free." What's meant by "side effect free"?
>
It means that the request must be idempotent - that if you make the same
request on the server multiple times, that you get the same result each
time.
Broadly speaking, that means that GET requests should be used to retrieve
information, and server updates should be made using a POST request. GET
requests shouldn't modify anything server side - that is, there shouldn't
be any side effects of issuing the GET request.
(There's a little bit more subtlety there if you get into the fine details,
but this will do as a first order approximation)
> I also have a question about this line: "In the corresponding view
> functions, ensure that the 'django.core.context_processors.csrf' context
> processor is being used." I'm interpreting this to mean: "in the view
> functions that are used to render your templates that do POSTs, ensure that
> the csrf context processor is being used." That is, I don't need to worry
> about the context processor in views that are just handling POSTs that
> originate via AJAX from my client side. Am I understanding this correctly?
>
The context processor makes sure that the CSRF token is available to
templates that need to render it. If you have a view that renders a form,
you need to make sure that view has the CSRF context processor in it's
stack, so that the form will render with the token.
If you're doing AJAX, you still need to provide the CSRF token - however
you probably won't be getting that token from the view that serves the AJAX
call. The AJAX view for accepting updates will often have no responsibility
for providing rendered content; in those cases, it doesn't matter if the
AJAX view has access to the CSRF token in template context, because the
template context won't ever be used. You'll still need to get the CSRF
token from *somewhere* though -- either from another view, or by reading a
cookie.
That said, context processors are usually installed on a per-project level,
so *all* views in a given project will have access to the same context
regardless.
> I have one view that handles a webhook/POST that originates from outside
> my site and comes from a non-logged-in-user. I have decorated this view
> with a csrf_exempt decorator and don't return the CSRF token in my
> response. So I think I am covered there -- correct?
>
To be completely certain, we'd need to know details about what the web hook
is using, and how the web hook is being used. In theory, anything without
CSRF protection is potentially subject to a CSRF attack - the question is
whether this poses an actual security risk.
This will largely depend on what the web hook will be actually doing. CSRF
attacks hinge on an attacker convincing a victim to submit a form, and
abusing the fact that the victim is already logged into the friendly system
to get the victim's own credentials to authorise the form submission.
Put it this way - if an attacker were able to pose as any user they wanted,
and could submit anything they wanted through the web hook -- what's the
worst thing they could do? Are they just going to force a view of some data
to update? Or are they going to have authority to clear out someone's bank
account? If it's the former, there's probably no problem removing CSRF
protection. If it's the latter, you'd better not :-)
For the POSTs that originate from my client-side javascript code, I use the
> code given in the doc to get the token from csrf cookie and attach it to
> outgoing AJAX calls to internal URLs for HTTP/HTTPS methods that require
> it. But there is one POST form I build on the fly. Since the page that runs
> that code is generated by a template and the CSRF token is included in the
> context, I included this code:
>
>
> <script type="text/javascript">
>
> var getCSRFToken = function () { return "{% csrf_token %}"; };
>
> </script>
>
>
> and call the function when I'm building my form. Is that the right way to
> handle this?
>
It's *a* way of handling it. :-)
The downside to this approach is that you can't cache the page (at least,
not as a site-wide basis).
The other way is to extract the CSRF token from the cookie. The CSRF docs
you reference contain a JavaScript snippet for doing this.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
