Quali sono le implicazioni del rischio di non verificare l'intestazione del referer sul modulo di accesso?

Un attacco CSRF cerca di sfruttare "la fiducia che un sito ha nel browser di un utente" (così dice la pagina di Wikipedia, ed è ben detto). Riguarda il server che accetta una richiesta dal client, in virtù della richiesta che viene fornita con alcune caratteristiche di autenticazione che fanno credere al server che proviene da un utente genuino (che fa) e sotto il controllo consapevole dell'utente reale (che è falso). La "caratteristica di autenticazione" sarebbe in genere un valore del cookie (accettabile per il server) o HTTPS con l'autenticazione del client basata su certificato.

Per una pagina di accesso , il server non si fida della richiesta dal client. Questo è il punto di una pagina di accesso: per inizializzare fiducia. La pagina di login si aspetta un login e una password precisamente perché non ci sarà nulla che la richiesta possa venire, il che renderà il server più felice e lo distrarrà dalla sua azione prevista, che è quella di verificare il coppia di login + password. Pertanto, gli attacchi CSRF non si applicano a questa pagina.

Puoi ancora controllare il campo Referer per verificare la presenza di "affari di pesce" (se è assente o sbagliato, allora qualcosa è sicuramente sbagliato), ma in realtà non cambierà la sicurezza.

Qual è l'implicazione di verificarlo? L'intestazione del referer:

• può essere falsificato dal client
• può essere completamente omesso dal client (notoriamente quando passa attraverso TOR / proxy)
• non garantisce che l'utente in realtà è venuto da lì

L'intestazione del referente viene inviata come cortesia dal tuo browser, non è un requisito RFC HTTP. Vedi qui per i dettagli sull'intestazione: link .

Dovrebbe quindi essere ovvio che questa intestazione non ha alcun valore e non dovrebbe essere una garanzia di qualsiasi cosa . Inoltre, chiunque sia abbastanza intelligente può rovinarlo. Se si desidera garantire che i dati del modulo di accesso provengano dal modulo di accesso, creare un controllo che tenti di trovare un valore univoco, generato in modo casuale, basato sull'utente (o basato su un navigatore). Questo sarà molto più affidabile (ma, a seconda dell'implementazione, non necessariamente a prova di proiettile) di un'intestazione Referer.

Per un modulo di accesso - non tanto. La maggior parte di ciò che potrebbe accadere è un sito ben noto come Facebook potrebbe fare il ladro e utilizzare le macchine dei loro clienti (tramite richieste POST da un modulo incorporato attivato da javascript) come parte di un'entità simile a botnet per potenziare il modulo di accesso.

Ma è piuttosto improbabile, quindi non c'è alcun problema nel non controllare i referer al login.

Si noti che il resto del sito Web, dopo il login, dovrebbe controllare i referenti su qualsiasi tipo di richiesta (GET o POST) con effetti collaterali. Altrimenti, potrei creare un sito che abbia un iframe incorporato con contenuti come:

<form method=post action="www.yoursite.com/makepayment.php">
<input type=hidden name="to" value="123453323">
<input type=hidden name="amount" value="$10000">
</form>

e JS-attivano il modulo, inviando una richiesta POST che trasferisce denaro da te a me (o qualsiasi altra cosa).

Vuoi evitarlo, quindi controlla i referer lì .

Ancora meglio, usa un token CSRF (un token temporaneo collegato a un account specifico per un breve periodo di tempo) in un <input type=hidden> su ogni modulo della pagina con effetti collaterali (cioè, non si carica semplicemente una nuova pagina ma muta anche i dati memorizzati sul server o altrove)