1

Do I need to use csrf tokens in my ajax requests?

I think that someone tricking my users to execute malicious ajax requests from another site, to my site, will fail because of the origin policy, which is handled by the browser, am I right?

I don't care about duplicated requests when using ajax, I'm only asking about the attacks. Am I at risk if I don't use csrf in my ajax requests?

HappyDeveloper
  • 12,480
  • 22
  • 82
  • 117
  • Here is another question that I think is the same as this one: http://stackoverflow.com/questions/144696/is-exposing-a-sessions-csrf-protection-token-safe – davidtbernal Feb 09 '11 at 17:35

3 Answers3

1

As per my research, We can reduce the vulnerability by using POST request(for the request which will take side affect). But thing is that we can forge the POST request as well with form submission, cause same origin policy will not applies plain html for submissions. But it applies to request which are getting generated with JS.

So if you use ajax POST request and you are safe if you are using JSON payload. Cause url encoded payload(POST request) can be forged with form submission from other sites. If you use JSON, as it is not possible to send plain text pay load(with out urlform encoded) with html form submission you are safe. Because with ajax POST request if you use urlform encoded data payload it can be forged with POST form submission.

neotam
  • 2,611
  • 1
  • 31
  • 53
0

The fact that you are using Ajax doesn't mean that others have to as well. Your server won't be able to distinguish a request made by XHR from one made by <form> submission. (Yes XHR usually adds a header identifying itself, but this is not hard to spoof.)

So yes, you do need to consider CSRF attacks.

Edit

Django have a POC, which is why they and Ruby on Rails now implement CSRF protection on AJAX requests.

Once again, please check your facts before downvoting, and explain what the downvote is for.

Community
  • 1
  • 1
OrangeDog
  • 36,653
  • 12
  • 122
  • 207
  • I don't understand how an attacker could lure the users to make fake ajax requests. Where can I see an example? – HappyDeveloper Jan 30 '11 at 00:49
  • But my server will reject non-ajax requests for ajax pages. I thought you were saying that they could easily fake the ajax headers. Nevermind, I found my answer somewhere else. – HappyDeveloper Jan 30 '11 at 23:40
  • @HappyDeveloper - How will your server know whether a request was XHR or not? – OrangeDog Jan 31 '11 at 00:16
  • To downvoters: unless you leave an explanation it's not very helpful. – OrangeDog Feb 01 '11 at 15:02
  • OrangeDog: you know it was an XHR because of the AJAX header. Is there a way to forge that within a browser? If you're not within a browser, the user is not authenticated, and it's a different type of attack. (I didn't downvote, but if I had, that's why I would have.) – davidtbernal Feb 09 '11 at 15:02
  • @notJim - The whole point of CSRF protection is to never trust the browser. – OrangeDog Feb 09 '11 at 16:17
  • @OrangeDog I don't think that's the case at all. If the user installs a compromised browser, no CSRF token is going to help you. Just like if you have an XSS vulnerability, your user's CSRF token will be leaked. The point of CSRF protection is to prevent someone else from accessing the site on your user's behalf, by validating a secret that's shared between you and an authenticated user. – davidtbernal Feb 09 '11 at 16:44
  • @notJim - If that were the case, everyone would just check the Referer and have done with it. – OrangeDog Feb 09 '11 at 17:00
  • @OrangeDog Checking the referrer *is* commonly cited as a first-pass approach to dealing with CSRF. cf http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Checking_Referer_Header – davidtbernal Feb 09 '11 at 17:29
  • @notJim - "A CRLF vulnerability in the http client could allow an attacker manipulate the HTTP request header" - which is why you also can't just rely on there being an XHR header. – OrangeDog Feb 09 '11 at 17:32
  • Yes, that's what I asked about originally. There aren't enough details there to decide whether it's actually a problem or not. If there's a vulnerability that allows the attacker to violate the same origin policy, than your CSRF tokens are trivially compromised anyway. – davidtbernal Feb 09 '11 at 17:42
  • This issue is discussed further in the comments on this answer: http://stackoverflow.com/questions/144696/is-exposing-a-sessions-csrf-protection-token-safe/533444#533444 – davidtbernal Feb 09 '11 at 17:43
  • @notJim - Read the pages that you are linking to. There are plenty of ways to intercept header fields that do not violate the same origin policy. – OrangeDog Feb 09 '11 at 17:44
0

This is how we solved the problem with CSRF token in Ajax requests http://mylifewithjava.blogspot.com/2010/11/implicit-csrf-protection-of-ajax_22.html

Stefan Rasmusson
  • 5,445
  • 3
  • 21
  • 48