Contenuto misto dietro una VPN: ripara la risorsa, non il tunnel

Una pagina HTTPS che carica script via HTTP effettua due richieste con due livelli di protezione diversi, e il lucchetto descrive solo la prima. Un tunnel non cambia questo, perché protegge il trasporto e non lo schema proprio della risorsa. Il browser ti sta già dicendo quale richiesta è fallita, se leggi la console invece della barra degli indirizzi. Tre controlli ti portano da una pagina che funziona a metà a una riparazione reale.

Leggi la richiesta, non la barra degli indirizzi

Un documento recuperato via HTTPS può fare riferimento a uno script, a un foglio di stile, a un carattere o a una cornice via HTTP semplice. Quel riferimento è una richiesta separata, ed è quella di cui il browser si lamenta. La protezione del documento principale non risale fino a essa, e il tunnel che trasporta entrambi i flussi non altera nessuno dei due schemi. La pagina può quindi essere davvero sicura e davvero rotta allo stesso tempo.

Chiamare la risorsa semplicemente un file incluso non rende innocua la sua sostituzione.

Se il contenuto di uno script non sicuro può essere alterato in transito e poi eseguito, può cambiare il comportamento della pagina, che è un problema più grande di un guasto estetico. Le immagini comportano un rischio minore ma reale quando vengono modificate lungo il percorso. Il lucchetto non mente su nulla. Risponde a una domanda più stretta di quella che gli hai posto.

Sapere quali risorse vengono bloccate e quali promosse

I browser non trattano ogni tipo di risorsa allo stesso modo. le linee guida sui contenuti misti separano le richieste promosse a HTTPS da quelle bloccate del tutto, con script, fogli di stile e richieste programmatiche dal lato bloccato, mentre immagini e media possono invece essere promossi o segnalati.

Questa differenza spiega i rapporti confusi. Una pagina con uno script bloccato perde del tutto una funzionalità, mentre una pagina con un'immagine promossa sembra a posto e ha silenziosamente cambiato la sua richiesta. Le categorie documentate hanno anche eccezioni, quindi non dare per scontato che ogni URL di un certo tipo venga promosso con successo. Leggi ciò che la console dice sulla richiesta specifica invece di ragionare da un'estensione di file.

Un widget bloccato non è la prova che il tunnel abbia fallito. È la prova che il browser ha fatto il suo lavoro.

Ripara il riferimento alla sua origine

Per il proprietario del sito, la riparazione appartiene al punto in cui è stato scritto l'URL non sicuro: un modello, un foglio di stile, uno script che compone URL o un componente di terze parti. Cambiare l'indirizzo visibile della pagina lascia tutto questo intatto. Cerca l'host nel sorgente e ripara ogni riferimento, non solo quello che la console ha citato per caso.

Poi conferma che la risorsa sia davvero servita via HTTPS con un'identità valida, perché un cambio di schema non può far comparire un servizio che non è mai stato pubblicato lì.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Segui anche i reindirizzamenti, perché un riferimento che inizia con HTTPS può comunque finire su un percorso di consegna in testo semplice. Quando una dipendenza semplicemente non ha una consegna sicura disponibile, rimuovila o sostituiscila tramite il normale processo di modifica invece di distribuire una soluzione tampone. Per un utente, lascia attive le protezioni del browser e segnala al proprietario del sito l'URL della risorsa, il suo tipo e il messaggio della console. Non diffondere mai istruzioni che chiedono al personale di consentire contenuti non sicuri per una pagina, perché quell'eccezione sopravvive all'incidente che l'ha provocata.

Verifica di nuovo la pagina come la toccano gli utenti

Esercita le operazioni che caricano risorse su richiesta, non solo il primo documento. Le pagine recuperano codice, dati e download aggiuntivi dopo la pressione di un pulsante, e quelle richieste sono spesso quelle non sicure. Conferma le richieste specifiche e il comportamento visibile con la protezione ancora attiva. Un test che inizia con un profilo del browser allentato non può mostrarti ciò che vede un utente normale.

Il tunnel ha ancora il suo compito, e quel compito è l'accesso alla rete, non l'integrità della pagina.

Una volta che il traffico lascia l'estremità del tunnel, qualsiasi richiesta HTTP rimanente non ha guadagnato nulla dal trasporto. Ripara il percorso della risorsa e mantieni l'applicazione nel browser. Trattare un ulteriore livello di trasporto come riparazione di una dipendenza non sicura è il modo in cui un team finisce con uno script di help desk che disattiva il controllo che funzionava correttamente.