Will "Authorization: Bearer" nell'intestazione della richiesta corregge gli attacchi CSRF? [duplicare]

Would this approach actually work to prevent CSRF attacks?

Sì. Un utente malintenzionato non può fare in modo che un browser invii una richiesta che includa l'intestazione di autorizzazione con il token al portatore corretto. Questo è per due motivi:

• L'autore dell'attacco non può impostare l'intestazione authroization.
• L'autore dell'attacco non conosce il valore corretto del token, quindi non saprebbero a cosa impostarlo.

Tuttavia, questo potrebbe essere sensibile alle modifiche apportate all'applicazione. Ad esempio, se un giorno qualcuno decide di cambiare il sistema di autenticazione in base a un cookie, potrebbe non rendersi conto che sta disattivando la protezione CSRF facendo così.

Inoltre, nel caso in cui il valore dell'intestazione richiesto sia prevedibile, un criterio CORS che consente di impostare l'intestazione potrebbe causare problemi.

Per quanto riguarda la domanda SO collegata, non sono sicuro di aver compreso la risposta accettata. Ma se guardi la seconda risposta , la tua situazione è di tipo 2 e non di tipo # 1.

I know If I am vulnerable to XSS attacks my cookies can be read and the bearer tokens can be stolen. But can the injected XSS create a the Authorization: Bearer header and append the stolen value from cookie?

Sì, puoi farlo se puoi inserire codice.

Se si dispone di una vulnerabilità XSS, consentirà all'utente malintenzionato di aggirare qualsiasi protezione CSRF inserita. Quindi le preoccupazioni per XSS non possono essere realmente utilizzate per favorire una forma di protezione CSRF rispetto a un'altra - a fronte di XSS sono tutte nulle.

Una leggera differenza è che il tuo token non può essere contrassegnato come solo HTTP, dal momento che devi accedervi da JS per inserirlo nell'intestazione. Di conseguenza, un utente malintenzionato XSS può rubarlo e quindi inviare comodamente richieste dal proprio computer. Se il token di autenticazione è HTTP, solo l'hacker deve fare in modo che il codice inserito invii le richieste, il che è un po 'complicato ma non impossibile.

Può funzionare, ma XSS comprometterà completamente la sessione.

L'intento delle attenuazioni CSRF è limitare l'ambito di chi può inviare dati dal browser di un utente al server e fare in modo che qualcosa accada. Gli attacchi CSRF funzionano affidandosi alle proprietà speciali dei browser Web in quanto generalmente includono i cookie in tutte le richieste e l'hacker ha solo bisogno di ottenere il browser per inviare una richiesta all'URL di destinazione . Si attenua questo facendo in modo che la richiesta includa dati che non fanno parte della richiesta normalmente inviata dal browser; per esempio. un'intestazione personalizzata o un campo modulo, iniettato da JavaScript.

Un token al portatore nell'intestazione dell'autorizzazione richiede necessariamente l'aggiunta di JavaScript perché il browser non lo includerà mai (salvo NTLM / Nego / etc, ma questo è un altro argomento). In modo che soddisfi i requisiti sopra ragionevolmente bene.

Il problema è che qualsiasi JavaScript eseguito su quella pagina può fare esattamente la stessa cosa del tuo codice aggiungendo l'intestazione perché qui non ci sono limiti di sicurezza. Ciò vuol dire che sei protetto da qualsiasi forma di XSS che consente l'esecuzione di codice arbitrario. In effetti, ti mette in una posizione più debole perché possono semplicemente rubare il tuo token e fare ciò che vogliono con esso al di fuori dei limiti di un browser, mentre un cookie protetto non può essere rubato perché non è accessibile da JavaScript.

Quindi ... sei al sicuro se puoi prevenire completamente l'XSS, ma è un compito difficile nelle migliori circostanze. Detto questo, l'aggiunta di un cookie nel mix non aiuta necessariamente perché XSS può generare richieste che aggiungono il token e il browser includerà comunque felicemente il cookie.