Al giorno d'oggi i cookie possono avere flag HTTPOnly, Secure e SameSite. Gli scopi delle flag HTTPOnly e Secure sono abbastanza chiari. Ma cosa impedisce esattamente lo scripting di SameSite e in che modo?
Inoltre, come si presenterebbe uno scenario di "attacco" o "abuso" di successo quando il flag SameSite non viene utilizzato?
Gli obiettivi del SameSite flag sono:
La risposta effettiva dovrebbe essere, come sempre: dipende dallo scenario di utilizzo.
Il valore Strict impedirà l'invio del cookie da parte del browser
al sito di destinazione in tutto il contesto di navigazione tra siti, anche quando si segue un normale
collegamento. Ad esempio, per un sito Web simile a GitHub ciò significherebbe che se un utente connesso
segue un link a un progetto GitHub privato pubblicato su un forum di discussione aziendale
o email, GitHub non riceverà il cookie di sessione e l'utente non sarà in grado
per accedere al progetto. Un sito Web della banca, tuttavia, molto probabilmente non lo vuole
per consentire a qualsiasi pagina transazionale di essere collegata da siti esterni, quindi il flag Strict
sarebbe il più appropriato qui.
Il valore predefinito Lax fornisce un ragionevole equilibrio tra sicurezza
e usabilità per i siti Web che desiderano mantenere la sessione di accesso dell'utente dopo
l'utente arriva da un collegamento esterno. Nello scenario GitHub sopra, il cookie di sessione
sarebbe consentito quando si segua un collegamento regolare da un sito Web esterno durante il blocco
in metodi di richiesta incline a CSRF (ad esempio POST ).
Leggi altre domande sui tag http websites cookies web-application same-origin-policy