
Preventing CSRF Attacks with AJAX and HTTP Headers - swah
https://nealpoole.com/blog/2010/11/preventing-csrf-attacks-with-ajax-and-http-headers/
======
nbpoole
Oh wow, I wrote this post a while ago! :-)

It was a neat little idea to play around with when I first wrote the post,
since setting X-Requested-With on an arbitrary domain requires a violation of
the same-origin policy. But as I point out at the top of the post, there was
at least one recent case of a same-origin violation (via the Flash 307 bug)
that allowed for arbitrary headers to be written.

CSRF tokens, whether they're in headers or in a form, are the more secure way
to prevent an attack. They require a violation of the same-origin policy where
an attacker can read (at least part of) the HTTP response sent by your server.
If an attacker can do that, you already have larger issues.

------
xSwag
I don't think that HTTP headers are enough and feel that setting csrf tokens
is the best approach to this. My reasoning behind this is that there are a lot
of privacy plugins[1] that people use that interfere with the headers and
using referer header is even worse because a lot of websites have redirection
vulnerabilities eg if you want to be returned to the page you were at after
logging into a website the url would be something like login.php?url=/page/id
, a lot of websites do not sanatize this which would render this useless. It
is also not an option for some websites that must have a function like this, a
prime example of this is Youtube[2] which uses csrf token (hidden fields) in
forms to mitigate this issue.

[1] - <http://www.ghostery.com> [2] -
<http://www.youtube.com/redirect?q=http://youtube.com/page>

------
ck2
There are comments on stackoverflow that setting headers via xhr isn't
completely reliable.

~~~
james-skemp
Article was seemingly invalid in 2011. Not sure why it's on page one now.

