È necessario proteggere le richieste JAX-RS contro CSRF?

Question

È necessario proteggere le richieste JAX-RS contro CSRF?

Entro definition REST è senza stato e quindi non esiste alcun ID di sessione (cookie di sessione), perché non esiste alcuna sessione (vedere anche https://stackoverflow.com/a/15746639/5277820).

La mia Primavera di configurazione della protezione 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); 
      } 
     } 
    } 
} 

Ma ho trovato ad esempio a seguito blog: Stateless Spring Security Part 1: Stateless CSRF protection. Sfortunatamente il blog non spiega, perché uno ha bisogno di protezione CSRF.

Esiste un altro attacco CSRF senza cookie di sessione?

Answer 1

Gli attacchi CSRF non necessitano di una sessione. Un attacco CSRF consiste nel fare qualcosa per conto di un utente ingannandolo/a facendo clic su un collegamento o inviando un modulo che va a un'applicazione in cui l'utente ha effettuato il login.

Se l'autenticazione di base o un cookie di sessione è utilizzato per identificare l'utente è irrilevante.

Si noti che l'utilizzo di un cookie non significa che l'app non è stateless. Un cookie, proprio come l'autenticazione di base, consiste semplicemente nell'invio di un'intestazione aggiuntiva con ogni richiesta HTTP.

Answer 2

I token di accesso vengono talvolta memorizzati in un cookie (sicuro solo http al meglio), in modo che i clienti non debbano preoccuparsi di aggiungerlo in ogni richiesta manualmente: i cookie vengono automaticamente allegati alle richieste dai browser. Questo è il motivo per cui è necessario implementare la protezione CSRF.

L'articolo si è collegato propone di hanno le clienti a generare e inviare lo stesso valore segreto unico sia un biscotto e un'intestazione HTTP personalizzata, che è abbastanza intelligente:

Considerando un sito sono consentiti esclusivamente per leggere/scrivere un cookie per il proprio dominio , solo il sito reale può inviare lo stesso valore in entrambe le intestazioni .

Cioè, se si riceve una e-mail con un'immagine falsa mira http://yourserver.com/admin/deleteAll per esempio (e il server gestisce attraverso GET ...), l'unico segreto non verrà impostato nell'intestazione della richiesta (un vecchio potrebbe ancora essere presente in un cookie): il server deve rifiutare la richiesta.