Mi piace quando mangi il tuo stesso cibo per cani!!!.
I browser moderni, senza citare quelli specifici (come Chrome), sono sempre più esigenti nelle impostazioni di sicurezza dei cookie.
Un esempio è l’impostazione del cookie SameSite. Ad esempio, se non è presente in Chrome, utilizzerà il suo metodo predefinito, SameSite=Lax.
Ma cosa succede se non vuoi questo? La risposta è modificare il codice della tua applicazione per riflettere l’impostazione che vuoi utilizzare. Ma cosa succede se non puoi farlo facilmente? Potrebbe trattarsi di un’applicazione legacy.
La risposta è utilizzare le funzioni di commutazione dei contenuti di EdgeADC flightPATH.
Il famigerato problema di WordPress WooCommerce che gira in un Iframe
Abbiamo avuto un problema con un’applicazione WordPress che utilizziamo e che gira in un Iframe. (Non chiedere il perché).
L’applicazione utilizzava cookie di sessione per i quali non era stata impostata l’opzione SameSite.
L’applicazione viene eseguita all’interno di un sistema WordPress predefinito fornito all’interno di un container Docker.
Abbiamo studiato alcuni modi per risolvere questo problema, ma le nostre modifiche non funzionavano correttamente su tutti i cookie, quindi abbiamo deciso di provare a risolvere il problema utilizzando flightPATH.
Ecco cosa abbiamo fatto.
Abbiamo creato una regola flightPATH per aggiungere SameSite=none ai tre cookie incriminati, come mostrato di seguito.
La prima regola flightPATH che creeremo è:
Successivamente, creeremo il secondo.
Infine, creiamo l’ultimo. Questa ha una definizione leggermente diversa, come puoi vedere. Abbiamo aggiunto un carattere jolly (*) perché non sappiamo quale sia il valore, dato che WordPress / WooCommerce assegna un valore casuale.
A questo punto, ti starai dicendo: “Ehi! Non è sicuro quando si usa un carattere jolly!”. Ci rendiamo conto che il sito è leggermente meno sicuro, ma..:
- Il tutto funziona con HTTPS
- Eseguiamo un firewall per le applicazioni
- È protetto dal fatto che è un sistema operativo containerizzato e i file chiave sono immutabili.
E nel caso in cui avessi bisogno di un aggiornamento su SameSite…
Qual è l’impostazione di SameSite per i cookie?
L’impostazione SameSite Cookie aiuta a controllare quando i cookie vengono inviati con le richieste cross-site, riducendo così il rischio di attacchi CSRF (Cross-site request forgery). Ecco come funziona:
Cosa sono le richieste cross-site?
Le richieste cross-site sono richieste effettuate da un sito web a un altro. Ad esempio, se sei connesso a un’applicazione e clicchi su un link a un articolo di cronaca, si tratta di una richiesta cross-site. In poche parole, una richiesta che collega un sito a un altro sito.
Che cos’è l’impostazione SameSite?
L’impostazione SameSite è un attributo dei cookie che può essere utilizzato per controllare se un cookie viene inviato o meno con le richieste cross-site. Ci sono tre valori possibili per l’impostazione SameSite:
- SameSite=Strict: I cookie vengono inviati solo con richieste allo stesso sito che li ha impostati.
- SameSite=Lax: I cookie vengono inviati con le richieste allo stesso sito che li ha impostati, così come con le richieste a siti di terze parti che sono incorporati nella stessa pagina, ad esempio all’interno di un iFrame.
- SameSite=Nessuno: I cookie vengono inviati con tutte le richieste, indipendentemente dal sito che li ha impostati.
Perché l’impostazione SameSite è importante?
L’impostazione SameSite è importante perché aiuta a mitigare il rischio di attacchi Cross-Site Request Forgery (CSRF). Gli attacchi CSRF sono un tipo di attacco informatico che sfrutta il fatto che il browser di un utente sia già connesso a un sito web. In un attacco CSRF, un aggressore può indurre un utente a fare una richiesta a un sito web a cui ha effettuato l’accesso, anche se l’utente non intende farlo. Questo può permettere all’aggressore di rubare i dati dell’utente o di eseguire altre azioni dannose.
