Best practice relative alle norme sui referrer e sui referrer

Maud Nalpas

Questa pagina illustra alcune best practice per impostare le tue norme relative ai referrer e utilizzando il referrer nelle richieste in entrata.

Riepilogo

• La fuga di informazioni tra origini impreviste danneggia gli utenti web privacy. R il criterio relativo al referrer protettivo può essere d'aiuto.
• Valuta la possibilità di impostare un criterio relativo al referrer strict-origin-when-cross-origin. it preserva la maggior parte dell'utilità del referrer, riducendo al contempo il rischio di fughe di dati tra origini.
• Non utilizzare i referrer per la protezione della falsificazione delle richieste su più siti (CSRF). Utilizza le funzionalità di Token CSRF e altre intestazioni come ulteriore livello di sicurezza.

Guida introduttiva alle norme sui referrer e sui referrer

Le richieste HTTP possono includere un'intestazione Referer facoltativa, che indica l'origine o l'URL della pagina web da cui è stata effettuata la richiesta. La Intestazione Referrer-Policy definisce quali dati sono resi disponibili nell'intestazione Referer.

Nell'esempio seguente, l'intestazione Referer include l'URL completo della pagina su site-one da cui è stata effettuata la richiesta.

L'intestazione Referer potrebbe essere presente in diversi tipi di richieste:

• Richieste di navigazione, quando un utente fa clic su un link.
• Richieste di sottorisorse, quando un browser richiede immagini, iframe, script e le altre risorse necessarie a una pagina.

Per le navigazioni e gli iframe, puoi anche accedere a questi dati con JavaScript utilizzando document.referrer.

Puoi imparare molto dai valori di Referer. Ad esempio, un servizio di analisi potrebbe utilizzarli per determinare che il 50% dei visitatori di site-two.example ha raggiunto da social-network.example. Ma quando l'URL completo, inclusi il percorso e stringa di query, inviata Referer in tutte le origini, può mettere in pericolo l'utente la privacy e creare rischi per la sicurezza:

Gli URL da 1 a 5 contengono informazioni private e, a volte, sono sensibili o che consentono l'identificazione personale. Far trapelare in silenzio le varie origini può compromettere degli utenti web privacy.

L'URL 6 è un URL funzionalità. Se qualcuno a parte l'utente interessato, un utente malintenzionato può assumere il controllo dell'account di questo utente.

Per limitare quali dati del referrer vengono resi disponibili per le richieste del tuo sito: puoi impostare un criterio relativo al referrer.

Quali norme sono disponibili e in che cosa differiscono?

Puoi selezionare uno degli otto criteri disponibili. A seconda del criterio, i dati disponibili dall'intestazione Referer (e document.referrer) possono essere:

• Nessun dato (nessuna intestazione Referer presente)
• Solo il campo origin
• L'URL completo: origine, percorso e stringa di query

Alcune norme sono pensate per comportarsi in modo diverso a seconda del contesto: richiesta multiorigine o della stessa origine, indipendentemente dal fatto che la destinazione della richiesta sia come sicuro come origine, o entrambe. Ciò è utile per limitare la quantità di informazioni condiviso tra origini o con origini meno sicure, pur mantenendo la ricchezza del referrer all'interno del tuo sito.

La seguente tabella mostra in che modo i criteri relativi ai referrer limitano i dati URL disponibili dall'intestazione referer e document.referrer:

MDN fornisce un elenco completo di criteri e comportamenti esempi.

Ecco alcuni aspetti da tenere presente quando imposti un criterio per il referrer:

• Tutti i criteri che tengono conto dello schema (HTTPS rispetto a HTTP) (strict-origin, no-referrer-when-downgrade e strict-origin-when-cross-origin) tratta le richieste da un'origine HTTP a un'altra origine HTTP allo stesso modo delle richieste da un'origine HTTPS a un'altra HTTPS, anche se HTTP è meno sicuro. Questo perché per questi i criteri, ciò che conta è se viene eseguito il downgrade della sicurezza; che è che la richiesta può esporre i dati da un'origine criptata a un'origine uno, come in HTTPS → richieste HTTP. Una richiesta HTTP → HTTP è completamente non è criptato, quindi non c'è il downgrade.
• Se una richiesta è same-origin, significa che lo schema (HTTPS o HTTP) è allo stesso modo, quindi non c'è alcun downgrade per la sicurezza.

Criteri referrer predefiniti nei browser

Dati aggiornati a ottobre 2021

Se non viene configurato alcun criterio per il referrer, il browser utilizza il criterio predefinito.

Best practice per l'impostazione del criterio relativo al referrer

Esistono diversi modi per impostare i criteri per i referrer per il tuo sito:

• Come intestazione HTTP
• All'interno di HTML
• Da JavaScript su richiesta

Puoi impostare criteri diversi per pagine, richieste o elementi diversi.

L'intestazione HTTP e l'elemento meta sono entrambi a livello di pagina. L'ordine di priorità per determinare la norma effettiva di un elemento è il seguente:

1. Criterio a livello di elemento
2. Norme a livello di pagina
3. Predefinito del browser

Esempio:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

L'immagine viene richiesta con un criterio no-referrer-when-downgrade e tutti gli altri le richieste di sottorisorse di questa pagina seguono le strict-origin-when-cross-origin .

Come si visualizza il criterio relativo al referrer?

securityheaders.com è utile per determinare quali i criteri utilizzati da un sito o una pagina specifici.

Puoi anche utilizzare gli strumenti per sviluppatori in Chrome, Edge o Firefox per verificare il criterio referrer utilizzato per una richiesta specifica. Al momento della stesura di questo documento, Safari non mostra l'intestazione Referrer-Policy, ma mostra la Referer che è stata inviate.

Quale norma dovresti impostare per il tuo sito web?

Consigliamo vivamente di impostare esplicitamente norme relative al miglioramento della privacy come strict-origin-when-cross-origin (o meno restrittiva).

Perché "esplicitamente"?

Se non imposti un criterio relativo al referrer, verrà utilizzato il criterio predefinito del browser, infatti spesso i siti web rimandare all'impostazione predefinita del browser. Questo, però, non è l'ideale, perché:

• I criteri predefiniti variano a seconda del browser, quindi se utilizzi il browser valori predefiniti, il tuo sito non si comporterà in modo prevedibile su tutti i browser.
• I browser stanno adottando valori predefiniti più rigidi, come strict-origin-when-cross-origin e di meccanismi quali l'eliminazione dei referrer per le richieste multiorigine. Attivazione esplicita di norme relative al miglioramento della privacy prima della modifica delle impostazioni predefinite del browser ti offre il controllo e ti aiuta a eseguire test che ritieni in forma.

Perché strict-origin-when-cross-origin (o più restrittivo)?

È necessario che le norme siano sicure, utili e che migliorino la privacy. Cosa è "utile" dipende da ciò che desideri ottenere dal referrer:

• Sicuro: se il sito web utilizza HTTPS (in caso contrario, imposta un immediatamente), non vuoi che gli URL del tuo sito web penetrino per le richieste non HTTPS. Dal momento che chiunque sulla rete può vederle, le fughe di notizie potrebbero esporre i tuoi utenti ad attacchi person-in-the- middle. Le norme no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer e strict-origin risolvono il problema.
• Miglioramento della privacy: per una richiesta multiorigine, no-referrer-when-downgrade Condivide l'URL completo, il che può causare problemi di privacy. strict-origin-when-cross-origin e strict-origin condividono solo l'origine, e no-referrer non condivide nulla. Questo ti lascia con strict-origin-when-cross-origin, strict-origin e no-referrer come opzioni di miglioramento della privacy.
• Utile: no-referrer e strict-origin non condividono mai l'URL completo, nemmeno per le richieste della stessa origine. Se hai bisogno dell'URL completo, strict-origin-when-cross-origin è un'opzione migliore.

Tutto questo significa che strict-origin-when-cross-origin è generalmente un è la scelta più sensata.

Esempio: impostazione di un criterio strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Sul lato server, ad esempio in Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Cosa succede se strict-origin-when-cross-origin (o un valore più restrittivo) non soddisfa tutti i tuoi casi d'uso?

In questo caso, adotta un approccio progressivo, ovvero definisci norme protettive come strict-origin-when-cross-origin per il tuo sito web e, se necessario, un altro criteri permissivi per richieste o elementi HTML specifici.

Esempio: norme a livello di elemento

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit potrebbe limitare document.referrer o l'intestazione Referer per richieste cross-site. Visualizza i dettagli.

Esempio: criterio a livello di richiesta

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Cos'altro dovresti prendere in considerazione?

Le norme devono dipendere dal tuo sito web e dai casi d'uso, come stabilito da te, il tuo team e la tua azienda. Se alcuni URL contengono dati identificativi o sensibili, e impostare un criterio di protezione.

Best practice per le richieste in arrivo

Di seguito sono riportate alcune linee guida su cosa fare se il tuo sito utilizza l'URL del referrer richieste in arrivo.

Proteggere gli utenti dati

Referer può contenere dati privati, personali o identificativi, quindi assicurati lo consideri tale.

I referrer in entrata possono modificare {referer-can-change}

L'utilizzo del referrer dalle richieste multiorigine in arrivo presenta alcune limitazioni:

• Se non hai alcun controllo sull'implementazione dell'emittente della richiesta, non puoi fare ipotesi sull'intestazione Referer (e document.referrer) che ricevere. L'autore della richiesta potrebbe decidere di passare a un criterio no-referrer in qualsiasi momento o più in generale a norme più rigide rispetto a quelle che in precedenza. Ciò significa che riceverai meno dati da Referer rispetto a prima.
• I browser usano sempre di più le Norme sui referrer strict-origin-when-cross-origin per impostazione predefinita. Ciò significa che ora potresti ricevere solo l'origine, invece di un URL referrer completo nelle richieste multiorigine in arrivo, se il sito del mittente non è impostato alcun criterio.
• I browser potrebbero modificare la modalità di gestione di Referer. Ad esempio, alcuni browser gli sviluppatori potrebbero decidere di tagliare sempre i referrer in base alle origini in multiorigine richieste di sottorisorse, per proteggere la privacy degli utenti.
• L'intestazione Referer (e document.referrer) potrebbe contenere più dati di di cui hai bisogno. Ad esempio, potrebbe avere un URL completo quando vuoi sapere solo se la richiesta è multiorigine.

Alternative a Referer

Potresti dover prendere in considerazione delle alternative se:

• Una funzione essenziale del tuo sito utilizza l'URL del referrer richieste multiorigine.
• Il tuo sito non riceve più la parte dell'URL referrer di cui ha bisogno in un multiorigine. Questo accade quando l'autore della richiesta modifica o se non sono configurati criteri e il criterio del browser predefinito è stato modificato (come in Chrome 85).

Per definire le alternative, devi innanzitutto analizzare la parte del referrer che stai utilizzando.

Se hai bisogno solo dell'origine

• Se utilizzi il referrer in uno script con accesso di primo livello alla pagina, window.location.origin è un'alternativa.
• Se disponibili, intestazioni come Origin e Sec-Fetch-Site fornisce il valore Origin o descrivi se la richiesta è multiorigine, potrebbe essere esattamente ciò di cui hai bisogno.

Se hai bisogno di altri elementi dell'URL (percorso, parametri di ricerca e così via)

• I parametri di richiesta potrebbero essere adatti al tuo caso d'uso e, di conseguenza, risparmiare il lavoro di durante l'analisi del referrer.
• Se utilizzi il referrer in uno script con accesso di primo livello alla pagina, window.location.pathname potrebbe funzionare in alternativa. Estrai solo il percorso dell'URL e la trasmettiamo come argomento, in modo che qualsiasi le informazioni nei parametri URL non vengono trasmesse.

Se non puoi utilizzare queste alternative:

• Controlla se puoi modificare i tuoi sistemi in modo che l'emettitore della richiesta (ad es. site-one.example) per impostare esplicitamente le informazioni di cui hai bisogno in qualche tipo di configurazione.
  • Pro: più espliciti e più incentrati sulla tutela della privacy per gli utenti di site-one.example, a prova di futuro.
  • Svantaggio: potenzialmente più lavoro da parte tua o per gli utenti del tuo sistema.
• Controlla se il sito che invia le richieste potrebbe accettare di impostare un Norme sui referrer per elemento o per richiesta di no-referrer-when-downgrade.
  • Svantaggio: una tutela della privacy potenzialmente minore per site-one.example utenti, potenzialmente non supportati in tutti i browser.

Protezione della falsificazione delle richieste tra siti (CSRF)

Un mittente di richieste può sempre decidere di non inviare il referrer impostando un no-referrer e un utente malintenzionato potrebbe persino eseguire lo spoofing del referrer.

Utilizza i token CSRF come protezione principale. Per una maggiore protezione, usa SameSite e anziché Referer, utilizza intestazioni come Origin (disponibile per richieste POST e CORS) e Sec-Fetch-Site se disponibile.

Registra ed esegui il debug

Assicurati di proteggere le risorse degli utenti personali o sensibili che potrebbero trovarsi Referer.

Se utilizzi solo l'origine, controlla se puoi utilizzare Origin intestazione come un'alternativa. Potresti ricevere le informazioni necessarie per il debug in modo più semplice e senza dover analizzare il referrer.

Pagamenti

I fornitori di servizi di pagamento potrebbero utilizzare l'intestazione Referer delle richieste in arrivo per e controlli di sicurezza.

Ad esempio:

• L'utente fa clic su un pulsante Acquista su online-shop.example/cart/checkout.
• online-shop.example reindirizza a payment-provider.example per gestire transazione.
• payment-provider.example confronta il valore Referer di questa richiesta con un elenco di valori Referer consentiti impostati dai commercianti. Se non corrisponde a nessuna voce dell'elenco, payment-provider.example rifiuta la richiesta. In caso affermativo l'utente può procedere alla transazione.

Best practice per i controlli di sicurezza del flusso di pagamento

In qualità di fornitore di servizi di pagamento, puoi utilizzare il Referer come assegno di base per alcuni attacchi informatici. Tuttavia, l'intestazione Referer da sola non è una base affidabile per un controllo. Il sito richiedente, indipendentemente dal fatto che sia un commerciante legittimo o meno, può impostare un Criterio no-referrer che rende le informazioni Referer non disponibili per l'utente fornitore di servizi di pagamento.

Dare un'occhiata alla Referer potrebbe aiutare i fornitori di servizi di pagamento a individuare gli aggressori ingenui che non ha impostato un criterio no-referrer. Se utilizzi Referer come primo controllo:

• Non aspettarti che Referer sia sempre presente. Se è presente, controlla solo rispetto al numero minimo di dati che può includere, ovvero l'origine.
  • Quando imposti l'elenco di valori Referer consentiti, assicurati di includere solo l'origine e nessun percorso.
  • Ad esempio, i valori Referer consentiti per online-shop.example devono essere online-shop.example, non online-shop.example/cart/checkout. Prevedendo o nessun Referer o un valore Referer che sia solo il richiedente del sito, eviterai errori che potrebbero derivare da ipotesi informazioni sui Referrer-Policy del commerciante.
• Se Referer non è presente o se è presente e la tua origine Referer di base controllo è andato a buon fine, puoi passare a un'altra verifica più affidabile .

Per verificare in modo più affidabile i pagamenti, chiedi al richiedente esegui l'hashing dei parametri della richiesta insieme a una chiave univoca. I fornitori di servizi di pagamento possono quindi calcolare lo stesso hash sul tuo sito. e accetti la richiesta solo se corrisponde al tuo calcolo.

Che cosa succede a Referer quando un sito commerciante HTTP senza referrer reindirizza a un fornitore di servizi di pagamento HTTPS?

Nessun Referer visibile nella richiesta al fornitore di servizi di pagamento HTTPS perché la maggior parte dei browser usa strict-origin-when-cross-origin o no-referrer-when-downgrade per impostazione predefinita quando per un sito web non è configurato alcun criterio. Passaggio di Chrome a un nuovo criterio predefinito non modificherà questo comportamento.

Conclusione

Un criterio protettivo sui referrer è un ottimo modo per garantire agli utenti una maggiore privacy.

Per ulteriori informazioni sulle varie tecniche per proteggere i tuoi utenti, consulta le nostre Raccolta protetta e sicura

Risorse

• Informazioni sulla funzione "stesso sito" e "same-origin"
• Una nuova intestazione di sicurezza: Norme sui referrer (2017)
• Norme relative ai referrer attive MDN
• Intestazione del referral: Problemi di privacy e sicurezza attivi MDN
• Modifica di Chrome: intento di lampeggiare verso implementare
• Modifica di Chrome: intento di lampeggiare verso nave
• Modifica di Chrome: voce di stato
• Modifica di Chrome: 85 beta blogpost
• Tagliamento dei thread GitHub dei referrer: quali sono i diversi browser cosa fare
• Specifiche delle norme per i referrer

Grazie mille per i contributi e i feedback a tutti i recensori, in particolare Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.