Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Am I right If I claim on that there doesn't exist any reliable protection against CSRF for a stateles environment today? I have a RESTful service (build with RESTEasy) that needs to be secured against CSRF attacks. I googled for statless CSRF prevention but what I found was only this article which is about double submits. According to the comments on this article, this approach isn't a secure countermeasure.

So, are there any other reliable countermeasures against this attack?

share|improve this question

1 Answer 1

up vote 5 down vote accepted

RESTful services are "stateless", except when it comes to authentication.

Authentication is a state that cannot be avoided and so it is allowed in a RESTful design. In RESTful services, this state is often implemented as a authentication token or in the case of OAuth: an authentication-bearer token. This token should be unknown to the attacker and is therefore: a suitable CSRF synchronization token.

After all if the attacker knew the authentication token, he wouldn't need CSRF to access the API, but he could.

share|improve this answer
    
Right. Just to confirm my own understanding of this: if a given request requires a session token of some kind either in an HTTP header, as a query string param, or in the request body, an attacker would need to know that token in order to forge a valid request (which they wouldn't). This is in contrast to requests that rely on cookie-based sessions which can be exploited because the browser happily sends cookies with any request for that domain. Please confirm this is correct? –  Marplesoft Sep 9 '13 at 19:11
    
Correct. Cookies are automatically included in the payload from the browser to the server for the domain being contacted. Therefore that communication is susceptible to csrf. Any other form of authentication that requires code to package and send its authentication information is not susceptible. In the case of a bearer token, the only way the bearer token is going to be added to the header is through your code. Since any attempt at csrf will not know the token, it cannot add it to its header, therefor you can't be impersonated. –  john west May 15 at 10:16
    
@johnwest, what about if the browser challenges: WWW-Authenticate. Isn't that suspectible? –  Paul Draper Oct 1 at 19:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.