5

After reading this: http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-to-use-it

I came to the conclusion that it is not valid to use this except for when you trust the person who is using the page which enlists it. Is this correct?

I guess I don't really understand when it's safe to use this because of this statement:

This should not be done for POST forms that target external URLs, since that would cause the CSRF token to be leaked, leading to a vulnerability.

The reason it's confusing is that; to me an "external URL" would be page on that isn't part of my domain (ie, I own www.example.com and put a form that posts to www.spamfoo.com. This obviously can't be the case since people wouldn't use Django for generating forms that post to other people's websites, but how could it be true that you can't use CSRF protection on public forms (like a login form)?

orokusaki
  • 55,146
  • 59
  • 179
  • 257
  • Actually, I have a Use Case where a form *is* posted to another site. It's a small e-commerce site which uses the bolt-on shopping cart from Mal's ecommerce (http://www.mals-e.com/). The site using this is not written in Django, but there's no reason why something similar might not occur with a Django site. – Peter Rowell Mar 12 '10 at 01:35
  • 2
    I think you need to better understand why CSRF is a vulnerability. A good step is to read about the Same Origin Policy: http://code.google.com/p/browsersec/wiki/Part2 – rook Mar 12 '10 at 01:50

1 Answers1

0

With apologies to not understanding the specific source of your confusion, I'll say that the question you should be asking is when NOT to use CSRF protection. You've already called out this case from the docs:

This should not be done for POST forms that target external URLs, since that would cause the CSRF token to be leaked, leading to a vulnerability.

If you are posting a form to your domain, you'll want CSRF protection enabled by default, unless you have a specific reason to disable it (which should be more rare than not).

Brian Luft
  • 1,153
  • 8
  • 12
  • @Brian My confusion comes because targeting external URLs is very rare, so to me I saw this as external to your company (as in not the admin, or other internal interface), and if I created a blog application, and my users added JavaScript to their blog pages (because they trusted it), XSS could send off the token to some other server. This makes me think that Django's CSRF stuff is not secure at all unless I'm making a website that doesn't include any content by users (no social networking, blog, CMS, cart, etc) which would pretty much render it useless. I'm not confused at how it works though – orokusaki Mar 12 '10 at 02:35
  • I agree that targeting external URLs is rare. I also agree that the documentation could benefit from some changes. I think it is a stretch to say it is "rendered useless". Social networking applications certainly have their place out there, but don't overlook that are many other classes of form/data driven applications out there. – Brian Luft Mar 12 '10 at 05:12
  • I agree that the potential to expose a CSRF token is one of many security-related aspects you'll want to consider if you're creating pages that allow users to run arbitrary scripts. That said, I can't think of many use cases where I'd present an application form on a page that executed arbitrary user code. – Brian Luft Mar 12 '10 at 05:12
  • Regardless, thumbs up for wanting to understand the implications fully. You might get better clarification if you browse through some of the original wiki and group discussion material: http://simonwillison.net/2009/Sep/28/ponies/ http://code.djangoproject.com/wiki/CsrfProtection http://groups.google.com/group/django-developers/browse_thread/thread/3d2dc750082103dc – Brian Luft Mar 12 '10 at 05:13
  • 1
    thanks for all your help / advice. I also checked out the links. – orokusaki Mar 12 '10 at 15:52