Is it necessary to protect JAX-RS requests against CSRF?

Question

By definition REST is stateless and therefore exists no session id (session cookie), because there is no session at all (see also https://stackoverflow.com/a/15746639/5277820).

My Spring Security Java Configuration:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Configuration
    @Order(1)
    public static class JaxRsWebSecurityConfigurationAdapter extends WebSecurityConfigurerAdapter {

        @Override
        protected void configure(final HttpSecurity http) throws Exception {
            http
                .antMatcher("/services/**")
                .csrf().disable()
                .authorizeRequests()
                    .antMatchers(HttpMethod.OPTIONS, "/services/**").permitAll()              
                    .anyRequest().hasAuthority("ROLE_user")
                    .and()
                .httpBasic()
                    .and()
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);
             }
        }
    }
}

But I found for example following blog: Stateless Spring Security Part 1: Stateless CSRF protection. Unfortunately the blog does not explain, why one needs CSRF protection.

Is there any other CSRF attack without session cookie?

you only need to protect them from CSRF if your site is used by web browsers. If it's only used by say curl, then you don't need to worry about CSRF — Neil McGuigan, Oct 19 '15 at 21:00

score 3 · Accepted Answer · answered Oct 19 '15 at 10:29

3

CSRF attacks don't need a session to exist. A CSRF attack consists in doing something on a user's behalf by tricking him/her into clicking a link or submitting a form that goes to an application where the user is logged in.

Whether basic authentication or a session cookie is used to identify the user is irrelevant.

Note that using a cookie doesn't mean that the app is not stateless. A cookie, just like basic authentication, simply consists in sending an additional header with each HTTP request.

answered Oct 19 '15 at 10:29

JB Nizet

678,734
91
1,224
1,255

Thanks. For [Basic Authentication Scheme](https://en.wikipedia.org/wiki/Basic_access_authentication) I found the relevant part in [RFC 2617](https://tools.ietf.org/html/rfc2617#page-5): "A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server." – dur Oct 19 '15 at 11:15

sp00m · Answer 2 · 2015-10-19T11:20:30.260

Access tokens are sometimes stored in a (secured http-only at best) cookie, so that clients don't have to bother adding it in each request manually: cookies are automatically attached to the requests by the browsers. This is a reason why CSRF protection needs to be implemented.

The article you linked proposes to have the clients generate and send the same unique secret value in both a Cookie and a custom HTTP header, which is quite smart:

Considering a website is only allowed to read/write a Cookie for its own domain, only the real site can send the same value in both headers.

That is, if you receive an email with a fake image targeting http://yourserver.com/admin/deleteAll for example (and the server handles it through GET...), the unique secret won't be set in the request header (an old one could still be present in a cookie): the server must reject the request.

I know, that cookies are automatically attached to the requests by the browsers, but I didn't know, that the authorization header is also automatically attached by the browser. The last one is indeed a problem with stateless (and cookie-less) JAX-RS requests. — dur, Oct 19 '15 at 11:25

Is it necessary to protect JAX-RS requests against CSRF?

2 Answers2

Linked