Нужно ли защищать запросы JAX-RS от CSRF?

Question

Необходимо ли защищать запросы JAX-RS от CSRF?

К definition REST является апатридом и поэтому не существует идентификатора сеанса (сеансового файла cookie), поскольку сеанса вообще нет (см. Также https://stackoverflow.com/a/15746639/5277820).

My Spring Security Configuration Java:

@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); 
      } 
     } 
    } 
} 

Но я нашел, например, следующий блог: Stateless Spring Security Part 1: Stateless CSRF protection. К сожалению, блог не объясняет, зачем нужна защита CSRF.

Есть ли еще одна атака CSRF без сессии cookie?

Answer 1

Атаки CSRF не требуют сеанса для существования. Атака CSRF заключается в том, чтобы делать что-то от имени пользователя, обманывая его/ее нажатие на ссылку или отправку формы, которая поступает в приложение, в котором пользователь вошел в систему.

Независимо от того, используется ли базовая аутентификация или файл cookie сеанса для определить пользователя не имеет значения.

Обратите внимание, что использование файла cookie не означает, что приложение не является апатридом. Куки, как и обычная проверка подлинности, просто состоит в отправке дополнительного заголовка с каждым HTTP-запросом.

Answer 2

Точки доступа иногда хранятся в файле cookie с защищенным http-только в лучшем случае, поэтому клиентам не нужно беспокоиться о добавлении его в каждом запросе вручную: файлы cookie автоматически прикрепляются к запросам браузеров. Это является причиной того, что защита CSRF должна быть реализована.

В статье вы связаны предлагает есть клиенты создавать и отправлять один и то же уникальное секретное значение в обоих Cookie и пользовательские HTTP заголовка, что довольно умный:

Учитывая сайт разрешен только читать/писать Cookie для своего собственного домена, только реальный сайт может отправлять одинаковое значение как в заголовках .

То есть, если вы получите письмо с поддельным изображением таргетинга http://yourserver.com/admin/deleteAll, например (и сервер обрабатывает его через GET ...), то уникальный секрет не будет установлен в заголовке запроса (старый файл все еще может присутствовать в файле cookie): сервер должен отклонить запрос.