Re:Apache Wicket's encrypted URLs don't protect from CSRF
by steakejjs on Sunday November 09, 2014 @02:23AM
(#8579343)
You'll notice a lot of people just have X-CSRF.* header (Stripe for example if you want to check one out). In my opinion you might as well just go the full 9 and actually implement an anti-CSRF solution instead of a quick hack.
x-Requested-By works but your webapp can be built in a way that things like insecure redirects fool you app.
The best solution is just to use tokens.
As Fabian says, just do the CSRF with the encrypted URL if it's not stateful. When Apache Wicket does add state, apparently it's just a small incrementing integer. Like an 8 bit anti-forgery token.
But all of this seems like so much over-engineering when one line of Javascript to add a non-standard request header, and one line on the server to fail if it's not present -- that's all you need?!
What I'm wondering, if you add an X- header with no actual token, do we agree that's enough these days? I remember an old Flash version which allowed adding X-headers outside the SOP, is that the only reason it's not considered fully safe? I think if you're running outdated Flash your machine is completely owned anyway and Anti-CSRF won't make a difference.
[1] - http://security.stackexchange.com/questions/23371/csrf-prote...