I cookie dello stesso sito saranno una protezione sufficiente contro CSRF e XSS?

Innanzitutto, una definizione di Chrome :

Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.

Quindi cosa protegge da questo?

CSRF?

I cookie con lo stesso sito possono prevenire efficacemente gli attacchi CSRF. Perché?

Se imposti il cookie di sessione come stesso sito, verrà inviato solo se una richiesta viene emessa dal tuo sito. Quindi un attacco CSRF standard in cui l'aggressore attira la vittima sul sito http://malicious.com che registra una richiesta su http://bank.com/transfer.php?amount=10000&receiver=evil_hacker non funzionerà. Poiché malicious.com non è la stessa origine di bank.com , il browser non invierà il cookie di sessione e transfer.php verrà eseguito come se la vittima non avesse effettuato l'accesso.

Questo è molto simile a come l'impostazione di un'intestazione HTTP X-Csrf-Token ti protegge da CSRF - di nuovo c'è qualcosa che viene inviato solo se la richiesta viene emessa dal tuo dominio. La proprietà dello stesso sito trasforma il tuo cookie di sessione in un token CSRF.

Quindi il problema è stato risolto? Beh, un po '. Ci sono alcuni avvertimenti:

• Funzionerà solo per i browser che implementano questa funzione. Finora, pochissimi lo fanno. A meno che non si desideri lanciare chiunque utilizzi un browser leggermente più vecchio sotto il bus, sarà comunque necessario implementare un token CSRF vecchio stile.
• Se hai bisogno di un controllo più dettagliato, questo non sarà sufficiente. Se si esegue un sistema che visualizza contenuti utente non attendibili, come un forum, non si desidera che le richieste provenienti dai post degli utenti siano considerate valide. Se qualcuno pubblica un link a http://myforum.com/?action=delete_everything , non vuoi che questo elimini qualcosa solo perché un utente fa clic su di esso. Con un token CSRF tradizionale, puoi controllare esattamente quando viene utilizzato. Con un cookie per lo stesso sito, non puoi.
• Restano validi gli stessi vecchi avvertimenti relativi alle protezioni CSRF vecchio stile. Se hai una vulnerabilità XSS, nessuna protezione CSRF in questo mondo ti proteggerà.

Detto ciò, lo stesso cookie del sito è ancora una buona cosa che dovrebbe essere usato insieme alle difese tradizionali come difesa in profondità.

XSS e XSSI?

Il cookie dello stesso sito non fa nulla per proteggerti dagli attacchi XSS ordinari. Se un hacker riesce a ingannare il tuo sito per echeggiare lo script dall'URL sul tuo sito, verrà eseguito come proveniente dalla tua origine (dopotutto lo è), e quindi i cookie di sessione saranno comunque inviati con tutte le richieste dello script immesso rende al tuo dominio.

Se leggi attentamente la citazione nel tuo post, vedrai che dice XSSI con un I alla fine, e non con XSS. L'I rappresenta l'inclusione e XSSI è correlato a, ma diverso da, XSS. Qui è una buona spiegazione di XSSI e come differisce da XSS:

XSSI is a form of XSS that takes advantage of the fact that browsers don't prevent webpages from including resources like images and scripts, which are hosted on other domains and servers. [...] For example, if Bank ABC's site has a script that reads a user's private account information, a hacker could include that script in their own malicious site (www.fraudulentbank.com) to pull information from Bank ABC's servers whenever a client of Bank ABC visits the hacker's site.

I cookie con lo stesso sito ti proteggono da XSSI, poiché un cookie di sessione non verrebbe inviato con la richiesta dello script e non restituirebbe quindi alcuna informazione sensibile. Tuttavia, per XSS ordinario non fa differenza.

Dipende dai browser che desideri supportare e dal modo in cui il tuo sito è attualmente impostato.

Se stai supportando esclusivamente i browser che supportano la funzione, dovrebbe essere sufficiente se sei disposto a:

• Non inviare cookie con la navigazione di primo livello (questo è abbastanza restrittivo in quanto non è possibile collegarsi esternamente alle pagine loggate)
• Accertati che le operazioni non utilizzino GET (o qualsiasi sicuro metodo) per eseguire un'operazione altrimenti ti apri per collegare attacchi come nella risposta precedente

Se puoi vivere senza navigazione di primo livello alle pagine loggate da siti esterni allora SameSite: 'strict' potrebbe essere adatto, questa opzione rende il cookie specificato non inviato con qualsiasi richiesta fatta di cross-origine ( compresi i clic sui collegamenti, ecc.)

Se hai bisogno di collegarti alle pagine loggate da siti esterni, devi assicurarti che no si verifichino cambiamenti osservabili da un GET (o qualsiasi safe metodo) al server e dovrebbe invece utilizzare SameSite: 'lax' . Se è possibile garantire questo vincolo, anche i collegamenti inviati dall'utente dovrebbero essere sicuri (dagli attacchi CRSF comunque).

Garantire uno di questi vincoli probabilmente non è banale in un code-base esistente (oltre ai moderni requisiti del browser) quindi non raccomanderei di rimuovere i token CSRF se li stai già utilizzando, dato che molti posti sono ancora abuso GET per le operazioni di attivazione.

Se stai iniziando un nuovo progetto e non stai pianificando di supportare i browser che non supportano la funzione, probabilmente vale la pena considerarlo in quanto è fondamentalmente solo una singola riga di codice, ma assicurati di essere a conoscenza di entrambe le modalità 'lax' e 'strict' e quali restrizioni dovrai seguire con entrambe.

Riguardo a SameSite: 'strict' : se stai utilizzando SameSite: 'strict' e un utente fa clic su un link esterno in una parte limitata del sito, allora potrebbe mostrare una schermata iniziale che chiede se vogliono procedere. Lo consiglio vivamente se le risorse non sono destinate ad essere collegate esternamente, nel qual caso un collegamento potrebbe essere un attacco / trucco.

Avendo una tale schermata iniziale se l'utente sceglie di procedere, non avrà ancora bisogno di effettuare nuovamente l'accesso perché cliccando sul tuo sito invierai SameSite -cookies perché è effettivamente la stessa origine.

Se vuoi che il reindirizzamento avvenga automaticamente, potresti anche aggiungere un'intestazione Refresh: 0 per le pagine che conosci sicure (che è anche un'ottima opportunità per verificare se una determinata pagina è effettivamente sicuro di essere collegato esternamente, se non si può tornare alla schermata iniziale menzionata sopra). Lo svantaggio principale di questo contro SameSite: 'lax' è che si finisce per ripetere due volte la navigazione.