Protezione CSRF su pagine statiche

Posso fare qualsiasi richiesta al tuo server, con qualsiasi intestazione e valore che voglio. Quindi un attaccante può facilmente inviarti un pacchetto con un referente scelto da lui. Ma come ti sei comportato in un attacco CSRF?

CSRF funziona da me mandandoti a una pagina web che controllo, e poi quella pagina reindirizza il tuo browser alla pagina web per eseguire il CSRF. Ad esempio, potrei inviarti (tramite quella pagina di attacco) a https://example.com/usermgmt.php?action=delete&user=1 , che potrebbe farti inavvertitamente cancellare userid 1.

Quello che fa il tuo browser è impostare l'intestazione REFERER (durante il caricamento di usermgmt.php) da qualsiasi parte provenga, ad esempio http://malicious.tld . Se usermgmt.php ha controllato il referente, si sarebbe accorto che non proveniva dallo stesso dominio. Quindi non puoi (di default) spoofare i referenti per CSRF.

Una cattura qui sono cose come le pagine di accesso. Considera questo: https://example.com/login.php?returnTo=index.php . Un attacco CSRF funziona solo quando la vittima ha già effettuato l'accesso, altrimenti l'autore dell'attacco può caricare l'URL stesso. E se sei loggato, probabilmente la pagina di accesso ti reindirizza direttamente all'URL di ritorno. Ora cosa succede se scrivi usermgmt.php?action=delete&userid=1 come URL di ritorno? Reindirizzerà da login.php a usermgmt.php e il referer ricevuto da usermgmt.php sarà https://example.com/login.php?returnto=x . Sembra del tutto legittimo, ma non lo è.

Inoltre, alcuni browser potrebbero non includere un referrer per motivi di privacy, il che interromperebbe il sito web. Non conosco alcun browser che abbia questa opzione ("funzionalità"?) Senza installare un componente aggiuntivo speciale, ma non si sa mai.

Quindi la soluzione migliore è usare i token CSRF, e certamente lo farei se stai per ospitare qualcosa per un pubblico più vasto, ma se è per un gruppo di utenti chiuso probabilmente stai controllando il referrer.

Personalmente, non è consigliabile utilizzare l'intestazione Referer per interrompere gli attacchi CSRF. Ha due problemi:

• In primo luogo, è fragile. C'è una lunga storia di attacchi sull'intestazione di Referer, che coinvolgono (in vari modi) exploit sui plugin (ad esempio, Flash), bug nelle API del browser (ad es. XHR) e reindirizzamento. Per essere chiari, non sto dicendo che il controllo del Referente sarà necessariamente insicuro; Sto solo sostenendo che penso che sia più fragile, e avrei più fiducia in una soluzione che utilizza i token CSRF.

• In secondo luogo, alcuni browser e firewall aziendali bloccano l'intestazione del Referer per motivi di privacy, il che significa che sarete costretti a bloccare utenti legittimi. Quindi l'intestazione Referer non è semplicemente una buona soluzione.

Invece di usare l'intestazione Referer, ti consiglio di utilizzare i token CSRF.

È in effetti l'endpoint delle tue rotaie che deve proteggersi. È necessario distinguere tra le pagine statiche e la pagina dannosa di qualcun altro su Internet.

Sono d'accordo sul fatto che avere l'endpoint delle rotaie controlla che il referrer sia un modo fragile per autorizzare l'accesso.

Una possibilità è che l'endpoint delle rotaie abbia una route non protetta da CSRF e non fa nulla, ma consente di impostare il cookie CSRF. Una "forma nulla". Tutti i siti statici sul tuo dominio possono colpirlo prima di effettuare altre chiamate AJAX.

Presumibilmente, se stai usando AJAX, ti trovi nello stesso dominio, il che significa che puoi vedere il cookie. Se quell'endpoint venisse colpito da un altro sito, non otterrebbero il cookie perché si trovano su un dominio diverso.