attacco csrf quando la vittima non ha effettuato l'accesso

Sì, può succedere. Molte pagine reindirizzano alla pagina di accesso quando una richiesta che richiede l'autenticazione fallisce a causa dell'utente che non ha effettuato l'accesso.

Se l'utente non è abbastanza consapevole, potrebbe tentare di accedere pensando che si tratti di un accesso "ordinario" (e non di un accesso causato da una richiesta che richiede l'accesso). In molti casi, la pagina di accesso sarà quindi dopo il login, inviare nuovamente la richiesta inizialmente non riuscita. Ciò può essere ottenuto dal fatto che la richiesta stessa viene salvata in un cookie, o che la richiesta può essere salvata in una sessione legata a un cookie (come un post sul forum) e quindi viene pubblicata dopo che l'utente ha effettuato l'accesso.

Può essere simile ad un attacco di fissazione della sessione, ma invece l'intera richiesta malevola è "fissata" durante il login.

Il resubmitting delle richieste fallite può essere visto come un esempio su molti forum phpBB. Diciamo che stai rispondendo a un thread e la tua sessione scade. Quindi si preme su "Post", si viene reindirizzati alla pagina di accesso e quindi si effettua il re-login. Successivamente, il tuo post è pubblicato, come se fosse "salvato" nel modulo di login. Tuttavia, phpBB utilizza la protezione CSRF. Era solo un esempio di come un tale nuovo invio può accadere.

In alcuni rari casi, la richiesta può essere salvata in un cookie permanente, che rende molto pericoloso un "attacco CSRF non autenticato". Questo è comune con i negozi online, che potrebbero salvare l'intero carrello in un cookie permanente. Se un webshop salverà un ordine completato in un cookie permanente e il webshop impiega una carta di credito salvata ("autorizzazione di pagamento ricorrente"), è molto probabile che un utente possa visitare il sito CSRF, premere il pulsante, notare che non accade nulla. Quindi, giorni o mesi dopo, visita il webshop e prova a effettuare il login, Voilá, un ordine viene immediatamente inserito a causa del cookie permanente, con l'indirizzo di spedizione diretto all'attaccante.

Risposta lunga: Richiesta cross-site Gli attacchi contraffatti si applicano solo dopo l'autenticazione poiché l'intenzione dell'utente malintenzionato modifica uno stato in un sistema back-end.

Quando un utente non è autenticato e fa clic sul link di un utente malintenzionato che intende eseguire un attacco CSRF, verrà visualizzata la schermata di accesso.

Risposta breve: No

Supponendo che l'attacco abbia come obiettivo una funzione che richiede l'autenticazione e non ci sono altri problemi come credenziali predefinite o xss persistenti, ecc. la risposta è no. Altrimenti la risposta è "dipende".

No, l'intera idea di csrf è che un utente malintenzionato agisca per conto di un utente autenticato. Se l'utente non è autenticato, fare clic sul link comporterà lo stesso comportamento di se l'utente malintenzionato avrebbe fatto clic su di esso.

Generalmente, ciò significa che verrà visualizzata una schermata di accesso. A seconda del sito web, potrebbe essere possibile che l'azione desiderata venga eseguita dopo che le credenziali di accesso sono state fornite alla schermata di accesso, quindi se un utente inserisce le proprie credenziali, l'attacco csrf potrebbe ancora funzionare nel tuo esempio.

Ma generalmente, questo non è il modo in cui si verificano gli attacchi CSR. L'utente non deve fare clic su un link o su un pulsante di invio, un utente malintenzionato automatizza le azioni dell'utente ogni volta che è possibile *, in modo che l'utente non debba fare clic su nulla e anche in modo che non diventino sospettosi.

_{* HTML è necessario per le richieste GET csrf e JavaScript per le richieste POST}