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