La prova di ritiro dell'accesso alla rete privata (PNA) per contesti non sicuri sta per finire. Implementa la richiesta di autorizzazione PNA

Yifan Luo
Yifan Luo

Chrome 124 include la funzionalità Autorizzazione di accesso alla rete privata per allentare i contenuti misti. È in corso un prova di ritiro per i siti che hanno bisogno di più tempo per prepararsi a questo cambiamento, ma questa prova termina con Chrome 132, la cui distribuzione è prevista per il 4 febbraio 2025. Questo post spiega la modifica, fornisce maggiori informazioni sul design della funzionalità, su come eseguire la migrazione dei tuoi siti web attuali e su come testare l'implementazione.

Che cosa cambia?

Per stabilire connessioni con dispositivi su una rete privata che non hanno nomi univoci a livello globale e che, di conseguenza, non possono ottenere certificati TLS, questa funzionalità introduce una nuova opzione per fetch() per dichiarare l'intenzione di uno sviluppatore di comunicare con un dispositivo di questo tipo. Sono incluse una nuova funzionalità controllata da norme per limitare l'accesso di ogni sito a questa funzionalità e nuove intestazioni per la risposta preflight del server per fornire metadati aggiuntivi.

Che cos'è l'accesso a rete privata?

L'accesso alla rete privata (PNA, precedentemente noto come CORS-RFC1918 e brevemente come accesso alla rete locale) è una funzionalità di sicurezza che limita la capacità dei siti web di inviare richieste ai server su reti private. In questo modo, gli utenti e le reti interne sono protetti da potenziali attacchi come la falsificazione di richieste cross-site (CSRF). Chrome ha implementato gradualmente la PNA e la protezione verrà ampliata nelle release future.

Perché è necessaria una richiesta di autorizzazione?

Chrome 94 ha introdotto un blocco dell'accesso alla rete privata da siti web pubblici non sicuri. La sperimentazione in corso sull' ritiro dell'accesso alla rete privata da contesti non sicuri ha rivelato difficoltà nella migrazione dei siti web interessati a HTTPS. Un problema comune è la difficoltà di eseguire la migrazione dei dispositivi privati a HTTPS, con conseguente violazione dei controlli dei contenuti misti.

Per risolvere questo problema, è stato aggiunto un nuovo prompt per le autorizzazioni nell'ambito di una prova dell'origine a partire da Chrome 120 e nella versione stabile a partire da Chrome 124.

Quando è necessaria una richiesta di autorizzazione?

Abbiamo pianificato di terminare la prova del ritiro dei contesti non sicuri dopo alcuni traguardi in seguito alla disponibilità della funzionalità di richiesta di autorizzazione. Per garantire la compatibilità, devi eseguire la migrazione dei tuoi siti web pubblici a HTTPS. Se non riesci a eseguire la migrazione del tuo server privato a HTTPS, la nuova funzionalità di richiesta di autorizzazione ti consentirà di allentare i controlli dei contenuti misti.

Di seguito è riportato un flusso di lavoro tipico per una richiesta di accesso alla rete privata con richiesta di autorizzazione.

Attivare la richiesta di autorizzazione

Aggiungi il nuovo attributo targetAddressSpace come opzione di recupero, in modo che la richiesta possa saltare il controllo dei contenuti misti.

fetch("http://router.local/ping", {
  targetAddressSpace: "private",
});

In conformità con le indicazioni riportate in Private Network Access: introducing preflight, qualsiasi richiesta di accesso alla rete privata è preceduta da una richiesta di preflight. Questa richiesta di preflight includerà una nuova intestazione, Access-Control-Request-Private-Network: true, e la risposta corrispondente deve includere l'intestazione Access-Control-Allow-Private-Network: true.

Per supportare la nuova richiesta di autorizzazione, i dispositivi devono incorporare due nuove intestazioni di risposta: Private-Network-Access-Name e Private-Network-Access-ID.

  • Private-Network-Access-ID: un valore di 48 bit presentato come 6 byte esadecimali separati da due punti.
  • Private-Network-Access-Name: un nome valido come stringa che corrisponde all'espressione regolare ECMAScript /^[a-z0-9_-.]+$/. La lunghezza massima del nome è 248 unità di codice UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Demo

Puoi provare la demo all'indirizzo: https://private-network-access-permission-test.glitch.me/.

Per utilizzare il sito web demo, devi avviare il tuo server privato personale. Il server privato deve rispondere con l'intestazione HTTP Access-Control-Allow-Private-Network: true, insieme alle intestazioni Private-Network-Access-ID e Private-Network-Access-Name specificate dal server. Se tutto è impostato correttamente, dovrebbe essere visualizzato il seguente prompt per l'autorizzazione:

Uscire dalla prova del ritiro del contesto non sicuro

Per i siti web che hanno registrato la prova relativa al ritiro dell'accesso alla rete privata per i contesti non sicuri, è arrivato il momento di eseguire la migrazione del sito web con la nostra nuova richiesta di autorizzazione ed uscire dalla prova.

Dopo aver aggiornato il codice, elimina il token di prova nelle intestazioni HTML, JavaScript o HTTP. Se non ricordi dove hai inserito il token di prova, consulta la sezione Registrati per la prova prima del ritiro del post del blog precedente.

Ti consigliamo inoltre di eliminare il token nella pagina della prova.

Passaggi successivi

La soluzione per le richieste da fetch() non API è ancora in fase di esplorazione.

Sono state testate diverse soluzioni, ad esempio l'utilizzo di service worker o la creazione di uno spazio indirizzi di destinazione come nuovo Content-Security-Policy. Tuttavia, la forma finale per le richieste da fetch() non API è ancora in fase di indagine.

In futuro, le richieste provenienti da frame secondari potrebbero essere supportate con i criteri di autorizzazione.

In futuro, potremmo voler supportare i criteri di autorizzazione per allentare le limitazioni relative ai frame secondari.

Feedback per i casi d'uso delle reti private

Se ospiti un sito web su una rete privata che richiede richieste da reti pubbliche, il team di Chrome vuole il tuo feedback. Invia una segnalazione al tracker dei problemi di Chromium (componente: Blink>SecurityFeature>CORS>PrivateNetworkAccess) o nel repository GitHub.

Risorse