2

I have a Django Site that uses Django's csrf-token for protection against csrf attacks. One of the forms can be accessed by public, including people who have not logged in.

Csrf Token is supposed to give protection against cross domain requests.

Edit: (quote from my comment) "But, in case of post requests that are allowed without requiring authorization, csrf is no better than a trival spam filter(captcha would do better here). In fact, it should be a security risk to include CSRF token(that expire after say, 30 mins) in pages that require no authentication what so ever.(but my site is doing it, which is why I made this post in the first place)"

Also, in this case, one could just fetch that page in browser js console, get the csrf token through some specific xpath and then post some arbitrary data with that csrf. Also, steps being easily reproducible, one could design a specific attack for the site, or any Django site for that matter cause you'll find csrf token besides 'csrfmiddlewaretoken' every time (and that includes sites like reddit, pinterest etc.).

As far as I can see, apart from making it a little difficult, csrf token didn't help much.

Is there an aspect to it I am missing? Is my implementation wrong? and If I'am correct is it dumb to have your csrf token flying around in your html source(esp. those not requiring any authentication)?

Optimus
  • 2,716
  • 4
  • 29
  • 49
  • 1
    How is the process you described an attack on someone else? Seems like you would just be performing a manual client side post as the owner of the session. – jdi Jun 09 '12 at 18:11
  • possible duplicate of [What is a csrf token ? what is it's importance and how does it work?](http://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work) – jdi Jun 09 '12 at 18:20
  • yes, but only if I do it. If it's a malicious plugin installed in someones browser, the plugin can then fetch the form with a simple get request, get the csrf token and post the form with it. It seems the csrf is easily bypassed, if some GET request that doesn't require authentication, but contains a form (with csrf token). – Optimus Jun 09 '12 at 18:25
  • 2
    It's not supposed to be a defence against malicious plugins. It's a defence against cross-site request forgeries, hence the name. – Daniel Roseman Jun 09 '12 at 18:27
  • what security does it actually offer then? people can steel csrf and they can steel sessions, how does it make it more secure then? – Optimus Jun 09 '12 at 18:30
  • Yes as Daniel points out, you are talking about a different type of exploit where you are getting the client side to run local code as opposed to a 3rd party site hosting malicious code to submit requests assuming the client has the session cookies. It would have to be same origin to work as you say. – jdi Jun 09 '12 at 18:34
  • It seems the scope of protection provided by a csrf token is a very trivially bypass-able, if that is the way it is. – Optimus Jun 09 '12 at 18:39
  • Stating my original concern, is it possible then for a malicious site to use a csrf token by fetching a specific page (that doesn't require authorization) and making further requests with that token. say, the token expires in an hour or so. – Optimus Jun 09 '12 at 18:41
  • @Optimus, it's like how locks are completely ineffective against a determined thief, yet work as deterrent for many. If you have csrf, I'd at least have to parse your page, determine the token, remember to pass it in my next request, etc. If your blog (let's just say) didn't have it, I could write a script to send you spam links in 10 seconds. – Yuji 'Tomita' Tomita Jun 09 '12 at 19:14
  • So, in case of post requests that are allowed without requiring authorization, csrf is no better than a trival spam filter(captcha would do better here). In fact, it should be a security risk to include CSRF token(that expire after say, 30 mins) in pages that require no authentication what so ever.(but my site is doing it, which is why I made this post in the first place) – Optimus Jun 09 '12 at 19:55
  • @jdi I modified the question to the doubt I specifically had, I am sorry if it is very trivial but, if it is in fact I need some thing assertive, because we have our csrf tokens exposed everywhere without any auth. – Optimus Jun 09 '12 at 20:33
  • It isn't a security risk to include them. No matter what, its still a hoop that an attacker has to jump through. Including a CSRF token doesnt make it any easier for them since they have to account for it. And it doesnt matter if its included an a form if they are or arent authenticated. Being authenticated would imply that they actually have greater permissions on the site – jdi Jun 09 '12 at 22:51

2 Answers2

3

This question has a really good couple of answers about the same thing. Also, the last answer on there addresses the fact that it technically would be possible to scrape the form for the token (via javascript), and then submit a post request with it (via javascript). But that the victim would have to be logged in.

The point of the CSRF protection is to specifically prevent tricking a random user. It has nothing to do with client-side exploits. You also have to consider that part of the protection includes denying cross-site origin requests. The request would have to come from the same origin as the target site.

Bottom line, CSRF has value. Its a region of protection, but its not the end all be all. And you can't defend against everything.

Quote from a blog post about CSRF:

Secret hidden form value. Send down a unique server form value with each form -- typically tied to the user session -- and validate that you get the same value back in the form post. The attacker can't simply scrape your remote form as the target user through JavaScript, thanks to same-domain request limits in the XmlHttpRequest function.

... And comments of interest:

I'm not a javascript wizard, but is it possible to load a remote page in a hidden iframe on the malicious page, parse it with javascript to find the hidden token and then populate the form the user is (presumably) about to submit with the right values?

  • David Goodwin on September 24, 2008 2:35 AM

@David Goodwin: No, the same-origin policy would prevent the malicious page from reading the contents of the iframe.

  • Rico on September 24, 2008 3:03 AM
Community
  • 1
  • 1
jdi
  • 90,542
  • 19
  • 167
  • 203
  • Thanks, It looks like I had a wrong sense of what csrf tokens actually did, also, OP from the first link had similar doubts to mine. – Optimus Jun 10 '12 at 09:15
  • In fact, we could say that this question is a possible duplicate of http://stackoverflow.com/questions/10242263/what-is-csrf-protection-really-for-in-django/ but question titles look pretty different. – Optimus Jun 10 '12 at 09:28
0

If your form is public and doesn't require authentication, then there is nothing stopping anyone (including malicious sites/plugins/people) from posting to it. That problem is called Spam, not CSRF.

Read this: http://en.wikipedia.org/wiki/Cross-site_request_forgery

CSRF involves a malicious site posting to your forms by pretending to be an authenticated user.

Vinod Kurup
  • 2,676
  • 1
  • 23
  • 18
  • I'am sorry, I wasn't really specific about the doubt I had, I have edit my question, I have read the csrf wiki page already, it doesn't resolve my doubt. – Optimus Jun 09 '12 at 20:39