3 ms·
Preventing CSRF Attacks with AJAX and HTTP Headers
- xSwag 14y agoI 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 http://www.ghostery.com [2] - http://www.youtube.com/redirect?q=http://youtube.com/page http://www.youtube.com/redirect?q=http://youtube.com/page
- nbpoole 14y agoOh 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.
- drhowarddrfine 14y agoSo...never mind.
- ck2 14y agoThere are comments on stackoverflow that setting headers via xhr isn't completely reliable.
- james-skemp 14y agoArticle was seemingly invalid in 2011. Not sure why it's on page one now.