Riduci i rischi associati all’esposizione involontaria dei dispositivi e dei server della rete interna di un client al web in generale.
I siti web dannosi che inviano richieste a dispositivi e server ospitati su una rete privata sono da tempo una minaccia. Gli aggressori potrebbero, ad esempio, modificare la configurazione di un router wireless per abilitare gli attacchi Man-in-the-Middle. CORS-RFC1918 è una proposta per bloccare queste richieste per impostazione predefinita sul browser e richiedere che i dispositivi interni attivino le richieste dalla rete internet pubblica.
Per capire in che modo questa modifica influisce sull'ecosistema web, il team di Chrome vorrebbe ricevere feedback dagli sviluppatori che creano server per le reti private.
Cosa c'è che non va nello status quo?
Molti server web vengono eseguiti all'interno di una rete privata: router wireless, stampanti, siti web intranet, servizi aziendali e dispositivi IoT (Internet of Things) costituiscono solo una parte. Potrebbero sembrare in un ambiente più sicuro rispetto a quelli esposti al pubblico, ma questi server possono essere utilizzati in modo illecito da malintenzionati che utilizzano una pagina web come proxy. Ad esempio, siti web dannosi possono incorporare un URL che, quando semplicemente visualizzato dalla vittima (su un browser abilitato per JavaScript), tenta di modificare le impostazioni del server DNS sul router a banda larga di casa della vittima. Questo tipo di attacco, chiamato "Drive-By Pharming", è avvenuto nel 2014, Sono stati sfruttati oltre 300.000 router wireless vulnerabili modificando le impostazioni DNS e consentendo agli utenti malintenzionati di reindirizzare gli utenti a server dannosi.
CORS-RFC1918
Per ridurre la minaccia di attacchi simili, la community web sta implementando CORS-RFC1918, la condivisione delle risorse tra origini (CORS), specializzata per le reti private definite in RFC1918.
I browser che implementano CORS controllano con le risorse di destinazione se possono essere caricati da un'origine diversa. Ciò avviene mediante intestazioni aggiuntive incorporate che descrivono l'accesso oppure utilizzando un meccanismo chiamato richieste preflight, a seconda della complessità. Per scoprire di più, consulta Condivisione delle risorse tra origini.
Con CORS-RFC1918, il browser blocca per impostazione predefinita il caricamento delle risorse sulla rete privata, ad eccezione di quelle consentite esplicitamente dal server mediante CORS e HTTPS. Il sito web che effettua richieste a queste risorse dovrà inviare le intestazioni CORS e il server dovrà indicare esplicitamente di accettare la richiesta multiorigine rispondendo con le intestazioni CORS corrispondenti. Le intestazioni CORS esatte sono ancora in fase di sviluppo.
Gli sviluppatori di tali dispositivi o server saranno tenuti a fare due cose:
- Assicurati che il sito web che effettua richieste a una rete privata venga gestito tramite HTTPS.
- Configura il supporto del server per CORS-RFC1918 e rispondi con le intestazioni HTTP previste.
Quali tipi di richieste sono interessati?
Le richieste interessate includono:
- Richieste dalla rete pubblica a una rete privata
- Richieste da una rete privata a una rete locale
- Richieste dalla rete pubblica a una rete locale
Una rete privata
Una destinazione che si risolve nello spazio di indirizzi privati definito nella sezione 3 di
RFC1918 in IPv4, un indirizzo IPv6 mappato su IPv4
in cui l'indirizzo IPv4 mappato è privato o un indirizzo IPv6 esterno
alle subnet ::1/128
, 2000::/3
e ff00::/8
.
Una rete locale
Una destinazione che si risolve nello spazio "loopback" (127.0.0.0/8
) definito nella sezione 3.2.1.3 di RFC1122 di IPv4, lo spazio "link-local" (169.254.0.0/16
) definito in
RFC3927 di IPv4, il prefisso "Unique Local
Address" (fc00::/7
) definito nella sezione 3 di
"RFC1.2} del prefisso"RFC1} nella sezione RFC9} di
RFC4193fe80::/10
RFC4291
Una rete pubblica Tutti gli altri.
![Relazione tra reti pubbliche, private e locali in CORS-RFC1918](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/relationship-between-publ-b36a72c2b6ded.png?authuser=0000&hl=it)
Chrome prevede l'abilitazione di CORS-RFC1918
Chrome sta introducendo CORS-RFC1918 in due passaggi:
Passaggio 1: le richieste alle risorse della rete privata saranno consentite solo da pagine web HTTPS
Chrome 87 aggiunge un flag che impone di utilizzare HTTPS per i siti web pubblici che effettuano richieste alle risorse di rete privata. Puoi andare a
about://flags#block-insecure-private-network-requests
per abilitarlo. Se questo flag è attivo, qualsiasi richiesta a una risorsa di rete privata da un sito web HTTP verrà bloccata.
A partire da Chrome 88, gli errori CORS-RFC1918 verranno segnalati come errori dei criteri CORS nella console.
![Gli errori CORS-RFC1918 verranno segnalati come errori dei criteri CORS nella console.](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-be-r-b862b694a7ca2.png?authuser=0000&hl=it)
Nel riquadro Rete di Chrome DevTools puoi abilitare la casella di controllo Richieste bloccate per concentrarti sulle richieste bloccate:
![Gli errori CORS-RFC1918 verranno segnalati anche come errori CORS nel riquadro Network.](https://developer.chrome.com/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-also-67275e6c8a037.png?authuser=0000&hl=it)
In Chrome 87, gli errori CORS-RFC1918 vengono segnalati solo nella console DevTools come ERR_INSECURE_PRIVATE_NETWORK_REQUEST
.
Puoi fare una prova in autonomia utilizzando questo sito web di prova.
Passaggio 2: invia le richieste preflight con un'intestazione speciale
In futuro, ogni volta che un sito web pubblico tenterà di recuperare risorse da una rete privata o locale, Chrome invierà una richiesta preflight prima della richiesta effettiva.
La richiesta includerà un'intestazione Access-Control-Request-Private-Network: true
e altre intestazioni delle richieste CORS. Tra le altre cose, queste intestazioni identificano l'origine della richiesta, consentendo un controllo dell'accesso granulare. Il server può rispondere con un'intestazione Access-Control-Allow-Private-Network:
true
per indicare esplicitamente che concede l'accesso alla risorsa.
Feedback desiderato
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. Puoi aiutarti in due modi:
- Vai a
about://flags#block-insecure-private-network-requests
, attiva il flag e controlla se il tuo sito web invia richieste alla risorsa di rete privata come previsto. - Se riscontri problemi o vuoi inviare un feedback, segnala un problema all'indirizzo crbug.com e imposta il componente su
Blink>SecurityFeature>CORS>RFC1918
.
Feedback di esempio
Il nostro router wireless gestisce un sito web per amministratori per la stessa rete privata, ma tramite HTTP. Se è richiesto HTTPS per i siti web che incorporano il sito web dell'amministratore, sarà contenuto misto. Dovremmo attivare HTTPS sul sito web dell'amministratore in una rete chiusa?
Questo è esattamente il tipo di feedback che Chrome cerca. Segnala un problema relativo al tuo caso d'uso concreto all'indirizzo crbug.com. Chrome vorrebbe conoscere la tua opinione.
Immagine hero di Stephen Philips su Unsplash.