8

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?

Improve this question

1 Answer 1

Reset to default
12

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.

Improve this answer
4
  • 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, 2013 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, 2014 at 10:16
  • @johnwest, what about if the browser challenges: WWW-Authenticate. Isn't that suspectible?
    – Paul Draper
    Oct 1, 2014 at 19:58
  • What if authentication is done with no token, e.g. with a SSL client certificate, WWW-Authenticate or even a cookie?
    – David Balažic
    May 14, 2015 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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