Vale la pena controllare il referrer?

Direi che l'utilizzo, la mancanza di referrer come unico indicatore di un attacco rischia di essere problematico in quanto non si può essere sicuri che tutti i client lo invieranno come previsto. In generale l'utilizzo del referrer come protezione contro CSRF non è considerato una buona idea in quanto può essere falsificato in alcune circostanze.

Se non ci fossero altre opzioni allora potrebbe valerne la pena, ma per CSRF esistono meccanismi di protezione meglio definiti (alcune informazioni. qui ) tale che nella maggior parte dei casi l'approccio migliore è usare i meccanismi di protezione incorporati nel framework, a meno che tu non abbia un motivo specifico per cui questi non funzionano nel tuo caso d'uso o sono inadeguati.

Usabilità

Sì, alcune persone non inviano referer. Ciò potrebbe essere dovuto a motivi di privacy o per motivi di sicurezza (gli URL non dovrebbero contenere dati sensibili come gli ID di sessione, ma ciò non significa che non lo facciano mai).

Sicurezza

Se il tuo sito web ha una vulnerabilità di reindirizzamento aperto, i controlli referer possono essere ignorati per le richieste GET. Ovviamente, le richieste GET non dovrebbero cambiare stato, ma ciò non significa che non lo facciano mai.

Conclusione

Per prevenire CSRF, userei un token anti-CSRF. Funziona, e non ha gli svantaggi del controllo dei referer.

Per i vantaggi generali e gli svantaggi di controllare il referente, consulta questa risposta e per informazioni generali sulla verifica della prevenzione CSRF questa guida OWASP .

Il referente può essere usato come indicazione che alcuni altri siti web collegano direttamente al tuo contenuto. Potresti voler attivare alcune restrizioni (o semplicemente registrarti) quando incontri un referente che punta a un sito web diverso dal tuo per scopi di larghezza di banda o copyright.

Tuttavia, non devi presumere che ogni browser ti invierà un'intestazione "referer". RFC 7231 afferma che " non tutte le richieste lo contengono ", mentre Wikipedia ha un bel paragrafo riguardante il nascondimento dei referenti a fini di privacy. La stessa sezione RFC si occupa anche di tali pratiche, incluso quando l'intestazione "referer" viene rimossa da un intermediario come nelle società citate:

Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the request target.

Ma come puoi vedere, non c'è alcun obbligo di mantenere il referrer: " NON DEVE " significa che possono ancora rimuoverlo e mantenere la conformità RFC.

Esistono diversi motivi non dannosi per cui un'intestazione Referer potrebbe essere vuota:

• l'accesso all'URL è stato effettuato da un segnalibro, dall'interno di una mail o l'URL è stato semplicemente digitato nel browser
• il supporto per Referer è stato disabilitato nel browser o Referer è stato rimosso da un firewall

A parte il fatto che il Referente potrebbe essere disabilitato da un attributo noreferrer nei link, utilizzando i tag meta refresh e altri metodi. Questi metodi potrebbero essere utilizzati da un utente malintenzionato ma potrebbero essere utilizzati anche per scopi non di attacco.

Questo significa che puoi considerare solo un'intestazione di Referer vuota come un segno di attacco se hai abbastanza controllo sul client che puoi assicurarti che acceda alla tua applicazione solo come tu hai inteso. Questo potrebbe essere il caso di una GUI Web per amministrare alcuni dispositivi locali, ma probabilmente non è possibile farlo con un'applicazione web disponibile a livello globale con molti client diversi e i loro middlebox (firewall, ecc.).

Ma puoi ancora prendere un Referente inaspettato non vuoto come segno di un possibile attacco e aggiungere un altro livello di protezione in questo modo, in aggiunta ai token CSRF.