CSRF è ancora un vettore di attacco rilevante?

... if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set. And even then, the target server has to implement a CORS header for the request to be successful. ... which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications.

CORS for XHR non è una nuova mitigazione e non è nemmeno una mitigazione contro gli attacchi precedentemente funzionanti. Quando XMLHttpRequest è stato progettato, nessuna richiesta di origine incrociata è stata possibile. E solo con l'introduzione di CORS queste restrizioni sono state modificate e sostituite con richieste di origine incrociata controllate da una politica CORS. In primo luogo, tutti i vecchi browser che non hanno implementato CORS non sono stati influenzati da CSRF tramite XHR.

Ciononostante, CSRF è ancora un problema e può ancora essere utilizzato nello stesso modo in cui poteva in passato. XHR non è affatto necessario come vettore per gli attacchi CSRF e comunque non ha funzionato in passato. Al contrario, è possibile utilizzare immagini intersettoriali, possono essere utilizzati invii di moduli incrociati o simili, che inviano automaticamente le credenziali e i cookie necessari sul sito. Il nuovo samesite attributo per i cookie può essere usato per prevenire questo, ma deve essere impostato in modo esplicito dall'applicazione e non tutti i browser lo supportano ancora.

Pertanto, la corretta protezione CSRF è ancora necessaria oggi.

Cosa succede se la protezione CSRF non è implementata correttamente può essere vista ad esempio da notizie recenti come Hacker che lanciano un massiccio attacco informatico contro 800.000 router DrayTek di Sfruttare la vulnerabilità zero-day .

Cookies and headers needed for authentication are not sent by default in cross site requests.

Questo non è corretto. Se un utente fa clic su un link o pubblica un modulo su evil.com su example.com , i cookie verranno inclusi. L'utente non ha nemmeno bisogno di fare clic sul link o sul pulsante di invio, può essere automatizzato con uno script.

For instance, if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set. And even then, the target server has to implement a CORS header for the request to be successful.

Sì, certo. Ma perché un hacker ha bisogno di XHR quando puoi semplicemente usare un modulo vecchio stile?

So I now wonder, which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications.

I browser non implementano contromisure automatiche, quindi è ancora necessario farlo. I siti vulnerabili continueranno ad essere vulnerabili, indipendentemente dal modo in cui utilizziamo i browser moderni.

In un certo senso hai ragione, però. Modern API: s sono spesso progettate in modo da fornire almeno una protezione CSRF per impostazione predefinita. Ciò accade ad esempio se si esegue l'autenticazione con un'intestazione di autorizzazione invece di cookie o se si accettano solo richieste POST con un corpo JSON.

Se dovessi fare un commento sull'argomento, sarebbe meglio riflettere su ciò che è scritto in questo pezzo.

link

CSRF è ancora rilevante in una condizione simile a IPv4 - Non saremo in grado di eliminare gradualmente i sistemi legacy che sono a loro riservati per un po 'di tempo, e alla fine ne scaturirà una permutazione.

Come sempre; ricorda di applicare patch ai tuoi figli di sistema