Riduci i rischi associati all'esposizione involontaria di dispositivi e server sulla rete interna di un cliente al web in generale.
I siti web dannosi che inviano richieste a dispositivi e server ospitati su una rete privata rappresentano da tempo una minaccia. Ad esempio, gli utenti malintenzionati potrebbero modificare la configurazione di un router wireless per attivare gli attacchi di tipo Man-in-the-Middle. CORS-RFC1918 è una proposta per bloccare queste richieste per impostazione predefinita nel browser e richiedere l'attivazione delle richieste provenienti dalla rete internet pubblica per i dispositivi interni.
Per comprendere l'impatto di questa modifica sull'ecosistema web, il team di Chrome è alla ricerca di feedback da parte degli sviluppatori che creano server per 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) sono solo alcuni esempi. Potrebbero sembrare in un ambiente più sicuro rispetto a quelli esposti al pubblico, ma questi server possono essere utilizzati in modo improprio dagli attaccanti che utilizzano una pagina web come proxy. Ad esempio, i siti web dannosi possono incorporare un URL che, se visualizzato semplicemente dalla vittima (su un browser con JavaScript abilitato), tenta di modificare le impostazioni del server DNS sul router di banda larga di casa della vittima. Questo tipo di attacco è chiamato "pharming dinamico" e si è verificato nel 2014. Più di 300.000 router wireless vulnerabili sono stati sfruttati modificando le impostazioni DNS e consentendo agli attaccanti di reindirizzare gli utenti a server dannosi.
CORS-RFC1918
Per ridurre la minaccia di attacchi simili, la community web sta introducendo CORS-RFC1918, ovvero la condivisione delle risorse tra origini (CORS), per le reti private definite in RFC1918.
I browser che implementano CORS controllano con le risorse di destinazione se è consentito il caricamento da un'origine diversa. Questo viene ottenuto con intestazioni aggiuntive in linea che descrivono l'accesso o utilizzando un meccanismo chiamato richieste di preflight, a seconda della complessità. Per saperne di più, consulta la sezione Condivisione delle risorse tra origini (CORS).
Con CORS-RFC1918 il browser blocca per impostazione predefinita il caricamento delle risorse sulla rete privata, ad eccezione di quelle consentite esplicitamente dal server tramite CORS e HTTPS. Il sito web che effettua richieste a queste risorse dovrà inviare intestazioni CORS e il server dovrà dichiarare esplicitamente di accettare la richiesta tra origini rispondendo con le intestazioni CORS corrispondenti. Le intestazioni CORS esatte sono ancora in fase di sviluppo.
Agli sviluppatori di questi dispositivi o server verrà chiesto di eseguire due operazioni:
- Assicurati che il sito web che effettua richieste a una rete privata venga pubblicato tramite HTTPS.
- Configura il supporto del server per CORS-RFC1918 e rispondi con le intestazioni HTTP previste.
Quali tipi di richieste sono interessate?
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 risolve nello spazio indirizzi privato definito nella Sezione 3 del
RFC1918 in IPv4, un indirizzo IPv6 mappato su IPv4
dove l'indirizzo IPv4 mappato è a sua volta privato o un indirizzo IPv6
al di fuori delle sottoreti ::1/128
, 2000::/3
e ff00::/8
.
Una rete locale
Una destinazione che risolve nello spazio "loopback" (127.0.0.0/8
) definito nella
sezione 3.2.1.3 di RFC1122 di IPv4, nello
spazio "link-local" (169.254.0.0/16
) definito nella
RFC3927 di IPv4, nel prefisso "Indirizzo locale univoco" (fc00::/7
) definito nella sezione 3 di
RFC4193 di IPv6 o nel prefisso "link-local" (fe80::/10
) definito nella sezione 2.5.6 di
RFC4291 di IPv6.
Una rete pubblica Tutte le altre.

Piani di Chrome per l'abilitazione di CORS-RFC1918
Chrome implementerà CORS-RFC1918 in due fasi:
Passaggio 1: le richieste alle risorse di rete privata saranno consentite solo dalle pagine web HTTPS
Chrome 87 aggiunge un flag che impone ai siti web pubblici che inviano richieste alle risorse di rete private di utilizzare HTTPS. Puoi andare su
about://flags#block-insecure-private-network-requests
per attivarlo. Se questo opzione è attivata, tutte le richieste a una risorsa di rete privata da un sito web HTTP verranno bloccate.
A partire da Chrome 88, gli errori CORS-RFC1918 verranno segnalati come errori dei criteri CORS nella console.

Nel riquadro Rete di Chrome DevTools puoi attivare la casella di controllo Richieste bloccate per concentrarti sulle richieste bloccate:

In Chrome 87, gli errori CORS-RFC1918 vengono segnalati nella console DevTools solo come
ERR_INSECURE_PRIVATE_NETWORK_REQUEST
.
Puoi provarlo tu stesso utilizzando questo sito web di test.
Passaggio 2: invio di richieste di preflight con un'intestazione speciale
In futuro, ogni volta che un sito web pubblico tenta di recuperare risorse da una rete privata o locale, Chrome invierà una richiesta di preflight prima della richiesta effettiva.
La richiesta includerà un'intestazione Access-Control-Request-Private-Network: true
oltre ad altre intestazioni delle richieste CORS. Tra le altre cose, questi parametri identificano l'origine che effettua la richiesta, consentendo un controllo granulare dell'accesso. Il server può rispondere con un'intestazione Access-Control-Allow-Private-Network:
true
per indicare esplicitamente che concede l'accesso alla risorsa.
Feedback richiesto
Se ospiti un sito web all'interno di una rete privata che si aspetta richieste da reti pubbliche, il team di Chrome è interessato ai tuoi feedback e casi d'uso. Puoi svolgere due operazioni per aiutarci:
- Vai a
about://flags#block-insecure-private-network-requests
, attiva l'indicatore e controlla se il tuo sito web invia richieste alla risorsa di rete privata come previsto. - Se riscontri problemi o vuoi inviare un feedback, invia una segnalazione all'indirizzo
crbug.com
e imposta il componente su
Blink>SecurityFeature>CORS>RFC1918
.
Feedback di esempio
Il nostro router wireless gestisce un sito web di amministrazione per la stessa rete privata, ma tramite HTTP. Se HTTPS è obbligatorio per i siti web che incorporano il sito web di amministrazione, si tratta di contenuti misti. È il caso di attivare HTTPS sul sito web di amministrazione in una rete chiusa?
Questo è esattamente il tipo di feedback che cerca Chrome. Invia una segnalazione con il tuo caso d'uso specifico all'indirizzo crbug.com. Chrome vorrebbe ricevere il tuo feedback.
Immagine hero di Stephen Philips su Unsplash.