Is Cross-Site Request Forgery possible against a stateless RESTful service?
I'm not talking about pseudo-REST where the server remembers that you're logged in via a cookie. I'm talking about pure no-application-state-on-the-server REST with no cookies.
I'm using SSL and Basic Authentication. For every request, that Authorization header has to be there. There is no "session" in the JSP sense, although there is some sort of session at the SSL level.
So let's assume I'm viewing the legitimate web page that makes Ajax requests, and somehow I go to a different page in the same tab or a different tab, and that page makes the same Ajax request. (I'm assuming there is no malicious code on the legitimate web page; that's a different thing entirely and anything is possible in that case.)
When the second page makes the Ajax request, will the browser put on the same Authorization header? i.e. will the browser say "Oh, you want to go THERE again? Hey, I just happen to still have the key!"?
Also, couldn't the malicious script do the xhr request, then in the callback take the request from the ioargs, get the Authorization header and un-Base64 the name and password?
Disclaimer: I am not a security expert.
Using HTTP Basic Auth does not prevent CSRF attacks via GET requests. E.g. somebody else can include an img tag in their HTML page that does a GET on some well-known URI, and your browser will happily send along the basic auth info. If the GET operation is "safe" (which is the #1 rule for anything claiming to be RESTful), this will not create a problem (beyond wasted bandwidth).
Ajax is not a problem because of the same-origin policy.
Only including a server-generated token in the HTML you generate, and validating its presence in form submission requests, will protect you from somebody else simply including a "foreign" form in their pages. You might limit this to the content types generated by browsers; no need to do so for XHR requests.