CSRF non è un problema di sicurezza del browser?

Question

Per quanto riguarda gli attacchi di falsificazione delle richieste tra siti (CSRF), se i cookie sono il metodo di autenticazione più utilizzato, perché i browser Web consentono l'invio di cookie di alcuni domini (e verso quel dominio) da una pagina generata da un altro dominio?

CSRF non è facilmente prevenibile nel browser impedendo tale comportamento?

Per quanto ne so, questo tipo di controllo di sicurezza non è implementato nei browser Web, ma non capisco perché. Ho sbagliato qualcosa?

Informazioni su CSRF:

• Su wikipedia
• Sul codice horror

Modifica: penso che i cookie non debbano essere inviati su HTTP POST nel caso precedente. Questo è il comportamento del browser che mi sorprende.

Answer 1

Perché il browser non invia i cookie?

Il sito A ( http://www.sitea.com ) imposta un cookie per l'utente.

L'utente accede al sito B ( http://www.siteb.com ). Il sito B include l'integrazione con il sito A: fare clic qui per eseguire un'operazione sul sito A! Gli utenti fanno clic su & Quot; qui & Quot ;.

Per quanto può dire il browser, l'utente sta prendendo una decisione consapevole di fare una richiesta al sito A, quindi la gestisce allo stesso modo in cui gestirà qualsiasi richiesta al sito A, e che include l'invio di cookie nel sito A in la richiesta al sito A.

---

Modifica : penso che il problema principale qui sia che tu pensi che ci sia una distinzione tra cookie di autenticazione e altri cookie. I cookie possono essere utilizzati per memorizzare qualsiasi cosa: le preferenze dell'utente, il tuo ultimo punteggio più alto o un token di sessione. Il browser non ha idea di cosa venga utilizzato per ciascun cookie. Voglio i miei cookie siano sempre disponibili per il sito che li ha impostati e voglio che il sito si assicuri che prenda le precauzioni necessarie.

O stai dicendo che se cerchi quot; gmail " ;, quindi fai clic sul link che ti porta a http://mail.google.com , non dovresti avere effettuato l'accesso, anche se hai detto a Gmail di rimanere connesso , perché hai fatto clic su il link da un altro sito?

Answer 2

Non è che un browser stia inviando il cookie da o verso un dominio esterno, è il fatto che sei autenticato e il sito non sta convalidando l'origine della richiesta, quindi lo tratta come se la richiesta è venuto dal sito.

Per quanto riguarda il fatto che un browser non lo debba o meno ... che dire delle molte situazioni in cui sono desiderabili richieste tra siti?

Modifica: per essere chiari, il tuo cookie non viene inviato attraverso domini.

Answer 3

Non so che ci sia molto che il browser possa fare in quella situazione poiché il punto di un attacco XSRF è indirizzare il browser verso un altro punto dell'applicazione che farebbe qualcosa di brutto. Sfortunatamente, il browser non ha idea se la richiesta che sta per inviare sia dannosa o meno. Ad esempio, dato il classico esempio di XSRF:

<img src="http://domain.com/do_something_bad" />

non è chiaro al browser che sta succedendo qualcosa di brutto. Dopo tutto, come è possibile conoscere la differenza tra questo e questo:

<img src="http://domain.com/show_picture_if_authenticated" />

Answer 4

Molti vecchi protocolli hanno grosse falle di sicurezza: ripensiamo al . Come praticamente qualsiasi sicurezza di rete, è responsabilità degli end-point; sì, fa schifo che dobbiamo risolvere da soli, ma è molto più difficile da risolvere a livello di browser. Ce ne sono alcuni ovvi (& Lt; img src = & Quot; logoff.php & Quot; & Gt; sembra dannatamente sospetto, giusto?), Ma ci saranno sempre casi limite. (Forse è uno script GD in un file PHP dopo tutto.) Che dire delle query AJAX? E così via ...

Answer 5

I cookie per un sito non vengono mai inviati a un altro sito. In effetti, per implementare un attacco CSRF riuscito, l'attaccante non deve avere accesso a questi cookie.

Fondamentalmente, un utente malintenzionato inganna l'utente, che è già connesso al sito Web di destinazione, facendo clic su un collegamento o caricando un'immagine che farà qualcosa sul sito di destinazione con le credenziali dell'utente.

Cioè, l'utente sta eseguendo l'azione e l'attaccante ha indotto l'utente a farlo.

Answer 6

Alcune persone hanno affermato di non pensare che il browser possa fare molto.

Vedi questo:

http: //people.mozilla. org / ~ bsterne / contenuti-security-policy / origine-header-proposal.html

È una panoramica di una proposta per una nuova intestazione HTTP per aiutare a mitigare gli attacchi CSRF.

Il nome dell'intestazione proposto è " Origine " ed è fondamentalmente il " Referer " intestazione meno il percorso, ecc.