regolari
23 marzo 2023: la cronologia è stata aggiornata e il ritiro non avverrà fino a Chrome 117.
19 gennaio 2023: la cronologia è stata aggiornata e il ritiro non avverrà fino a Chrome 114.
12 agosto 2022: la cronologia è stata aggiornata e il ritiro non avverrà fino a Chrome 109.
10 febbraio 2022: è stato pubblicato un articolo aggiornato nella pagina relativa all'accesso alla rete privata: introduzione ai preflight
25 agosto 2021: aggiornamento dell'annuncio con le tempistiche e introduzione di una prova relativa al ritiro.
Chrome sta ritirando l'accesso agli endpoint di rete privata da siti web non sicuri nell'ambito della specifica Accesso a rete privata. Lo scopo è proteggere gli utenti da attacchi di falsificazione di richieste tra siti (CSRF) che prendono di mira i router e altri dispositivi sulle reti private. Questi attacchi hanno colpito centinaia di migliaia di utenti, consentendo a utenti malintenzionati di reindirizzarli a server dannosi.
Chrome introdurrà le seguenti modifiche:
- Blocco delle richieste alle reti private da siti web pubblici non sicuri a partire da Chrome 94.
- Ti presentiamo una prova relativa al ritiro che terminerà in Chrome
- Consentirà agli sviluppatori di richiedere un'estensione del tempo per le origini scelte, che non saranno interessate dalla prova relativa al ritiro.
- Introduzione di un criterio di Chrome che consentirà ai deployment di Chrome gestiti di ignorare definitivamente il ritiro. Disponibile in Chrome 92.
Se hai bisogno di più tempo per ridurre l'impatto del registro relativo al ritiro per la prova relativa al ritiro.
Se hai il controllo amministrativo sugli utenti, puoi riattivare la funzionalità utilizzando i criteri di Chrome.
Per mitigare l'impatto delle nuove restrizioni, utilizza una delle seguenti strategie:
- Esegui l'upgrade del sito web a HTTPS e, se necessario, del server di destinazione.
- Esegui l'upgrade del tuo sito web a HTTPS e utilizza WebTransport.
- Inverti la relazione di incorporamento.
Sequenza
- Novembre 2020: richiesta di feedback sui cambiamenti imminenti.
- Marzo 2021: dopo aver esaminato i feedback e aver contattato il team, vengono annunciate le modifiche imminenti. La specifica viene rinominata da CORS-RFC1918 ad Accesso alla rete privato.
- Aprile 2021: Chrome 90 viene implementato nel canale stabile e mostra avvisi sul ritiro.
- Giugno 2021: Chrome 92 viene implementato nella versione beta, escludendo le richieste di reti private da contesti non sicuri. In seguito al feedback degli sviluppatori che richiedono più tempo per adattarsi, il ritiro viene differito a Chrome 93, per essere accompagnato da una prova relativa al ritiro.
- Luglio 2021: dopo ulteriori feedback degli sviluppatori, il ritiro e la prova associata vengono rimandati a Chrome 94. Inoltre, i siti web privati non sono più interessati dal ritiro.
- Agosto 2021: Chrome 94 viene implementato nella versione beta. Gli sviluppatori web possono iniziare a registrarsi per la prova relativa al ritiro.
- Settembre 2021: Chrome 94 viene implementato nella versione stabile. Gli sviluppatori web devono aver effettuato la registrazione per la prova relativa al ritiro e aver eseguito il deployment dei token di prova in produzione.
- Dicembre 2022: sondaggio della prova dell'origine inviato e feedback ricevuto. La prova relativa al ritiro è estesa a Chrome 113.
- Marzo 2023: la prova relativa al ritiro è stata estesa a Chrome 116 e terminerà a Chrome 117. È in fase di sviluppo un meccanismo alternativo basato sulle autorizzazioni, che ha come target la release iniziale in Chrome 114.
- Maggio 2023 (provvisorio): viene implementato il meccanismo basato su autorizzazioni in Chrome 114. I siti web possono utilizzarlo per uscire dalla prova relativa al ritiro.
- Settembre 2023: viene implementato Chrome 117 nel canale stabile, terminando la prova relativa al ritiro. Chrome blocca tutte le richieste di rete privata da contesti pubblici non sicuri.
Che cos'è l'accesso alla rete privata
L'accesso alla rete privata (precedentemente noto come CORS-RFC1918) limita la possibilità dei siti web di inviare richieste a server su reti private. ma solo da contesti sicuri. La specifica estende anche il protocollo CORS (Cross-Origin Resource Sharing) in modo che i siti web debbano richiedere esplicitamente una concessione dai server sulle reti private prima di poter inviare richieste arbitrarie.
Le richieste di rete privata sono richieste il cui indirizzo IP del server di destinazione è più privato rispetto a quello da cui è stato recuperato l'autore della richiesta. Ad esempio, una richiesta da un sito web pubblico (https://example.com) a un sito web privato (http://router.local) o una richiesta da un sito web privato a localhost.
Per saperne di più, consulta la pagina Richiesta di feedback: CORS per reti private (RFC1918).
Che cos'è una prova relativa al ritiro
Le prove di deprecazione (precedentemente note come prove di deprecazione dell'origine) sono una forma di prove dell'origine utilizzata per facilitare il ritiro delle funzionalità web. Le prove del ritiro consentono a Chrome di ritirare alcune funzionalità web e di impedire ai siti web di formare nuove dipendenze da queste ultime, dando allo stesso tempo ai siti web dipendenti attuali tempo extra per eseguirne la migrazione.
Durante una prova relativa al ritiro, le funzionalità deprecate non saranno disponibili per tutti i siti web per impostazione predefinita. Gli sviluppatori che devono ancora utilizzare le funzionalità interessate devono registrarsi alla prova relativa al ritiro e ottenere i token per le origini web specificate, quindi modificare i propri siti web per pubblicare questi token nelle intestazioni HTTP o nei meta tag (tranne in questo caso). Se un sito web pubblica token validi corrispondenti alla loro origine, Chrome consentirà l'utilizzo della funzionalità deprecata per un periodo di tempo limitato.
Per ulteriori informazioni, consulta la guida introduttiva alle prove dell'origine di Chrome e la guida per gli sviluppatori web alle prove dell'origine per istruzioni.
Cosa cambia in Chrome
Chrome 94
A partire da Chrome 94, ai contesti pubblici non sicuri (in genere siti web che non vengono pubblicati tramite HTTPS o da un indirizzo IP privato) è vietato effettuare richieste alla rete privata. Questo aspetto era stato programmato in precedenza per Chrome 92, quindi i messaggi relativi al ritiro potrebbero ancora menzionare il traguardo precedente.
Questo ritiro è accompagnato da una prova relativa al ritiro che consente agli sviluppatori web i cui siti web utilizzano la funzionalità deprecata di continuare a utilizzarla fino a Chrome 116 registrandosi per i token. Vedi di seguito per istruzioni su come registrarti e attivare la prova sul tuo sito web.
È possibile utilizzare una coppia di criteri di Chrome per disabilitare la deprecazione completamente o su origini specifiche, a tempo indeterminato. In questo modo le installazioni gestite di Chrome, ad esempio quelle in impostazioni aziendali, consentono di evitare interruzioni.
Chrome 117
La prova relativa al ritiro termina. Per continuare ad abilitare la funzionalità, è necessario eseguire la migrazione di tutti i siti web dalla funzionalità deprecata oppure di configurare i criteri degli utenti.
Azioni consigliate per gli sviluppatori
Il primo passaggio per i siti web interessati è molto probabile che acquisti un po' di tempo prima di poter eseguire il deployment di una correzione adeguata: registrandosi per la prova del ritiro o utilizzando i criteri. Successivamente, la linea d'azione consigliata varia a seconda delle circostanze di ciascun sito web interessato.
Registrati alla prova relativa al ritiro
- Fai clic su Registra per la prova dell'accesso alla rete privata da contesti non sicuri per ottenere un token di prova per l'origine partecipante.
- Aggiungi il
Origin-Trial: $tokenspecifico dell'origine all'intestazione della risposta. Questa intestazione della risposta deve essere impostata solo sulla risorsa principale e sulle risposte di navigazione quando il documento risultante utilizza la funzionalità deprecata. È inutile (sebbene innocuo) collegare questa intestazione alle risposte delle sottorisorse.
Poiché questa prova deve essere attivata o disattivata prima che un documento possa effettuare richieste, non può essere attivato tramite un tag <meta>. Questi tag vengono analizzati dal corpo della risposta solo dopo che sono state emesse le richieste di sottorisorse. Ciò rappresenta un problema per i siti web che non hanno il controllo delle intestazioni delle risposte, come i siti web statici github.io pubblicati da terze parti.
Per ulteriori dettagli, consulta la Guida per gli sviluppatori web alle prove dell'origine.
Abilita criteri
Se hai il controllo amministrativo sugli utenti, puoi riattivare la funzionalità ritirata utilizzando uno dei seguenti criteri:
Per ulteriori informazioni sulla gestione dei criteri per gli utenti, consulta questo articolo del Centro assistenza.
Accesso a localhost
Se il tuo sito web deve inviare richieste a localhost, devi solo eseguire l'upgrade del sito web a HTTPS.
Le richieste che hanno come target http://localhost (o http://127.*.*.*, http://[::1])
non vengono bloccate dai contenuti misti, anche se provengono da contesti sicuri.
Tieni presente che il motore WebKit e i browser basati su questo modello (in particolare Safari) differiscono dalla specifica per i contenuti misti W3C qui e vietano queste richieste come contenuti misti. Inoltre, non implementano l'accesso privato alla rete, pertanto i siti web potrebbero voler reindirizzare i client che utilizzano questi browser a una versione HTTP in testo non crittografato del sito web, che potremmo comunque consentire a questi browser di effettuare richieste a localhost.
Accesso agli indirizzi IP privati
Se il tuo sito web deve inviare richieste a un server di destinazione su un indirizzo IP privato, il semplice upgrade del sito web che ha avviato la campagna a HTTPS non risolve il problema. Il contenuto misto impedisce a contesti sicuri di effettuare richieste tramite HTTP in testo normale, pertanto il sito web appena protetto continuerà a non riuscire a effettuare le richieste. Puoi risolvere il problema in diversi modi:
- Esegui l'upgrade di entrambe le estremità ad HTTPS.
- Utilizza WebTransport per connetterti in modo sicuro al server di destinazione.
- Inverti la relazione di incorporamento.
Esegui l'upgrade di entrambe le estremità a HTTPS
Questa soluzione richiede il controllo sulla risoluzione DNS degli utenti, ad esempio in contesti intranet, oppure se gli utenti ottengono gli indirizzi dei propri server dei nomi da un server DHCP sotto il tuo controllo. Richiede inoltre che tu possieda un nome di dominio pubblico.
Il problema principale della gestione di siti web privati tramite HTTPS è che le autorità di certificazione dell'infrastruttura a chiave pubblica (CA PKI) forniscono certificati TLS solo ai siti web con nomi di dominio pubblici. Per risolvere il problema:
- Registra un nome di dominio pubblico (ad esempio
intranet.example) e pubblica i record DNS che puntano a quel nome di dominio su un server pubblico di tua scelta. - Ottieni un certificato TLS per
intranet.example. - All'interno della tua rete privata, configura il DNS per risolvere
intranet.examplenell'indirizzo IP privato del server di destinazione. - Configura il tuo server privato per l'utilizzo del certificato TLS per
intranet.example. Consente agli utenti di accedere al server privato inhttps://intranet.example.
Puoi quindi eseguire l'upgrade del sito web che avvia le richieste a HTTPS e continuare a effettuare le richieste come prima.
Questa soluzione è a prova di futuro e riduce la fiducia che riponi nella tua rete, estendendo l'uso della crittografia end-to-end all'interno della tua rete privata.
WebTransport
Questa soluzione non richiede il controllo sulla risoluzione DNS degli utenti. Richiede che il server di destinazione esegua un server WebTransport minimo (server HTTP/3 con alcune modifiche).
Puoi ignorare l'assenza di un certificato TLS valido firmato da una CA attendibile utilizzando WebTransport e il relativo meccanismo di blocco dei certificati. Ciò consente di stabilire connessioni sicure a dispositivi privati che potrebbero avere, ad esempio, un certificato autofirmato. Le connessioni WebTransport consentono il trasferimento bidirezionale di dati, ma non le richieste di recupero. Puoi combinare questo approccio con un service worker per eseguire il proxy in modo trasparente delle richieste HTTP sulla connessione, dal punto di vista della tua applicazione web. Sul lato server, un livello di traduzione corrispondente può convertire i messaggi WebTransport in richieste HTTP.
Siamo consapevoli che si tratta di un'ingente quantità di lavoro, ma dovrebbe essere notevolmente più semplice rispetto allo sviluppo basato su WebRTC; ci auguriamo anche che una parte dell'investimento necessario venga implementato come librerie riutilizzabili. Riteniamo inoltre che valga la pena di considerare il fatto che i contesti non sicuri potrebbero perdere l'accesso a un numero sempre maggiore di funzionalità delle piattaforme web man mano che la piattaforma punta a incoraggiare l'utilizzo di HTTPS in modi più efficaci nel corso del tempo. Indipendentemente dall'accesso alla rete privata, si tratta probabilmente di un investimento prudente.
Prevediamo che WebTransport su HTTP/3 venga spedito in Chrome 96 (è stata avviata una prova dell'origine) con mitigazioni per proteggere dalla condivisione delle chiavi e da altre pratiche di sicurezza non standard, tra cui:
- Scadenza massima breve per i certificati bloccati.
- Un meccanismo specifico del browser per revocare determinate chiavi soggette ad abuso.
Non spediremo la limitazione relativa al contesto sicuro fino ad almeno due traguardi dopo l'implementazione completa di WebTransport. La prova relativa al ritiro sarà estesa, se necessario.
Inverti incorporamento
Questa soluzione non richiede alcun controllo amministrativo sulla rete e può essere utilizzata quando il server di destinazione non è abbastanza potente per eseguire HTTPS.
Anziché recuperare le sottorisorse private da un'app web pubblica, puoi pubblicare uno scheletro dell'app dal server privato, che a sua volta recupera tutte le relative risorse secondarie (come script o immagini) da un server pubblico, ad esempio una rete CDN. L'app web risultante può quindi effettuare richieste al server privato, che sono considerate della stessa origine. Può anche effettuare richieste ad altri server con IP privati (ma non localhost), anche se ciò potrebbe cambiare a lungo termine.
Ospitando solo uno scheletro sul server privato, puoi aggiornare l'app web trasferendo nuove risorse al server pubblico, proprio come faresti con un'app web pubblica. D'altra parte, l'app web risultante non è un contesto sicuro, quindi non ha accesso ad alcune delle funzionalità più potenti del web.
Piani per il futuro
Limitare le richieste di rete privata a contesti sicuri è solo il primo passaggio per avviare l'accesso alla rete privata. Chrome si adopererà per implementare il resto della specifica nei prossimi mesi. Continua a seguirci per non perderti gli aggiornamenti.
Limitazione dell'accesso a localhost da siti web privati
Le modifiche in Chrome 94 interessano solo i siti web pubblici che accedono a indirizzi IP privati o localhost. La specifica dell'accesso alla rete privata classifica anche le richieste da siti web privati a localhost come problematiche. Chrome ritirerà anche questi elementi pubblicitari. Tuttavia, questo presenta un insieme di problemi leggermente diverso, poiché molti siti web privati non hanno nomi di dominio, il che complica l'utilizzo dei token di prova relativi al ritiro.
Richieste preflight CORS
La seconda parte dell'accesso alla rete privata consente di limitare le richieste di rete privata avviate da contesti sicuri con le richieste preflight CORS. L'idea è che, anche se la richiesta è stata avviata da un contesto sicuro, al server di destinazione viene chiesto di fornire una concessione esplicita a chi l'ha avviata. La richiesta viene inviata solo se la concessione ha esito positivo.
In breve, una richiesta preflight CORS è una richiesta HTTP OPTIONS con alcune intestazioni Access-Control-Request-* che indicano la natura della richiesta successiva. Il server può quindi decidere se concedere o meno un accesso granulare rispondendo a 200 OK con le intestazioni Access-Control-Allow-*.
Per ulteriori informazioni, consulta la specifica.
Limita i recuperi della navigazione
Chrome sta ritirando e alla fine il blocco delle richieste di sottorisorse alle reti private. Ciò non influirà sulle navigazioni alle reti private, che possono essere utilizzate anche negli attacchi CSRF.
La specifica dell'accesso alla rete privata non fa una distinzione tra i due tipi di recuperi, che alla fine saranno soggetti alle stesse restrizioni.
Foto di copertina di Markus Spiske su Unsplash