I cookie sono aspetti fondamentali di un’applicazione Internet che spesso si occupano di utenti e sviluppatori. Un cookie è un piccolo dato che viene archiviato nel browser di un utente. L’elemento dati viene utilizzato come mezzo per comunicare le informazioni tra il browser Internet e il livello lato server dell’applicazione.
I cookie servono a vari scopi, come ricordare le credenziali di un utente (non consigliate), indirizzare gli annunci pubblicitari (monitoraggio dei cookie) o contribuire a mantenere lo stato di autenticazione di un utente in un’applicazione Internet. Numerosi articoli fantastici su Web sono stati scritti nel corso degli anni sui cookie.
Questo articolo si concentra sulla gestione dei biscotti a dominio incrociato, alias di terze parti.
Tipi di biscotti
Prima di saltare immediatamente nell’obiettivo principale di questo articolo, evidenziamo brevemente le categorie in cui possiamo rompere i biscotti. Una categoria si basa sul tipo di casi d’uso che risolvono e altre categorie si basano sulla proprietà dei cookie.
Composizione in base ai casi d’uso
Cookie di sessione
Come suggerisce il nome cookie di sessione è un tipo di cookie che viene utilizzato per gestire la sessione internet di un utente. In genere, il server invia il cookie come risposta al browser dopo l’autenticazione corretta come intestazione di risposta “set-cookie”. Il browser invia il cookie come parte della richiesta nella successiva chiamata al server. Il server convalida il cookie per assicurarsi che l’utente sia ancora autenticato prima di rispondere con i dati.
Se l’utente si disconnette o il tempo di sessione, il cookie è invalidato. Altrimenti, se l’utente chiude il browser, anche il cookie della sessione diventa inaccessibile.
// Setting a session cookie
doc.cookie = "session_cookie=worth; path=/";
Cookie persistente
UN Cookie persistente è un tipo di cookie che non muore quando il browser è chiuso o se l’utente si firma da un’applicazione Internet. Il suo scopo è di conservare alcune informazioni nella workstation dell’utente per un periodo di tempo più lungo.
Un esempio comune di un caso d’uso in cui viene utilizzato il cookie persistente è durante l’autenticazione a due fattori su un sito Internet. Abbiamo incontrato tutti questa esperienza sui siti Internet, soprattutto quando si accede ai portali banking on-line. Dopo aver inserito il nostro ID utente e la nostra password, ci viene spesso richiesto un secondo livello di autenticazione.
Questo secondo fattore è in genere un passcode una tantum (OTP), che viene inviato al nostro dispositivo cellular tramite SMS o chiamata vocale o al nostro indirizzo e-mail (sebbene l’utilizzo dell’e-mail sia generalmente scoraggiato, poiché gli account di posta elettronica sono più inclini a compromessi). In generale, la schermata di autenticazione del 2 ° fattore ci offre la possibilità di ricordare il dispositivo. Se lo scegliamo come opzione, in genere l’applicazione genera un codice casuale e persiste sul lato server.
L’applicazione imposta quel codice casuale come cookie persistente e lo invia al browser. Durante l’accesso successivo, il codice lato consumer dell’applicazione invia il cookie persistente nella richiesta dopo un’autenticazione corretta. Il lato server del codice trova valido il cookie persistente, quindi non richiede l’utente per l’autenticazione del 2 ° fattore. Altrimenti, l’utente è sfidato per il codice OTP.
// Setting a persistent cookie for 30 days
var expirationDate = new Date();
expirationDate.setDate(expirationDate.getDate() + 30);
doc.cookie = "persistent_cookie=worth; expires=" + expirationDate.toUTCString() + "; path=/";
Cookie di tracciamento
A differenza dei cookie di sessione o persistenti, che sono stati molto comuni sin dall’inizio delle soluzioni a base di cookie nelle applicazioni Internet, il monitoraggio dei cookie è relativamente nuovo e principalmente un fenomeno degli ultimi dieci anni. Qui, un sito Internet inizia a monitorare l’attività di navigazione degli utenti e la memorizza nel browser. Successivamente, viene utilizzato per visualizzare annunci pertinenti agli utenti quando accedono a Web dallo stesso browser.
Poiché un cookie di monitoraggio viene utilizzato per acquisire i dati degli utenti, i siti Internet spingono gli utenti advert accettare o rifiutare il monitoraggio dei cookie quando accedono a un sito Internet che implementa i cookie di tracciamento.
// Setting a monitoring cookie with SameSite=None and Safe possibility for cross website entry
var expirationDate = new Date();
expirationDate.setDate(expirationDate.getDate() + 365); // Expires after 1 yr
doc.cookie = "tracking_cookie=worth; expires=" + expirationDate.toUTCString() + "; path=/; SameSite=None; Safe";
Composizione in base alla proprietà
Biscotto di prima parte
Immagina di aprire l’URLwww.abc.comIn una scheda browser. Il sito Internet utilizza i cookie e un cookie è impostato nel browser. Come URL nel browser, www.abc.com, corrisponde al dominio del cookie, è un biscotto di prima parte. In altre parole, un cookie rilasciato nel browser per l’indirizzo del sito Internet presente nella barra degli indirizzi del browser è una prima parte biscotto.
Biscotto di terze parti
Ora, immagina che ci sia una pagina internet all’internowww.abc.com che carica i contenuti da un sito Internet diverso, www.xyz.com. In genere, questo viene fatto usando un tag iforame html. Il biscotto emesso da www.xyz.com è chiamato biscotto di terze parti. Come il dominio del cookie perwww.xyz.comNon corrisponde all’URL presente nella barra degli indirizzi del browser (www.abc.com), il cookie è considerato di terze parti.
Risoluzione del problema dell’accesso ai cookie di terze parti
Per motivi di privateness, Safari su Mac, iOS e Chrome in Incognito in modalità Blocca i cookie di terze parti. Anche se il cookie di terze parti è impostato utilizzando il SameSite=None; Safe
Attributo, Safari e Chrome Incognito lo bloccheranno.
Pertanto, l’esempio di incorporamento del contenuto basato su Iframe spiegato sopra non funzionerà nel browser, il che mette le restrizioni su di esso. Per risolvere il problema, Alcuni lavori di networking devono essere svolti.
- Un file di alias, come xyz-thirdparty.abc.comdeve essere creato.
- Il file di aliasxyz-thirdparty.abc.comdeve averewww.xyz.comcome endpoint goal nella configurazione della rete.
- È necessario generare un certificato con CN e nome alternativo in materia come xyz-thirdparty.abc.com da un’autorità di certificazione (advert es. VeriSign). Il certificato deve essere installato nell’infrastruttura (advert esempio, proxy inverso, server Internet, bilanciamento del carico, ecc.)www.xyz.com.
- Il codice iFrame dovrebbe utilizzare l’URL di destinazione come xyz-thirdparty.abc.com invece di www.xyz.com.
- In questo modo il biscotto emesso dawww.xyz.comverrà effettivamente emesso ai sensi del file di alias xyz-thirdpary.abc.com. Poiché il dominio del cookie è ABC.com che corrisponde al dominio dell’URL presente nella barra degli indirizzi del browser (www.abc.com), il cookie sarà trattato come prima parte. L’applicazione che utilizza IFrame funzionerà in modalità Safari e Chrome Incognito.
Nota: Il sottodominio per il file di alias potrebbe essere qualcosa di simile a foo.abc.com. Ho usato il sottodominio dell’alias come Xyz-Thirdparty solo a scopo dimostrativo.
Il diagramma seguente dimostra la soluzione di networking.
Configurazione di rete per IFRAME incrociato
Considerazione
IL www.xyz.comIl sito Internet deve utilizzare le intestazioni delle opzioni X nella sua infrastruttura (advert esempio, proxy inverso) e whitelistwww.abc.comcome il sito Internet che può Iframe. Altrimenti, anche con la soluzione di file di alias,www.abc.comnon sarà in grado di iframewww.xyz.com.
Come nota a margine, l’intestazione delle opzioni X-Body viene utilizzata per controllare se un sito Internet può essere IFRAME-D o meno e se sì, quali siti Internet specifici possono infilarlo. Questo viene fatto per proteggere un sito Internet da un attacco di clickjacking.
Conclusione
Proteggere gli utenti finali e i siti Internet da attacchi dannosi è fondamentale nel internet moderno. I browser stanno diventando restrittivi con i controlli aggiuntivi. Tuttavia, ci sono casi d’uso legittimi quando le comunicazioni a dominio a dominio devono avvenire in un browser, come l’incorporamento di un sito Internet all’interno di un altro in IFRAME.
I cookie di terze parti diventano una sfida da implementare nelle implementazioni basate su Iframe. Questo articolo ha dimostrato la tecnica su come implementare questa funzione utilizzando la configurazione della rete.