Security Header da F ad A: Referrer Policy

In questo terzo articolo dedicato ai security header vedremo il response header: Referrer Policy. Come sempre implementeremo l'header su questo sito (blog.rev3rse.it) e verificheremo il punteggio su securityheaders.com. Se non sai di cosa sto parlando, ti consiglio di leggere il primo capitolo.

Referrer Policy è una "nuova" feature che permette a un sito, o un'applicazione web, di controllare ciò che il browser dell'utente inserisce all'interno dell'header referer. Infatti ogni volta che clicchiamo su un link che porta il nostro browser verso una nuova pagina, esso valorizza il request header referer con l'URL di provenienza e lo invia al sito di destinazione (non sempre, come vedremo dopo).

Ad esempio, se un utente cliccasse sul link rev3rse.it pubblicato su di un tweet su Twitter, il browser potrebbe valorizzare il campo referer in questo modo:

Curiosità: ma perchè Referer con una "r" sola?

Coloro i quali non conoscessero questa storia, rimarranno sicuramente colpiti nel sapere che l'errore nel nome dell'header "Referer" è rimasto nella RFC per un po' di tempo prima che qualcuno se ne accorgesse...

Phillip Hallam-Baker (ora vice presidente di Comodo e all'epoca parte del IETF, contribuì alla stesura del HTTP nel 1992 al CERN), all'inizio degli anni 90 insieme a Roy Fielding propose di inserire l'header Referrer in quella che sarà poi la HTTP RFC 1945. Peccato che nessuno dei due autori si accorse che Referer era scritto con una sola "r".

Fortunatamente negli archivi della mailing list di IETF possiamo trovare la mail originale di uno dei contributors, John Franks, che scrive:

"Scusate ma, qualcuno si è accorto che Referer è scritto male?"  – John

:D la risposta di Roy, co-autore della proposta, mi ha spiazzato:

"Oh, è tutto ok! spell comunque non riconosce né Referer e né Referrer...

(spell è/era un comando per il controllo ortografico in Unix)

Io dico di dare la colpa alla Francia ;-)"  – Roy

e per la cronaca si riferiva alla parola francese "référer".

Morale della favola, se vi steste chiedendo se l'errore sia stato corretto, la risposta è: assolutamente no. Lo usiamo con una R sola da anni, e siamo contenti così. In questi casi ho una risposta standard che fa anche da parafrasi alla risposta di Phillip: "solo chi non fa un cazzo non fa mai errori, non è vero?" ;)

Perchè controllare il Referrer?

Come abbiamo visto, il browser dell'utente valorizza l'header referer praticamente ogni volta che clicca su un link. Questo comportamento genera due problematiche principali: la prima riguardante la privacy e la seconda la sicurezza dell'utente.

Privacy: pensiamo a un utente che utilizza un social network. In questo social l'utente prende parte a gruppi privati in cui pubblica spesso articoli che possono rivelare le sue preferenze politiche. Il social network dovrebbe evitare che l’URL del profilo dell’utente, o del gruppo, venga inviato al sito destinatario nell'header referer perchè l’URL del profilo dell'utente potrebbe rivelare l’identità del proprietario.

Sicurezza: pensiamo a un sito o un'applicazione web che inserisce l'id di sessione dell'utente autenticato all'interno del URL. Per sempio: /home?sessionid=deadbeef. Ovviamente non vogliamo che questo id venga inviato dal browser a terze parti. Referrer Policy può aiutarci a evitare che questo accada.

La sintassi è molto semplice:

Referrer-Policy: <policy>

Abbiamo a disposizione 8 tipi di policy:

• no-referrer
• no-referrer-when-downgrade
• same-origin
• origin
• strict-origin
• origin-when-cross-origin
• strict-origin-when-cross-origin
• unsafe-url

In realtà i moderni browser dovrebbero già utilizzare no-referrer-when-downgrade come policy di default, ovvero: Nessun header referer se si verifica una condizione di downgrade di schema (da https a http). Lo vedremo nel dettaglio tra poco.

no-referrer

Non invia mai l'header referer.

no-referrer-when-downgrade

Non invia l’header referer in una situazione di downgrade di schema. Questo significa che quando il browser viene indirizzato da un sito in HTTPS verso una destinazione HTTP, non viene inviato alcun referrer. L’URL completo viene comunque inviato dal browser se non si verifica un downgrade, quindi passando da schema HTTP verso qualsiasi destinazione.

same-origin

Il browser invia l’header referer solo nei confronti di request HTTP con stesso origin. Attenzione: per "stesso origin" si intende stesso schema, stesso hostname e stessa porta, esempio https://example.com:8081/foo

origin

Il browser invia l’header referer ma lo valorizza solo con l’origin (quindi: schema, hostname e porta) togliendo informazioni sul path, pagine e querystring dal valore dell’header. Attenzione, questa policy valorizza il Referrer anche in caso di downgrade di schema!

strict-origin

Questa policy è identica alla precedente (origin) ma non invia l’header referer se si verifica un downgrade di schema. Quindi verso destinazioni con schema HTTP se proveniente da HTTPS.

origin-when-cross-origin

Il browser invia l’URL completo (quindi con path, file, ecc...) solo verso destinazioni con stesso origin. Per tutte le altre destinazioni (cross origin) invia solo schema, hostname e porta. Attenzione: in caso di downgrade di schema l'origin viene comunque inviato.

strict-origin-when-cross-origin

Credo che questa policy possa essere la candidata ideale per il blog rev3rse, perché è simile alla precedente ma non invia alcun Referrer in caso di downgrade di schema.

unsafe-url

Credo che sia abbastanza chiaro il velato suggerimento incluso nel nome di questa policy. In questo caso il browser invia Referrer sempre e comunque. Il consiglio è quello di non usare mai, per quanto possibile, questa policy.

Implementiamo Referrer-Policy

È arrivato il momento di tentare di aumentare la nostra inssuficienza su securityheaders.com implementando Referrer-Policy sy blog.rev3rse.it. Il nostro attuale voto è "D".

Credo che semplicemente mi limiterò a inserire quanto segue sul file di configurazione di Nginx:

Purtroppo questa configurazione non ha spostato di molto il nostro punteggio che rimane "D", dovremo aspettare le prossime puntate!

Video

Link utili

https://en.wikipedia.org/wiki/HTTP_referer
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy