Stesso sito schematico

La definizione di "same-site" si sta evolvendo per includere lo schema URL, quindi i link tra le versioni HTTP e HTTPS di un sito ora vengono conteggiati come richieste cross-site. Esegui l'upgrade a HTTPS per impostazione predefinita per evitare problemi, ove possibile, oppure continua a leggere per conoscere i dettagli sui valori degli attributi SameSite necessari.

Steven Bingler
Steven Bingler
GitHub
Rowan merewood

Schemeful Same-Site modifica la definizione di un sito (web) solo dal dominio registrabile allo schema + dominio registrabile. Puoi trovare ulteriori dettagli ed esempi in Informazioni su "stesso sito" e "stesso-origine".

La buona notizia è che se il tuo sito web è già stato completamente aggiornato a HTTPS, non devi preoccuparti di nulla. Non cambierà nulla per te.

Se non hai ancora eseguito l'upgrade completo del tuo sito web, questa dovrebbe essere la tua priorità. Tuttavia, se i visitatori del tuo sito passano da HTTP a HTTPS, vengono descritti di seguito alcuni di questi scenari comuni e il comportamento dei cookie SameSite associato.

Puoi attivare queste modifiche per i test sia in Chrome sia in Firefox.

  • A partire da Chrome 86, attiva about://flags/#schemeful-same-site. Monitora l'avanzamento sulla pagina Stato di Chrome.
  • In Firefox 79, imposta network.cookie.sameSite.schemeful su true tramite about:config. Monitora l'avanzamento tramite il problema di Bugzilla.

Uno dei motivi principali della modifica a SameSite=Lax come predefinita per i cookie è la protezione contro la falsificazione di richieste su più siti (CSRF). Tuttavia, il traffico HTTP non sicuro presenta ancora l'opportunità agli utenti malintenzionati di rete di modificare i cookie che verranno utilizzati nella versione HTTPS sicura del sito. La creazione di questo ulteriore confine tra siti tra gli schemi fornisce ulteriore difesa da questi attacchi.

Scenari comuni tra schemi

Se navighi tra versioni cross-scheme di un sito web (ad esempio, un link da http://site.example a https://site.example) consentirebbe in precedenza l'invio dei cookie SameSite=Strict. Ora viene considerata una navigazione tra siti, il che significa che i cookie SameSite=Strict verranno bloccati.

Una navigazione tra schemi che viene attivata seguendo un link presente nella versione HTTP non sicura di un sito alla versione HTTPS protetta. SameSite=Cookie rigorosi bloccati, SameSite=Lax e SameSite=None; cookie sicuri consentiti.
Navigazione tra schemi da HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloccato ⛔ Bloccato
SameSite=Lax ✓ Consentito ✓ Consentito
SameSite=None;Secure ✓ Consentito ⛔ Bloccato

Caricamento delle risorse secondarie in corso...

Eventuali modifiche apportate qui devono essere considerate correzioni temporanee solo se esegui l'upgrade all'estensione HTTPS completa.

Esempi di risorse secondarie includono immagini, iframe e richieste di rete effettuate con XHR o Fetch.

Il caricamento di una sottorisorsa tra schemi su una pagina consentiva in precedenza l'invio o l'impostazione di cookie SameSite=Strict o SameSite=Lax. Ora, questo viene trattato come qualsiasi altra sottorisorsa di terze parti o tra siti, il che significa che qualsiasi cookie SameSite=Strict o SameSite=Lax verrà bloccato.

Inoltre, anche se il browser consente il caricamento di risorse di schemi non sicuri su una pagina sicura, tutti i cookie verranno bloccati in queste richieste poiché i cookie di terze parti o tra siti richiedono Secure.

Una sottorisorsa tra schemi derivante da una risorsa della versione HTTPS sicura del sito inclusa nella versione HTTP non sicura. SameSite=Strict e SameSite=Lax cookie bloccati e SameSite=None; I cookie sicuri sono consentiti.
Una pagina HTTP che include una sottorisorsa tra schemi tramite HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloccato ⛔ Bloccato
SameSite=Lax ⛔ Bloccato ⛔ Bloccato
SameSite=None;Secure ✓ Consentito ⛔ Bloccato

PUBBLICARE un modulo

La pubblicazione tra versioni di un sito web su più schemi in precedenza consentiva l'invio dei cookie impostati con SameSite=Lax o SameSite=Strict. Ora questo viene trattato come un POST tra siti. È possibile inviare solo SameSite=None cookie. Questo scenario potrebbe verificarsi sui siti che presentano la versione non sicura per impostazione predefinita, ma esegui l'upgrade degli utenti alla versione protetta all'invio del modulo di accesso o check-out.

Come per le risorse secondarie, se la richiesta passa da un contesto sicuro, ad esempio HTTPS, a uno non sicuro, ad esempio HTTP, contesto, tutti i cookie verranno bloccati in queste richieste poiché i cookie di terze parti o tra siti richiedono Secure.

L'invio di un modulo tra schemi derivante da un modulo presente nella versione HTTP non sicura del sito inviato alla versione HTTPS protetta. SameSite=Strict e SameSite=Lax cookie bloccati e SameSite=None; I cookie sicuri sono consentiti.
Invio di moduli tra schemi da HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloccato ⛔ Bloccato
SameSite=Lax ⛔ Bloccato ⛔ Bloccato
SameSite=None;Secure ✓ Consentito ⛔ Bloccato

Come posso testare il mio sito?

Gli strumenti e i messaggi per sviluppatori sono disponibili in Chrome e Firefox.

A partire da Chrome 86, la scheda Problema in DevTools include i problemi relativi allo stesso sito di Schemeful. Per il tuo sito potrebbero essere evidenziati i seguenti problemi.

Problemi relativi alla navigazione:

  • "Esegui la migrazione completa a HTTPS per continuare a ricevere i cookie nelle richieste dello stesso sito": un avviso che indica che il cookie verrà bloccato in una versione futura di Chrome.
  • "Esegui la migrazione completa a HTTPS per ricevere i cookie nelle richieste dello stesso sito": un avviso che indica che il cookie è stato bloccato.

Problemi di caricamento delle sottorisorse:

  • "Esegui la migrazione completa a HTTPS per continuare a ricevere i cookie nelle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per continuare a consentire l'impostazione dei cookie dalle sottorisorse dello stesso sito": avvisi che indicano che il cookie verrà bloccato in una versione futura di Chrome.
  • "Esegui la migrazione completa a HTTPS per fare in modo che i cookie vengano inviati alle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per consentire l'impostazione dei cookie dalle sottorisorse dello stesso sito": avvisi che indicano che il cookie è stato bloccato. Il secondo avviso può essere visualizzato anche quando si PUBBLICA un modulo.

Ulteriori dettagli sono disponibili in Suggerimenti di test e debug per Schemeful Same-Site.

In Firefox 79, con network.cookie.sameSite.schemeful impostato su true tramite about:config, nella console verrà visualizzato il messaggio relativo ai problemi relativi a Schemeful Same-Site. Sul tuo sito potresti visualizzare:

  • "Il cookie cookie_name verrà presto trattato come cookie cross-site rispetto a http://site.example/ perché lo schema non corrisponde."
  • "Il cookie cookie_name è stato trattato come cross-site rispetto a http://site.example/ perché lo schema non corrisponde."

Domande frequenti

Il mio sito è già completamente disponibile su HTTPS. Perché vedo problemi nei DevTools del mio browser?

È possibile che alcuni link e sottorisorse rimandino ancora a URL non sicuri.

Un modo per risolvere il problema è utilizzare HTTP Strict-Transport-Security (HSTS) e l'istruzione includeSubDomain. Con HSTS + includeSubDomain, anche se una delle tue pagine include accidentalmente un link non sicuro, il browser utilizzerà automaticamente la versione protetta.

Che cosa succede se non posso eseguire l'upgrade a HTTPS?

Sebbene consigliamo vivamente di eseguire completamente l'upgrade del sito a HTTPS per proteggere gli utenti, se non sei in grado di farlo autonomamente, ti consigliamo di rivolgerti al tuo provider host per verificare se può offrire questa opzione. Se esegui l'hosting autonomo, Let's Encrypt fornisce una serie di strumenti per installare e configurare un certificato. Puoi anche valutare lo spostamento del sito dietro una rete CDN o un altro proxy in grado di fornire la connessione HTTPS.

Se ciò non fosse ancora possibile, prova a ridurre la protezione SameSite sui cookie interessati.

  • Nei casi in cui vengono bloccati solo SameSite=Strict cookie, puoi ridurre la protezione a Lax.
  • Nei casi in cui entrambi i cookie Strict e Lax vengono bloccati e i cookie vengono inviati a (o impostati da) un URL sicuro, puoi ridurre le protezioni a None.
    • Questa soluzione alternativa non andrà a buon fine se l'URL a cui stai inviando i cookie (o da cui vengono impostati) non è sicuro. Questo perché SameSite=None richiede l'attributo Secure per i cookie, il che significa che questi cookie non possono essere inviati o impostati su una connessione non sicura. In questo caso, non potrai accedere al cookie finché non avrai eseguito l'upgrade del sito a HTTPS.
    • Ricorda che si tratta di una situazione solo temporanea, in quanto i cookie di terze parti verranno ritirati completamente.

In che modo questo influisce sui miei cookie se non ho specificato un attributo SameSite?

I cookie senza un attributo SameSite vengono trattati come se fossero specificati SameSite=Lax e lo stesso comportamento tra schemi viene applicato anche a questi cookie. Tieni presente che l'eccezione temporanea ai metodi non sicuri continua a essere valida. Per ulteriori informazioni, consulta la mitigazione di Lax + POST nelle SameSiteDomande frequenti di Chromium.

In che modo sono interessati i WebSocket?

Le connessioni WebSocket saranno comunque considerate "stesso sito" se offrono la stessa sicurezza della pagina.

Stesso sito:

  • wss:// connessione da https://
  • ws:// connessione da http://

Tra siti:

  • wss:// connessione da http://
  • ws:// connessione da https://

Foto di Julissa Capdevilla su Unsplash