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.
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.
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.
![Le richieste sono private quando una rete più disponibile invia una richiesta a un
con meno rete disponibile.](https://developer.chrome.com/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=3&hl=it)
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 PNAAccess-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:
- Gestire le richieste preflight sul lato server
- 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 utilizzando uno dei seguenti criteri:
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.