Accesso alla rete privata: introduzione dei preflight

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Aggiornamenti

• 7 luglio 2022: aggiornamento dello stato attuale e aggiunta della definizione dello spazio degli indirizzi IP.
• 27 aprile 2022: annuncio aggiornato sulla cronologia.
• 7 marzo 2022: è stato annunciato il rollback dopo la scoperta dei problemi nella Chrome 98.

Introduzione

Chrome sta ritirando l'accesso diretto agli endpoint di rete privati dai pubblici siti web nell'ambito Accesso privato alla rete (PNA) e la specifica del prodotto.

Chrome inizierà a inviare una richiesta preflight CORS prima di qualsiasi richiesta di rete privata per una risorsa secondaria, che chiede per ottenere l'autorizzazione esplicita da parte del server di destinazione. Questa richiesta preflight includere una nuova intestazione, Access-Control-Request-Private-Network: true e la risposta deve avere un'intestazione corrispondente Access-Control-Allow-Private-Network: true.

Lo scopo è proteggere gli utenti da attacchi di falsificazione di richieste tra siti (CSRF) il targeting di router e altri dispositivi su reti private. Questi attacchi hanno colpito centinaia di migliaia di utenti, consentendo agli aggressori di reindirizzarli a server dannosi.

Piano di implementazione

Chrome implementerà questa modifica in due fasi per dare ai siti web il tempo di notarlo la modifica e apportare le modifiche necessarie.

1. In Chrome 104:

   • Esperimenti di Chrome inviando richieste preflight prima della rete privata richieste di sottorisorse.
   • Gli errori preflight mostrano solo avvisi in DevTools, senza altrimenti delle richieste di rete privata.
   • Chrome raccoglie dati sulla compatibilità e contatta il numero maggiore interessato siti web.
   • Ci aspettiamo che questa funzionalità sia ampiamente compatibile con i siti web esistenti.
   di Gemini Advanced.

2. In Chrome 113 al più presto:

   • Questa operazione inizierà solo se e quando i dati di compatibilità indicano che il cambiamento è abbastanza sicuro e lo abbiamo contattato direttamente, se necessario.
   • Chrome impone l'esito delle richieste preflight, altrimenti non andranno a buon fine le richieste.
   • Una prova relativa al ritiro inizia il giorno allo stesso tempo per consentire ai siti web interessati da questa fase di richiedere una un'estensione di orario. La prova durerà almeno 6 mesi.

Che cos'è l'accesso alla rete privata (PNA)

Accesso alla rete privata (noto in precedenza come CORS-RFC1918) limita la possibilità dei siti web di inviare richieste ai server su reti.

Chrome ha già implementato parte delle specifiche: a partire dalla versione 96, contesti sicuri possono effettuare richieste di rete privata. Consulta le nostre post del blog precedente per maggiori dettagli.

La specifica estende anche la condivisione delle risorse tra origini (CORS) per cui i siti web devono ora richiedere esplicitamente una concessione ai server sulle reti private prima di poter inviare richieste arbitrarie.

In che modo PNA classifica gli indirizzi IP e identifica una rete privata?

Gli indirizzi IP sono classificati in tre spazi di indirizzi IP: - public - private - local

Lo spazio di indirizzi IP locali contiene indirizzi IP che sono IPv4 indirizzi di loopback (127.0.0.0/8) definiti nella sezione 3.2.1.3 di RFC1122 o indirizzi di loopback IPv6 (::1/128) definiti nella sezione 2.5.3 di RFC4291.

Lo spazio di indirizzi IP privati contiene indirizzi IP che hanno un solo significato all'interno della rete attuale, tra cui 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 definito in RFC1918, indirizzi locali rispetto al collegamento 169.254.0.0/16 definiti in RFC3927, indirizzi unicast IPv6 locali univoci fc00::/7 definiti in RFC4193, Indirizzi unicast IPv6 locali rispetto al collegamento fe80::/10 definiti nella sezione 2.5.6 di RFC4291 e indirizzi IPv6 mappati a IPv4, dove l'indirizzo IPv4 mappato è a sua volta privato.

Lo spazio degli indirizzi IP pubblici contiene tutti gli altri indirizzi non menzionati in precedenza.

Un indirizzo IP locale è considerato più privato di un indirizzo IP privato, è considerato più privato di un indirizzo IP pubblico.

Per saperne di più, vedi Feedback richiesto: CORS per reti private (RFC1918).

Richieste preflight

Sfondo

Le richieste preflight sono un meccanismo introdotto dallo standard CORS (condivisione delle risorse tra origini) utilizzato richiedere l'autorizzazione da un sito web di destinazione prima di inviargli una richiesta HTTP che potrebbero avere effetti collaterali. Ciò assicura che il server di destinazione comprenda il protocollo CORS e riduce significativamente il rischio di attacchi CSRF.

La richiesta di autorizzazione viene inviata come richiesta HTTP OPTIONS con intestazioni delle richieste CORS specifiche che descrive la richiesta HTTP imminente. La risposta deve includere intestazioni della risposta CORS specifiche accettando esplicitamente la richiesta imminente.

Novità dell'accesso alla rete privata

Viene introdotta una nuova coppia di intestazioni di richiesta e risposta per le richieste preflight:

• Access-Control-Request-Private-Network: true è impostato su tutte le richieste preflight PNA
• Access-Control-Allow-Private-Network: true deve essere impostato su tutte le risposte preflight PNA

Le richieste preflight per PNA vengono inviate per tutte le richieste di rete privata, indipendentemente dal metodo di richiesta mode. Vengono inviati in anticipo rispetto alle richieste in modalità cors, nonché in no-cors e in tutte le altre modalità. Questo è che tutte le richieste di rete privata possono essere usate per attacchi CSRF, a prescindere dalla modalità di richiesta e dal fatto che i contenuti della risposta vengano a disposizione dell'iniziatore.

Le richieste preflight per PNA vengono inviate anche per le richieste della stessa origine, se l'indirizzo IP di destinazione è più privato di quello dell'iniziatore. Questa operazione è diversa dalla CORS, in cui le richieste preflight sono solo per le richieste multiorigine. Prima del periodo di pubblicazione per le richieste della stessa origine Attacchi di rebinding DNS.

Esempi

Il comportamento osservabile dipende modalità di richiesta.

Nessuna modalità CORS

Di' https://foo.example/index.html incorporamenti <img src="https://bar.example/cat.gif" alt="dancing cat"/> e bar.example si risolve in 192.168.1.1, un indirizzo IP privato secondo RFC 1918.

Chrome prima invia una richiesta preflight:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Affinché questa richiesta venga soddisfatta, il server deve rispondere con:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Dopodiché Chrome invierà la richiesta effettiva:

HTTP/1.1 GET /cat.gif
...

A cui il server può rispondere normalmente.

modalità CORS

Supponiamo che https://foo.example/index.html esegua il seguente codice:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Anche in questo caso, supponiamo che bar.example venga risolto in 192.168.1.1.

Chrome prima invia una richiesta preflight:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Affinché questa richiesta venga soddisfatta, il server deve rispondere con:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Dopodiché Chrome invierà la richiesta effettiva:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

A cui il server può rispondere secondo le consuete regole CORS:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Come sapere se il tuo sito web è interessato

A partire da Chrome 104, se viene rilevata una richiesta di rete privata, viene inviata verrà inviata prima. Se questa richiesta preflight non va a buon fine, verrà verrà comunque inviata, ma verrà visualizzato un avviso in DevTools nel riquadro dei problemi.

Le richieste preflight interessate possono anche essere visualizzate e diagnosticate nel riquadro Rete:

Se la tua richiesta avrebbe attivato un normale preflight CORS senza delle regole di accesso alla rete privata, potrebbero essere visualizzati due preflight di rete, dove il primo sembrava sempre presentare errori. Si tratta di un bug noto, puoi tranquillamente ignorarlo.

Per esaminare cosa succede se è stato applicato l'esito preflight, puoi: passa il seguente argomento della riga di comando, a partire da Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Qualsiasi richiesta preflight non riuscita comporterà un recupero non riuscito. Questo può consentirti per verificare se il tuo sito web funzionerebbe seconda fase del nostro piano di implementazione. Gli errori possono essere diagnosticati in allo stesso modo degli avvisi usando i riquadri DevTools menzionati sopra.

Che cosa fare se il sito web è interessato

Quando questa modifica verrà implementata in Chrome 104, non è previsto interrompere sito web. Tuttavia, ti consigliamo vivamente di aggiornare i percorsi di richiesta interessati per assicura che il tuo sito web continui a funzionare come previsto.

Le soluzioni a tua disposizione sono due:

1. Gestire le richieste preflight sul lato server
2. Disattiva i controlli PNA con i criteri aziendali

Gestire le richieste preflight lato server

Aggiorna il server di destinazione di tutti i recuperi interessati per gestire il preflight PNA richieste. Innanzitutto, implementa il supporto per le richieste preflight CORS standard su le route interessate. Quindi, aggiungi il supporto per le due nuove intestazioni delle risposte.

Quando il tuo server riceve una richiesta preflight (una richiesta OPTIONS con CORS ), il server deve verificare la presenza di un Intestazione Access-Control-Request-Private-Network: true. Se questa intestazione è presenti nella richiesta, il server deve esaminare l'intestazione Origin e percorso di richiesta insieme a qualsiasi altra informazione pertinente (ad esempio Access-Control-Request-Headers) per assicurarti che la richiesta possa essere consentita in sicurezza. In genere, dovresti consentire l'accesso a un'unica origine sotto il tuo controllo.

Una volta che il server ha deciso di consentire la richiesta, deve rispondere 204 No Content (o 200 OK) con le intestazioni CORS necessarie e il nuovo PNA intestazione. Queste intestazioni includono Access-Control-Allow-Origin e Access-Control-Allow-Private-Network: true e altri, se necessario.

Fai riferimento agli esempi per scenari concreti.

Disabilita i controlli di accesso alla rete privata che utilizzano i criteri aziendali

Se hai il controllo amministrativo sugli utenti, puoi disattivare le Controlli di accesso alla rete con uno dei seguenti criteri:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Per saperne di più, consulta Comprendere la gestione dei criteri di Chrome.

Inviaci i tuoi commenti

Se ospiti un sito web all'interno di una rete privata che riceve richieste reti pubbliche, il team di Chrome è interessato ai tuoi feedback e ai tuoi casi d'uso. Faccelo sapere segnalando un problema relativo a Chromium all'indirizzo crbug.com e imposta il componente a Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Passaggi successivi

In seguito, Chrome estenderà i controlli dell'accesso alla rete privata web worker: lavoratori dedicati, condivisi e dei servizi. Il nostro obiettivo è per iniziare a mostrare gli avvisi in Chrome 107.

Chrome estenderà i controlli dell'accesso privato alla rete per coprire le navigazioni, inclusi iframe e popup. Abbiamo in programma di puntare a Chrome 108 per l'avvio che mostrano avvisi.

In entrambi i casi, procederemo con cautela con un'analoga implementazione graduale, per dare agli sviluppatori web il tempo di adeguare e stimare il rischio di compatibilità.

Ringraziamenti

Foto di copertina di Mark Olsen su Rimuovi schermo.