5

I have a RESTful API which has annotations like @Consumes(MediaType.JSON) - in that case, would the CSRF attack still be possible on such a service? I've been tinkering with securing my services with CSRFGuard on server side or having a double submit from client side. However when I tried to POST requests using FORM with enctype="text/plain", it didn't work. The technique is explained here This works if I have MediaType.APPLICATION_FORM_URLENCODED in my consumes annotation. The content negotiation is useful when I'm using POST/PUT/DELETE verbs but GET is still accessible which might need looking into.

Any suggestions or inputs would be great, also please let me know if you need more info.

Cheers

opensourcegeek
  • 5,552
  • 7
  • 43
  • 64

2 Answers2

10

JAX-RS is designed to create REST API which is supposed to be stateless. The Cross Site Request Forgery is NOT a problem with stateless applications.

The way Cross Site Request Forgery works is someone may trick you to click on a link or open a link in your browser which will direct you to a site in which you are logged in, for example some online forum. Since you are already logged in on that forum the attacker can construct a url, say something like this: someforum.com/deletethread?id=23454

That forum program, being badly designed will recognize you based on the session cookie and will confirm that you have the capability to delete the thread and will in fact delete that thread.

All because the program authenticated you based on the session cookie (on even based on "remember me" cookie)

With RESTful API there is no cookie, no state is maintaned between requests, so there is no need to protect against session hijacking.

The way you usually authenticate with RESTFul api is be sending some additional headers. If someone tricks you into clicking on a url that points to restful API the browser is not going to send that extra headers, so there is no risk.

In short - if REST API is designed the way it supposed to be - stateless, then there is no risk of cross site forgery and no need to CSRF protection.

Dmitri
  • 34,780
  • 9
  • 39
  • 55
  • 5
    Your RESTful API could be behind a security framework, like spring security which means you would need to be authenticated by the framework. In that case it writes a cookie to identify you as an authenticated user. Once the user is identified then the usual service calls to GET/POST/DELETE/PUT data will be available. So in this case the service itself isn't stateless however the service is behind a security framework which has state. Anyway, my main interest was to check if someone was able to perform a CSRF attack when content type negotiation is enabled as I could not crack it through. – opensourcegeek Apr 01 '13 at 15:59
  • 1
    That would be a bad design. API client may be some app, not a browser and will not expect to receive cookies at all. Using cookies in REST API is a pretty bad practice. – Dmitri Apr 01 '13 at 16:26
  • Absolutely, right now our API is secured using both basic and form based authentication. So some other app which is not a browser comes through basic auth, it sends username and security token on each request over HTTPS. These are users generated by system and they have access to part of the API. However in a browser based app I had to authenticate user using form based authentication. You can avoid trawling through users to get the principal on each request if its held in the session after the first check. – opensourcegeek Apr 01 '13 at 20:15
1

Adding another answer as Dmitri’s answer mixes serverside state and cookies.

An application is not stateless if your server stores user information in the memory over multiple requests. This decreases horizontal scalability as you need to find the "correct" server for every request.

Cookies are just a special kind of HTTP header. They are often used to identify a users session but not every cookie means server side state. The server could also use the information from the cookie without starting a session. On the other hand using other HTTP headers does not necessarily mean that your application is automatically stateless. If you store user data in your server’s memory it’s not. The difference between cookies and other headers is the way they are handled by the browser. Most important for us is that the browser will resend them on every subsequent request. This is problematic if someone tricks a user to make a request he doesn’t want to make.

Is this a problem for an API which consumes JSON? Yes, in two cases:

  • The attacker makes the user submit a form with enctype=text/plain: Url encoded content is not a problem because the result can’t be valid JSON. text/plain is a problem if your server interprets the content not as plain text but as JSON. If your resource is annotated with @Consumes(MediaType.JSON) you should not have a problem because it won’t accept text/plain and should return a status 415. (Note that JSON may become a valid enctype one day and this won’t be valid any more).
  • The attacker makes the user submit an AJAX request: The Same Origin Policy prevents AJAX requests to other domains so you are safe as long as you don’t disable this protection by using CORS-headers like e.g. Access-Control-Allow-Origin: *.
lefloh
  • 10,653
  • 3
  • 28
  • 50