Accesso alla rete privata: introduzione dei preflight

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

regolari

• 7 luglio 2022: è stato aggiornato lo stato attuale e è stata aggiunta la definizione dello spazio di indirizzi IP.
• 27 aprile 2022: aggiornamento dell'annuncio sulle tempistiche.
• 7 marzo 2022: annuncio di rollback dopo il rilevamento di problemi in Chrome 98.

Introduzione

Chrome sta ritirando 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 sottorisorsa, che chiede l'autorizzazione esplicita al server di destinazione. Questa richiesta preflight trasformerà una nuova intestazione, Access-Control-Request-Private-Network: true, e la risposta deve includere un'intestazione corrispondente, Access-Control-Allow-Private-Network: true.

Lo scopo è proteggere gli utenti da attacchi di richiesta di falsificazione tra siti (CSRF) che prendono di mira 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.

Piano di implementazione

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

1. In Chrome 104:

   • Esperimenti Chrome inviando richieste preflight prima delle richieste di sottorisorse di rete privata.
   • Gli errori preflight vengono visualizzati solo in DevTools, senza influire in altro modo sulle richieste di rete privata.
   • Chrome raccoglie i dati sulla compatibilità e contatta i principali siti web interessati.
   • Ci aspettiamo che questa funzionalità sia ampiamente compatibile con i siti web esistenti.
   Avviso: per limitare gli effetti sui siti web che non supportano già i preflight, il timeout è limitato a 200 millisecondi in Chrome 104. La limitazione viene applicata solo in modalità di avviso. Il limite di timeout speciale viene rimosso dopo aver abilitato la modalità di applicazione forzata impostando l'opzione "Rispetta il risultato dei preflight di accesso alla rete privata" su "Attivato" in chrome://flags e il limite predefinito è di 5 secondi.

2. Al più presto in Chrome 113:

   • Questa modifica inizierà solo se e quando i dati sulla compatibilità indicano che la modifica è sufficientemente sicura e abbiamo contattato direttamente quando necessario.
   • Chrome impone che le richieste preflight vadano a buon fine, altrimenti non superano le richieste.
   • Una prova relativa al ritiro inizia contemporaneamente per consentire ai siti web interessati in questa fase di richiedere un'estensione 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, annunciato in precedenza 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 per Chrome 104.

Che cos'è l'accesso alla 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 dalla versione 96 di Chrome, solo i contesti sicuri sono autorizzati a effettuare richieste di rete privata. Per informazioni dettagliate, consulta il nostro post del blog precedente.

La specifica estende anche il protocollo di condivisione delle risorse tra origini (CORS) in modo che i siti web ora debbano richiedere esplicitamente una concessione dai server sulle 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 rispetto a quello da cui è stata recuperata la richiesta che ha avviato la 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 di indirizzi IP privati contiene indirizzi IP che hanno un significato solo all'interno della rete attuale, inclusi 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 definiti in RFC1918, indirizzi locali rispetto al link 169.254.0.0/16 definiti in RFC3927, indirizzi unicast IPv6 locali univoci fc00::/7 definiti in RFC4193, indirizzi unicast IPv6 locali collegati nella sezione RFC9 fe80::/10 definitiRFC4291

Lo spazio di 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 in Private Network Access (CORS-RFC1918)

Per saperne di più, consulta la pagina Richiesta di feedback: CORS per reti private (RFC1918).

Richieste preflight

Contesto

Le richieste preflight sono un meccanismo introdotto dallo standard CORS (Cross-Origin Resource Sharing) utilizzato per richiedere l'autorizzazione a un sito web di destinazione prima di inviare al sito una richiesta HTTP che potrebbe avere effetti collaterali. In questo modo il server di destinazione comprende il protocollo CORS e riduce in modo significativo il rischio di attacchi CSRF.

La richiesta di autorizzazione viene inviata come una richiesta HTTP OPTIONS con intestazioni delle richieste CORS specifiche che descrivono la richiesta HTTP imminente. La risposta deve portare specifiche intestazioni delle risposte CORS in modo esplicito per la richiesta imminente.

Novità relative all'accesso alla rete privata

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

• La colonna Access-Control-Request-Private-Network: true è impostata su tutte le richieste preflight PNA
• Il campo 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 e dalla modalità di richiesta. Vengono inviate 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 delle risposte siano resi disponibili o meno all'autore dell'azione.

Nota: se la richiesta di rete privata viene effettuata in modalità cors, è necessario impostare le intestazioni CORS nella risposta finale, oltre alla risposta preflight.

Le richieste preflight per PNA vengono inviate anche per le richieste della stessa origine, se l'indirizzo IP di destinazione è più privato rispetto all'autore dell'avvio. Questo processo è diverso dal normale CORS, in cui le richieste preflight sono solo per le richieste multiorigine. Le richieste preflight per le richieste della stessa origine proteggono dagli attacchi DNS rebinding.

Esempi

Il comportamento osservabile dipende dalla modalità di richiesta.

Modalità senza CORS

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

Chrome invia innanzitutto una richiesta preflight:

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

Affinché questa richiesta abbia esito positivo, 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 dovrebbero essere raramente accessibili a tutte le origini, quindi valuta con attenzione i rischi associati alla configurazione di un'intestazione di questo tipo.

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 sia 192.168.1.1.

Chrome invia innanzitutto 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 abbia esito positivo, 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

Chrome invierà la richiesta effettiva:

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

A cui il server può rispondere in base alle 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 una richiesta preflight prima di questa. 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 preflight interessate possono essere visualizzate e diagnosticate anche nel riquadro di rete:

Se la tua richiesta ha attivato un normale preflight CORS senza regole di accesso alla rete privata, nel riquadro di rete potrebbero essere visualizzati due preflight; il primo risulta sempre non riuscito. Questo è un bug noto e puoi tranquillamente ignorarlo.

Per esaminare cosa succede se è stato applicato l'esito positivo preflight, 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 funzionerà dopo la seconda fase del nostro piano di implementazione. Gli errori possono essere diagnosticati come gli avvisi utilizzando i riquadri DevTools menzionati in precedenza.

Che cosa fare se il tuo sito web è interessato

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

Hai a disposizione due soluzioni:

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

Gestire le richieste preflight lato server

Aggiorna il server di destinazione di tutti i recuperi interessati per gestire le richieste preflight PNA. In primo luogo, implementa il supporto per le richieste preflight CORS standard sulle route interessate. Quindi, aggiungi il supporto per le due nuove intestazioni di risposta.

Quando il 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 insieme a qualsiasi altra informazione pertinente (ad esempio Access-Control-Request-Headers) per garantire che la richiesta sia consentita in sicurezza. In genere, dovresti consentire l'accesso a una singola origine sotto il tuo controllo.

Avviso: fai attenzione alle origini non sicure (non https), perché non sono autenticate. Un aggressore sul percorso potrebbe mascherarsi da una qualsiasi origine di questo tipo.

Una volta che il server ha deciso di consentire la richiesta, dovrebbe rispondere 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, nonché altre intestazioni necessarie.

Consulta gli esempi per scenari concreti.

Disattiva i controlli dell'accesso alla rete privata utilizzando i criteri aziendali

Se hai il controllo amministrativo sugli utenti, puoi disabilitare i controlli dell'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 su una rete privata che prevede richieste da reti pubbliche, il team di Chrome sarà interessato al tuo feedback e ai tuoi casi d'uso. Contattaci inviando un problema con Chromium all'indirizzo crbug.com e impostando il componente su Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Passaggi successivi

In seguito, Chrome estenderà i controlli di accesso privato alla rete per coprire i web worker: worker dedicati, worker condivisi e service worker. Il nostro obiettivo è fare in modo che Chrome 107 inizi a mostrare avvisi.

Successivamente, Chrome estenderà i controlli di accesso alla rete privata per coprire le navigazioni, inclusi iframe e popup. Il nostro obiettivo è fare in modo che Chrome 108 inizi a mostrare avvisi.

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

Ringraziamenti

Foto di copertina di Mark Olsen su Unsplash.