Sul lato client, una richiesta HTTP inviata dalla pagina web A che bersaglia il sito B causerà l'invio di tutti i cookie appartenenti al sito Web B (anche se A non appartiene a B).
Non capisco perché il comportamento dei cookie sia stato progettato in questo modo. Non è ovviamente assicurato e il motivo alla base di CSRF (cross-site request forgery)?
So che oggigiorno "lo stesso cookie del sito" è in arrivo. Ma voglio sapere qual è stata la motivazione del vecchio design insicuro.
Secondo Wikipedia , il concetto di cookie viene da Lou Montulli nel giugno 1994. Il protocollo HTTP era ancora molto giovane.
Poiché il HTTP non ha alcune funzionalità di sicurezza fondamentali, come la crittografia, suppongo che la sicurezza non sia la loro priorità. Dubito anche che qualcuno delle persone che lavorava in quel momento avrebbe potuto prevedere che HTTP sarebbe stato usato così selvaggiamente al giorno d'oggi, anche da attori malvagi.
È molto più semplice guardare indietro a tutte le vulnerabilità / difetti delle specifiche che abbiamo trovato negli ultimi 20 anni, che per anticiparli tutti in primo luogo.
Come hai detto, l'attributo del cookie SameSite è sulla buona strada per risolvere questo difetto . Fino al supporto da parte dei browser, gli sviluppatori devono utilizzare le tecniche di attenuazione CSRF standard .
Se ho capito bene, si tratta del 3 °. biscotti di festa. Questo approccio è particolarmente adatto per siti pubblicitari, ad esempio (non solo per loro)
Come una pagina del dominio A ha un dato del dominio B, la risorsa (diciamo un'immagine) risponde con un cookie (B set cookie per questo).
Ora quando vai al dominio C che ha un'altra risorsa dal dominio B, qui il dominio B può identificare che hai visitato anche il dominio A.
Alcuni browser supportano la disattivazione di 3rd. cookie di partito, ma non abilitati di default (non sono sicuro)
Ogni volta che viene effettuata una richiesta per un dominio X, tutti i cookie verranno inviati con la richiesta, naturalmente, dal browser.