1

A penetration testing is ordered on one of the web sites. I have implemented OWASP CSRF Guard on the web site. It uses custom headers for CSRF protection for AJAX. This got flagged with subject message. No explanation is given. I am not sure if the above statement is true. Why does it invalidate?

Note:

Please note that the presence of the CSRF token in the HTTP header invalidates the CSRF protection.

The OWASP Csrf Guard adds to ajax requests a custom header, "you specify the name". So the http header for my ajax call looks like "csrftoken: 4949-2393-....." This token then gets checked by the filter.

He's saying that this is not an enough protection and an attacker can access the custom http header and value. I did not think this was doable using GET or ajax calls. Assuming the attacker knows the header, (registered on the site), how can he determine the value of the token?

I don't get it.

user3586195
  • 147
  • 1
  • 5
  • 1
    Not very clear what you are asking. Could you please clarify better? –  Aug 19 '15 at 17:48

1 Answers1

1

Using custom headers to mitigate CSRF does work, however, this isn't considered best practice. Best practice is to include a CSRF token as a parameter in all state changing requests to ensure the request is from within the domain. The main concern for using custom headers to mitigate CSRF is that it's unknown if in the future an attacker will be able to send custom headers in cross-site requests.

This post does a really good job explaining why this isn't the best idea.

Community
  • 1
Justin Moore
  • 769
  • 4
  • 9
  • I have read that page but I am not just sending a custom header. I am also changing the token of the custom header. How can an attacker access that? Also frankly with that type of reasoning, you can never be secure. What happens if there is a major bug in one of the browsers? How will one protect against that? – user3586195 Aug 24 '15 at 17:14
  • If you're validating the custom header against a stored value your technique should protect against CSRF indefinitely. Some people prevent against CSRF by only including a custom header and checking for the existence of the header which may not work in the future depending on what features browsers implement. – Justin Moore Aug 24 '15 at 18:15