Are JAXRS support services prone to CSRF attacks when content type negotiation is enabled?

Question

I have a RESTful API that has annotations like @Consumes (MediaType.JSON) - in which case is it possible to attack CSRF on such a service? I provide my services using CSRFGuard on the server side or with double sending from the client side. However, when I tried to send POST requests using FORM with enctype = "text / plain", this did not work. This method is explained here. It works if I have MediaType.APPLICATION_FORM_URLENCODED in my consumption annotation. Content matching is useful when I use the POST / PUT / DELETE verbs, but GET is still available, which may be required when viewing.

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

Greetings

Answer 1

JAX-RS is designed to create a REST API, which should be stateless. The cross-reference request routine is NOT a problem when using stateless applications.

How Cross Site Request Forgery works, someone can trick you into clicking a link or opening a link in your browser that will direct you to the site where you are logged in, for example, to some online forum. Since you are already logged in on this forum, an attacker can create a URL, let's say something like this: someforum.com/deletethread?id=23454

This forum program, poorly designed, will recognize you based on the session cookie and confirm that you have the option to delete the stream and actually delete this stream.

That's because the program authenticated you based on the cookie of the session (even based on the cookie "remember me")

There is no cookie in the RESTful API, state is not supported between requests, so there is no need to protect against session hijacking.

As you usually authenticate with the RESTFul api, you send some extra headers. If someone tricks you into clicking on a URL pointing to a soothing API, the browser is not going to send additional headers, so there is no risk.

In short, if the REST API is designed the way it should be - stateless, then there is no risk of faking cross-sites and there is no need to protect CSRF.

Answer 2

Adding another answer as Dmitris's answer mixes serveride state and cookies.

An application is not stateless if your server stores user information in memory for several requests. This reduces horizontal scalability, since you need to find the “right” server for each request.

Cookies are just a special HTTP header. They are often used to identify user sessions, but not every cookie state means a server. The server can also use cookie information without starting a session. On the other hand, using other HTTP headers does not necessarily mean that your application automatically without apathy. If you save user data in the memory of your servers, this is not so. The difference between cookies and other headers is how they are handled by the browser. The most important thing for us is that the browser sends them to each subsequent request. This is problematic if someone is tricking the user into making a request that he does not want to make.

Is this a problem for an API that uses JSON? Yes, in two cases:

• The attacker forces the user to submit the form with enctype=text/plain : Url-encoded content is not a problem because the result cannot 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 using @Consumes(MediaType.JSON) , you should not have problems because it does not accept text/plain and should return 415 status. (Note that JSON may become valid enctype one day, and that will no longer be valid).
• The attacker forces the user to send an AJAX request: A policy of the same origin prevents AJAX requests for other domains, so you can be safe until you disable this protection using CORS headers, for example, Access-Control-Allow-Origin: * .