Protecting against CSRF when a form is being submitted via an AJAX call

Question

I'm using anti-CSRF tokens on all my forms to prevent CSRF attacks. Also, the tokens are being saved in the $_COOKIE variable to validate against the value I get from the form. I'm resetting the token each time a form is loaded.

But there are a few forms that are using $.post, i.e. AJAX to submit and getting a JSON response.

The $_COOKIE variable is not set because of AJAX being used.

Is there a workaround or am I doing something wrong?

EDIT: Adding client-side and server-side code sample

Client-side:

<?php
$tokenVal = md5(uniqid(mt_rand(), true));
setcookie ("token", $tokenVal);
?>
<form action="target.php" method="post" name="abc">
<input type="text" name="city" id="city" value="abc" size="25" maxlength="10">
<input type="hidden" name="csrf" value="<?php echo $tokenVal; ?>">
<a class="cssButton buttonColor right" id="billToSubmit">Save</a>
</form>

---

Server-side:

if($_POST['csrf'] == $_COOKIE['token']) {
//process further
} else {
die("Invalid form source")
}

The form is being submitted using $.post. The problem I'm facing is that $_POST['csrf'] is never equal to $_COOKIE['token']!

Answer 1

Assuming the CSRF token is available to JavaScript, you can use setRequestHeader to attach the request token manually and modify your server to look for the request token in the cookie header, or for requests that should be accessible via XHR in the header you supply.

Answer 2

Most Javascript frameworks add a specific header when POSTing requests, such as X-Requested-With: AJAX. In theory, on the backend you could check for the existence of this header to be sure that your form was submitted via AJAX (an attacker should not be able to make a third party add a custom header to a form submission). Since AJAX requests can only come from the same domain, you should be safe from CSRF attacks.

But it has been discovered that in the presence of some combinations of browser plugins it is actually possible for attacker to craft a request with custom headers. This makes the above approach not so sound. Today the preferred protection is to pass the CSRF token to the client even for AJAX submissions. For instance you can still add it into a hidden field and then read it with javascript.

EDIT: With regards to the $_COOKIE$ variable not being set in AJAX requests, I do not understand your point. You can actually set cookies in AJAX requests, and even normal cookies will be preserved, provided they are not http-only.

Answer 3

This is a valid form of CSRF protection because the attacker will not know the value of the cookie there for the attacker will not have a valid value for the token post variable. This method does not require a per-user state which is a benefit.

The CSRF Prevention Cheat Sheet is a good resource.

Answer 4

If you are using cookies to store (and retrieve) the CSRF token, that doesn't really mitigate the CSRF vulnerability. Correction: As clarified in comments, this line isn't true for the way Gaurav is using CSRF tokens.

Instead of making your own CSRF prevention scheme, why not use something like PHP CSRF Guard