Stesso sito schematico

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

Steven Bingler

Rowan Merewood

Ecologico Sullo stesso sito modifica la definizione di un sito (web) passando dal semplice dominio registrabile alla schema + dominio registrabile. Puoi trovare ulteriori dettagli ed esempi in Informazioni sulla funzione "stesso sito" e "same-origin".

La buona notizia è che se hai già eseguito l'upgrade completo del tuo sito web a HTTPS, non devi preoccuparti di niente. Non cambierà nulla per te.

Se non hai ancora eseguito l'upgrade completo del tuo sito web, questa dovrebbe essere la priorità. Tuttavia, se ci sono casi in cui i visitatori del tuo sito passano tra HTTP e HTTPS e alcuni di questi scenari comuni e il cookie SameSite associato. sono descritti di seguito.

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

• Da Chrome 86, attiva about://flags/#schemeful-same-site. Monitora i progressi sullo stato di Chrome .
• Da Firefox 79, imposta network.cookie.sameSite.schemeful su true tramite about:config. Monitora i progressi attraverso il Bugzilla problema.

Uno dei motivi principali per il passaggio a SameSite=Lax come valore predefinito per i cookie erano per proteggere dalla falsificazione di richieste tra siti (CSRF) Tuttavia, il traffico HTTP non sicuro rappresenta comunque un’opportunità per i malintenzionati di rete manomettere i cookie che verranno poi utilizzati nella versione HTTPS sicura del sito. La creazione di questo ulteriore confine tra siti tra gli schemi fornisce un'ulteriore difesa contro questi attacchi.

Scenari comuni in più schemi

Navigazione

Navigare tra le versioni in più schemi di un sito web (ad esempio, creare collegamenti da Da http://site.example a https://site.example) consentiva in precedenza SameSite=Strict cookie da inviare. Questa viene ora considerata una navigazione, il che significa che i cookie di SameSite=Strict verranno bloccati.

Caricamento delle risorse secondarie in corso...

Le eventuali modifiche apportate qui devono essere considerate come soluzioni temporanee, mentre eseguire l'upgrade all'HTTPS completo.

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

Il caricamento di una sottorisorsa a schema incrociato su una pagina consentiva in precedenza SameSite=Strict o SameSite=Lax cookie da inviare o impostare. Questo è come qualsiasi altra risorsa secondaria di terze parti o tra siti che significa che verranno bloccati eventuali cookie SameSite=Strict o SameSite=Lax.

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

PUBBLICARE un modulo

La pubblicazione tra versioni in più schemi di un sito web consentiva cookie impostati con SameSite=Lax o SameSite=Strict da inviare. Questo è trattati come POST tra siti: possono essere inviati solo SameSite=None cookie. Puoi riscontra questo scenario su siti che presentano la versione non sicura per impostazione predefinita, ma esegui l'upgrade degli utenti alla versione sicura al momento dell'invio della richiesta di accesso modulo di pagamento.

Come per le sottorisorse, se la richiesta proviene da un ambiente sicuro, ad es. da HTTPS a HTTPS non sicuro, ad esempio HTTP, contesto, quindi tutti i cookie verranno bloccati su queste richieste poiché i cookie di terze parti o tra siti richiedono Secure.

Come faccio a testare il mio sito?

Gli strumenti per sviluppatori e la messaggistica sono disponibili in Chrome e Firefox.

In Chrome 86, nella scheda Problema DevTools. includono i problemi di Schemeful Same-Site. Potresti vedere i seguenti problemi evidenziati per il tuo sito.

Problemi di navigazione:

• "Esegui la migrazione completamente a HTTPS per continuare a ricevere i cookie sullo stesso sito richieste": un avviso che informa che il cookie verrà bloccato in una versione futura. di Chrome.
• "Esegui la migrazione completamente a HTTPS per ricevere i cookie nelle richieste sullo stesso sito" - A che avvisa che il cookie è stato bloccato.

Problemi di caricamento delle sottorisorse:

• "Esegui la migrazione completamente a HTTPS per continuare a ricevere i cookie sullo stesso sito risorse secondarie" oppure "Esegui la migrazione completamente a HTTPS per continuare a consentire i cookie essere impostato da risorse secondarie dello stesso sito"; avvisi che informano del fatto che il cookie sarà bloccato in una versione futura di Chrome.
• "Esegui la migrazione completamente a HTTPS per ricevere i cookie alle sottorisorse sullo stesso sito" oppure "Esegui la migrazione completamente a HTTPS per consentire l'impostazione dei cookie dalla stessa subresources": avvisa che il cookie è stato bloccato. Quest'ultimo l'avviso può essere visualizzato anche quando PUBBLICA un modulo.

Ulteriori dettagli sono disponibili in Suggerimenti per test e debug per lo schema Same-Site.

Da Firefox 79, con network.cookie.sameSite.schemeful impostato su true tramite about:config nella console verrà visualizzato un messaggio per i problemi relativi allo stesso sito di Schemeful. Sul tuo sito potresti notare quanto segue:

• "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 in DevTools del mio browser?

È possibile che alcuni link e risorse secondarie puntino ancora a link non sicuri URL.

Un modo per risolvere il problema consiste nell'utilizzare HTTP Massima sicurezza per i trasporti (HSTS) e la direttiva includeSubDomain. Con HSTS + includeSubDomain anche Se una delle tue pagine include accidentalmente un link non sicuro, il browser la versione sicura.

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

Ti consigliamo vivamente di eseguire l'upgrade del tuo sito completamente a HTTPS per proteggere i tuoi utenti, se non sei in grado di farlo autonomamente, ti consigliamo di rivolgerti il tuo provider host per vedere se può offrire questa opzione. Se sei tu a organizzare l'evento, quindi Let's Encrypt offre una serie di strumenti installare e configurare un certificato. Puoi anche verificare lo spostamento del sito dietro una rete CDN o altro proxy in grado di fornire la connessione HTTPS.

Se il problema persiste, prova ad allentare la protezione di SameSite su cookie interessati.

• Nei casi in cui vengono bloccati solo i cookie SameSite=Strict, puoi ridurre la protezione per Lax.
• Nei casi in cui i cookie Strict e Lax vengano bloccati e la tua i cookie vengono inviati (o impostati da) un URL sicuro, puoi ridurre protezioni a None.
  • Questa soluzione alternativa non avrà esito positivo se l'URL a cui stai inviando i cookie (o (impostazione da cui sono impostati) non è sicura. Questo perché SameSite=None richiede Secure sui cookie, il che significa che questi cookie potrebbero non essere inviati o e la configurazione tramite una connessione non sicura. In questo caso non sarà possibile accedere quel cookie fino a quando non viene eseguito l'upgrade del sito a HTTPS.
  • Ricordate che si tratta di una situazione solo temporanea, in quanto i cookie di terze parti verranno eliminati completamente.

Qual è l'impatto sui miei cookie se non ho specificato un attributo SameSite?

I cookie senza un attributo SameSite vengono trattati come se fossero stati specificati SameSite=Lax e lo stesso comportamento in più schemi si applica a questi cookie: beh. Tieni presente che si applica ancora l'eccezione temporanea ai metodi non sicuri. Consulta mitigazione Lax + POST in Chromium SameSite Domande frequenti per saperne di più.

Quali sono le conseguenze per i WebSocket?

Le connessioni WebSocket saranno comunque considerate dello stesso sito se sono uguali sicurezza della pagina.

Stesso sito:

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

Cross-site:

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

Foto di Julissa Capdevilla attivo Rimuovi schermo