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 sulle tempistiche.
• 7 marzo 2022: è stato annunciato il rollback dopo aver rilevato dei problemi in Chrome 98.

Introduzione

Chrome ritirerà l'accesso diretto agli endpoint di rete privata da siti web pubblici nell'ambito della specifica Private Network Access (PNA).

Chrome inizierà a inviare una richiesta preflight CORS prima di qualsiasi richiesta di rete privata per una risorsa secondaria, in cui viene richiesta l'autorizzazione esplicita dal server di destinazione. Questa richiesta preflight includerà una nuova intestazione, Access-Control-Request-Private-Network: true, e la risposta alla richiesta deve avere un'intestazione corrispondente, Access-Control-Allow-Private-Network: true.

Lo scopo è proteggere gli utenti da attacchi di falsificazione di richieste cross-site (CSRF) che prendono di mira router e altri dispositivi su reti private. Questi attacchi hanno interessato centinaia di migliaia di utenti, consentendo agli utenti malintenzionati di reindirizzarli a server dannosi.

Piano di implementazione

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

1. In Chrome 104:

   • Chrome esegue esperimenti inviando richieste di preflight prima delle richieste di risorse secondarie della rete privata.
   • Gli errori di preflight mostrano solo avvisi in DevTools, senza influire sulle richieste di rete privata.
   • Chrome raccoglie dati sulla compatibilità e contatta i più grandi siti web interessati.
   • Ci aspettiamo che sia ampiamente compatibile con i siti web esistenti.
   Avviso: per limitare gli effetti sui siti web che non supportano già i preflight, il tempo di attesa è limitato a 200 millisecondi in Chrome 104. La limitazione viene applicata solo in modalità di avviso. Il limite di timeout speciale verrà rimosso dopo aver attivato la modalità di applicazione impostando "Rispetta il risultato dei preflight di accesso alla rete privata" su "Attivato" in chrome://flags e il limite predefinito è 5 secondi.

2. In Chrome 113 o versioni successive:

   • Questo inizierà solo se e quando i dati sulla compatibilità indicheranno che la modifica è abbastanza sicura e avremo contattato direttamente te, se necessario.
   • Chrome impone che le richieste preflight debbano andare a buon fine, altrimenti le richieste non andranno a buon fine.
   • Allo stesso tempo viene avviata una prova relativa al ritiro per consentire ai siti web interessati da questa fase di richiedere un'estensione del periodo di tempo. La prova durerà almeno 6 mesi.

Nota: in precedenza è stato fatto un tentativo di implementare gli avvisi in Chrome 98 e Chrome 102, come annunciato in questo post del blog. È stato eseguito il rollback dopo che sono stati rilevati problemi di stabilità e compatibilità durante l'implementazione. I problemi identificati sono stati risolti in Chrome 104.

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

L'accesso alla rete privata (precedentemente noto come CORS-RFC1918) limita la possibilità dei siti web di inviare richieste a server su reti private.

Chrome ha già implementato parte della specifica: a partire da Chrome 96, solo i contesti sicuri sono autorizzati a effettuare richieste di rete privata. Per maggiori dettagli, consulta il nostro post del blog precedente.

La specifica estende anche il protocollo CORS (Cross-Origin Resource Sharing) in modo che i siti web debbano ora richiedere esplicitamente una concessione dai server su reti private prima di poter inviare richieste arbitrarie.

Termine chiave: le richieste di rete privata sono richieste il cui indirizzo IP del server di destinazione è più privato di quello da cui è stato recuperato l'iniziatore 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.

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 indirizzi di loopback IPv4 (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 degli indirizzi IP privati contiene indirizzi IP che hanno significato solo all'interno della rete corrente, inclusi 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 definiti nella RFC1918, indirizzi link-local 169.254.0.0/16 definiti nella RFC3927, indirizzi unicast IPv6 locali univoci fc00::/7 definiti nella RFC4193, indirizzi unicast IPv6 link-local fe80::/10 definiti nella sezione 2.5.6 della RFC4291 e indirizzi IPv6 mappati a IPv4 in cui l'indirizzo IPv4 mappato è esso stesso 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, che è considerato più privato di un indirizzo IP pubblico.

Relazione tra reti pubbliche, private e locali nell'accesso alla rete privata (CORS-RFC1918)

Scopri di più all'indirizzo 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 per richiedere l'autorizzazione da un sito web di destinazione prima di inviargli una richiesta HTTP che potrebbe avere effetti collaterali. In questo modo, il server di destinazione comprende il protocollo CORS e riduce notevolmente il rischio di attacchi CSRF.

La richiesta di autorizzazione viene inviata come richiesta HTTP OPTIONS con intestazioni di richiesta CORS specifiche che descrivono la richiesta HTTP imminente. La risposta deve contenere intestazioni di risposta CORS specifiche che accettano 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 di preflight PNA
• Access-Control-Allow-Private-Network: true deve essere impostato su tutte le risposte di preflight PNA

Le richieste di preflight per le PNA vengono inviate per tutte le richieste di rete privata, indipendentemente dal metodo di richiesta e dalla modalità. Vengono inviati prima delle richieste in modalità cors, no-cors e in tutte le altre modalità. Questo perché tutte le richieste di rete privata possono essere utilizzate per gli attacchi CSRF, indipendentemente dalla modalità di richiesta e dal fatto che i contenuti della risposta siano messi o meno a disposizione dell'iniziatore.

Nota: se la richiesta di rete privata viene effettuata in modalità cors, le intestazioni CORS devono essere impostate sulla risposta finale, oltre che sulla risposta preflight.

Le richieste di preflight per i PNA vengono inviate anche per le richieste dello stesso ambito, se l'indirizzo IP di destinazione è più privato di quello dell'iniziatore. A differenza del CORS normale, in cui le richieste di preflight sono solo per le richieste cross-origin. Le richieste di preflight per le richieste dello stesso ambito proteggono dagli attacchi di DNS rebinding.

Esempi

Il comportamento osservabile dipende dalla modalità della richiesta.

Nessuna modalità CORS

Supponiamo che https://foo.example/index.html incorpori <img src="https://bar.example/cat.gif" alt="dancing cat"/> e bar.example risolva in 192.168.1.1, un indirizzo IP privato secondo RFC 1918.

Chrome invia prima una richiesta preflight:

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

Affinché questa richiesta vada a buon fine, il server deve rispondere con:

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

Avviso: il server può impostare Access-Control-Allow-Origin: *, anche se questa operazione è pericolosa e sconsigliata. Le risorse di rete privata raramente devono essere accessibili a tutte le origini, quindi valuta attentamente i rischi legati all'impostazione di un'intestazione di questo tipo.

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',
})

Di nuovo, bar.example restituisce 192.168.1.1.

Chrome invia prima 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

Poi Chrome invierà la richiesta effettiva:

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

A cui il server può rispondere in base alle normali 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, verrà inviata una richiesta di preflight. Se questa richiesta preflight non va a buon fine, la richiesta finale verrà comunque inviata, ma verrà visualizzato un avviso nel riquadro dei problemi di DevTools.

Le richieste di preflight interessate possono essere visualizzate e diagnosticate anche nel riquadro della rete:

Se la tua richiesta avrebbe attivato un normale preflight CORS senza regole di accesso alla rete privata, nel pannello della rete potrebbero essere visualizzati due preflight, con il primo che sembra sempre non riuscito. Si tratta di un bug noto e puoi ignorarlo.

Per verificare cosa succede se l'esito positivo del preflight è stato applicato, puoi passare 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. In questo modo puoi verificare se il tuo sito web funzionerebbe dopo la seconda fase del nostro piano di implementazione. Gli errori possono essere diagnosticati allo stesso modo degli avvisi utilizzando i riquadri di DevTools sopra indicati.

Che cosa fare se il sito web è interessato

Quando questa modifica verrà implementata in Chrome 104, non dovrebbe causare interruzioni su nessun sito web. Tuttavia, ti consigliamo vivamente di aggiornare i percorsi delle richieste interessati per assicurarti 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 eventuali recuperi interessati in modo da gestire le richieste di preflight PNA. In primo luogo, implementa il supporto per le richieste preflight CORS standard sulle route interessate. Aggiungi poi il supporto per le due nuove intestazioni di risposta.

Quando il tuo server riceve una richiesta preflight (una richiesta OPTIONS con intestazioni CORS), deve verificare la presenza di un'intestazione Access-Control-Request-Private-Network: true. Se questa intestazione è presente nella richiesta, il server deve esaminare l'intestazione Origin e il percorso della richiesta, nonché eventuali altre informazioni pertinenti (ad esempio Access-Control-Request-Headers) per verificare che la richiesta sia sicura da consentire. In genere, devi consentire l'accesso a una singola origine sotto il tuo controllo.

Avviso: fai attenzione alle origini non sicure (non https), in quanto non sono autenticate. Un malintenzionato sul percorso potrebbe rubare l'identità di una di queste origini.

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

Per scenari concreti, consulta gli esempi.

Disattivare i controlli di accesso alla rete privata utilizzando i criteri aziendali

Se disponi del controllo amministrativo sugli utenti, puoi disattivare i controlli di accesso alla rete privata utilizzando 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 prevede richieste da reti pubbliche, il team di Chrome è interessato al tuo feedback e ai tuoi casi d'uso. Comunicacelo segnalando un problema relativo a Chromium all'indirizzo crbug.com e imposta il componente su Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Passaggi successivi

In futuro, Chrome estenderà i controlli di accesso alla rete privata per coprire i worker web: worker dedicati, worker condivisi e worker di servizio. Prevediamo di iniziare a mostrare gli avvisi con Chrome 107.

In seguito, Chrome estenderà i controlli di accesso privato alla rete per coprire le navigazioni, inclusi iframe e popup. Prevediamo di iniziare a mostrare gli avvisi con Chrome 108.

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

Ringraziamenti

Foto di copertina di Mark Olsen su Unsplash.