Vulnerabilità CSRF/domanda di cookie

Question

Voglio solo ottenere input da persone che sanno. Stavo considerando le vulnerabilità della CSRF e il metodo apparentemente più popolare che conosco per combatterlo. Quel metodo è creare un token nel html restituito e aggiungere un cookie con lo stesso valore. Quindi, se uno script cerca di fare un post, farebbe il have to guess the token thats embedded in the web page affinché abbia successo.

Ma se stanno mira un sito web specifico perché non possono semplicemente utilizzare uno script che

1. chiama un get nella pagina (il cookie verrà restituito anche se lo script non può accedervi)
2. analizza l'HTML e ottiene il token
3. chiama un post con quella pedina in esso (un cookie è tornato sarà rispedito)
4. hanno presentato con successo una forma senza la conoscenza degli utenti

Lo script non ha bisogno di conoscere il contenuto del cookie, è solo utilizzando il fatto che i cookie vengono inviati avanti e indietro per tutto il tempo.

Cosa mi manca qui? Non è possibile? Penso che sia abbastanza spaventoso se ci pensi.

di sotto di questa linea non è richiesta la lettura di rispondere alla domanda :)

banche Questa vulnerabilità sul fatto che l'autenticazione è fatto sulla base di biscotti, che credo sia l'autenticazione principale modo in cui è attualmente in corso.

Un'altra soluzione che posso pensare è che l'autenticazione sia a livello di pagina. Quindi quando accedono, l'html restituito avrà quel token al suo interno. ogni collegamento che fanno clic contiene quel token, quindi quando il server Web riceve una richiesta, ha un modo per identificare l'utente/sessione. Il problema è che se usano una navigazione diversa da quella che sono "non autenticati" (ad esempio digitano un url), anche l'URL non sembra carino perché probabilmente assomiglierebbe a questo:

https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3

Ma io capisco che se la sicurezza è più importante, allora un bel URL è il secondo posto.

Non so tutto sui cookie ma cosa succede se i programmi utente erano un po 'più attenti con i loro cookie?

Ad esempio, cosa succede se i cookie inviati dipendono dalla scheda? A questo punto navighiamo tutti usando le schede, giusto? quindi cosa succede se l'ambito del cookie era la scheda? quindi se ho il mio sito bancario aperto sulla scheda 1 e sto navigando nella scheda 2, qualsiasi script chiamata gets/posts nella scheda 2 invierà solo i cookie accumulati nella scheda 2.

O cosa succede se i cookie sono stati memorizzati/dominio Quindi, mentre sono su example.com, tutti i cookie che ritornano nella raccolta di cookie example.com. e poi quando sono su www.mybankingsite.com tutti i cookie vengono inseriti nella raccolta mybankingsite.com. Quindi, se vado su example.com e viene eseguito uno script che richiama un get/post, l'agente utente invierà solo cookie example.com. Questo è diverso dall'invio dei cookie del dominio richiesto. Per esempio. se uno script chiama get su mybankingsite.com all'interno di una pagina Web di esempio.com, l'utente agente non invierà i cookie mybankingsite.com.

So di avere alcun controllo su ciò che gli agenti utente fare, ma io sono solo esplorando possibilità

Answer 1

Il token CSRF deve essere unico per ogni sessione. Se un server malintenzionato richiede la stessa pagina, riceverà un token diverso. Se provano a richiedere i contenuti della pagina tramite JavaScript sul computer del cliente, la politica di origine identica li preverrà.

Answer 2

Quindi penso che il problema qui diventi il ​​tentativo dell'attaccante di ottenere il contenuto della pagina. Per ottenere la pagina dell'utente autenticato, l'utente malintenzionato deve essere in grado di inviare una richiesta per suo conto e leggere il contenuto. AJAX non invierà richieste tra domini, gli iframe non ti permetteranno di leggere la risposta. Sto lottando per pensare ad altri modi in cui un utente malintenzionato potrebbe ottenere i contenuti per primi.

Un attacco più probabile è l'utilizzo di clickjacking per consentire all'utente di inviare il modulo. Questa tecnica non sembra troppo probabile. (avvertenza: è la sicurezza, possiamo sempre essere sbagliati.)

Answer 3

Qualcuno si preoccupa di condividere un po 'di codice su questo problema perché ho appena hackerato il mio sito (non in produzione) con CSRF. Tutto quello che dovevo fare era il seguente

A: www.badguy.com/ scrivere il seguente codice HTML

img src = "www.goodguy.com/secure/user/delete/5">

Quindi l'amministratore va a www.badguy.com/ e l'immagine invia una richiesta a www.goodguy.com/secure/user/delete/5 dal browser degli utenti, quindi l'amministratore inconsapevolmente solo cancellato un utente. Se crei un loop, hai qualche problema. Aspettarsi che non elimini mai i dati, basta cambiarne lo stato :) ma comunque non mi piace l'aspetto di questo.