Feedback desiderato: CORS per reti private (RFC1918)

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.

Relazione tra reti pubbliche, private e locali in CORS-RFC1918
Relazione tra reti pubbliche, private e locali in CORS-RFC1918.

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.

Gli errori CORS-RFC1918 verranno segnalati come errori delle norme CORS nella console.
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:

Gli errori CORS-RFC1918 verranno segnalati anche come errori CORS nel riquadro Rete.
Gli errori CORS-RFC1918 verranno segnalati anche come errori CORS nel riquadro Rete.

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.