Mitigazione basata su token di intestazione di origine Vs

1

OWASP CSRF Prevention cheatsheet parla di due mitigazioni popolari per CSRF - Origin / Referrer controllo dell'intestazione e basato sul token.

Ci sono problemi legati alla mitigazione basata sul controllo dell'origine / referrer che potrebbe essere stata catturata dall'attenuazione basata su token e viceversa? Sto solo cercando di capire se abbiamo bisogno di impiegarli entrambi nelle nostre applicazioni. Vorrei implementarle entrambe se ognuna di esse ha qualche inconveniente che potrebbe essere stata catturata dall'altra (se non c'è nulla in quanto tale - vorrei selezionarne solo una per ora e considerare l'aggiunta di altre difese in misura di profondità in un secondo momento)

    
posta security guy 10.08.2018 - 02:35
fonte

1 risposta

1

L'approccio basato su token è quello che considero il modo più efficace per prevenire gli attacchi CSRF. Se implementato correttamente, la misura basata su token non fallisce mai. Mentre gli altri metodi dipendono totalmente dal browser che non è sotto il proprio controllo e non dovrebbe essere invocato. Ad esempio, EDGE consente comunque di spoofing l'intestazione del referrer sulle richieste GET. Inoltre, gli utenti interessati dalla privacy potrebbero disabilitare l'invio di tali intestazioni. Questo potrebbe interrompere la tua applicazione per tali utenti. Questi approcci basati sull'intestazione sono utilizzati specificamente per ridurre il sovraccarico del server di archiviazione e controllo del token per ciascun utente o per ogni pagina perché non si dovrebbe memorizzare nulla. Ho visto molti inconvenienti nell'utilizzo dell'intestazione Origin / Referrer mentre non ce ne sono per l'approccio basato su token.

E, implementarne uno è sufficiente per prevenire gli attacchi CSRF. Non serve a niente implementare entrambi.

    
risposta data 10.08.2018 - 19:26
fonte

Leggi altre domande sui tag