Mitigare i rischi associati all'esposizione involontaria di dispositivi e server su una rete interna di un cliente al web in generale.
I siti web dannosi che effettuano richieste a dispositivi e server ospitati su una rete privata sono da tempo una minaccia. Man-in-the-Middle CORS-RFC1918 è una proposta per bloccare queste richieste per impostazione predefinita nel browser e richiedere ai dispositivi interni di attivare le richieste provenienti da internet pubblico.
Per capire in che modo questa modifica influisce sull'ecosistema web, il team di Chrome sta cercando feedback dagli sviluppatori che creano server per reti private.
Qual è il problema con lo 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 illecito dagli aggressori che utilizzano una pagina web come proxy. Ad esempio, i siti web dannosi possono incorporare un URL che, quando viene visualizzato dalla vittima (su un browser con JavaScript abilitato), tenta di modificare le impostazioni del server DNS sul router a banda larga domestico della vittima. Questo tipo di attacco è chiamato "Drive-By Pharming" e è avvenuto nel 2014. Più di 300.000 router wireless vulnerabili sono stati sfruttati modificando le impostazioni DNS e consentendo agli aggressori di reindirizzare gli utenti a server dannosi.
CORS-RFC1918
Per mitigare la minaccia di attacchi simili, la community web sta introducendo CORS-RFC1918, ovvero la condivisione delle risorse tra origini (CORS) specializzata per le reti private definite in RFC1918.
I browser che implementano CORS verificano con le risorse di destinazione se è consentito il caricamento da un'origine diversa. A seconda della complessità, questa operazione viene eseguita con intestazioni aggiuntive in linea che descrivono l'accesso o utilizzando un meccanismo chiamato richieste preflight. Per saperne di più, consulta Condivisione delle risorse tra origini.
Con CORS-RFC1918, il browser bloccherà il caricamento delle risorse sulla rete privata per impostazione predefinita, ad eccezione di quelle esplicitamente consentite dal server tramite CORS e HTTPS. Il sito web che effettua richieste a queste risorse dovrà inviare le intestazioni CORS e il server dovrà dichiarare esplicitamente di accettare la richiesta multiorigine 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:
- Assicurarsi che il sito web che effettua richieste a una rete privata venga pubblicato tramite HTTPS.
- Configurare il supporto del server per CORS-RFC1918 e rispondere 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 in IPv4 in cui l'indirizzo IPv4 mappato è privato o un indirizzo IPv6
al di fuori delle 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, nello
spazio "link-local" (169.254.0.0/16) definito in
RFC3927 di IPv4, nel prefisso "Unique Local
Address" (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 abilitare CORS-RFC1918
Chrome introdurrà CORS-RFC1918 in due passaggi:
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 effettuano richieste alle risorse di rete privata di utilizzare HTTPS. Puoi andare a about://flags#block-insecure-private-network-requests per abilitarlo. Con questo flag attivato, 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 solo nella console DevTools come ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Puoi provarlo tu stesso utilizzando questo sito web di test.
Passaggio 2: invio di 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 oltre ad altre intestazioni delle richieste CORS. Tra le altre cose, queste intestazioni identificano l'origine che effettua la 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 richiesto
Se ospiti un sito web all'interno di una rete privata che prevede richieste da reti pubbliche, il team di Chrome è interessato ai tuoi feedback e casi d'uso. Ecco due cose che puoi fare per aiutarci:
- Vai a
about://flags#block-insecure-private-network-requests, attiva il flag e verifica se il tuo sito web invia le richieste alla risorsa di rete privata come previsto. - Se riscontri problemi o hai feedback, invia un problema all'indirizzo
crbug.com
e imposta il componente su
Blink>SecurityFeature>CORS>RFC1918.
Esempio di feedback
Il nostro router wireless pubblica 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 tratterà di contenuti misti. Dobbiamo abilitare HTTPS sul sito web di amministrazione in una rete chiusa?
Questo è esattamente il tipo di feedback che Chrome sta cercando. Invia un problema con il tuo caso d'uso concreto all'indirizzo crbug.com. Chrome sarà felice di ricevere il tuo feedback.