VPN disambungkan tetapi kandungan bercampur masih disekat: apa yang perlu dibaiki

Separuh halaman dipaparkan, satu helaian gaya kelihatan kelabu dalam panel Rangkaian, dan klien VPN masih melaporkan terowong yang sihat. Ketiga-tiga pemerhatian benar serentak, kerana pelayar menilai permintaan yang dibuat halaman dan terowong tidak mempunyai suara dalam penilaian itu. Yang menutup kes ialah keputusan, bukan tetapan: baiki rujukan, serahkan isu kepada pemilik hos, atau lepaskan kebergantungan itu. Setiap pilihan mempunyai ujian murah, dan memilih yang salah menghabiskan satu kitaran sokongan.

Mengapa terowong tidak boleh melindungi sub-sumber

Kandungan bercampur bermula dengan dokumen HTTPS yang meminta sub-sumber melalui HTTP biasa. Setiap URL dinilai mengikut skemanya sendiri, jadi perlindungan dokumen induk tidak pernah meluas kepada permintaan anak. Penyulitan yang ditambah di bawah pelayar mengubah apa yang bergerak di wayar, bukan http:// yang diminta oleh penanda.

Pelayar semasa membahagikan permintaan ini kepada dua kumpulan dan mengendalikannya secara berbeza. Skrip, helaian gaya, iframe dan panggilan melalui fetch, XMLHttpRequest atau WebSocket ditolak terus, tanpa percubaan peningkatan terlebih dahulu. Imej, audio dan video ditulis semula ke https:// dan diminta semula, dan pemuatan dibatalkan apabila pengambilan selamat itu gagal. URL sub-sumber yang hosnya ialah alamat IP kosong dikecualikan daripada peningkatan, jadi imej HTTP pada hos IP kekal disekat dan bukannya dibaiki secara senyap. Pembahagian itu, termasuk pengecualian di sisi boleh ditingkatkan, didokumenkan dalam panduan kandungan bercampur Mozilla. Chrome menggunakan penolakan serupa pada muat turun tidak selamat yang dimulakan dari halaman selamat, sebab itu pautan PDF boleh mati sementara halaman di sekelilingnya kelihatan utuh.

Baris kelabu itu oleh itu bukti kawalan berfungsi, bukan bukti terowong membocorkan teks biasa. Anggap baris itu sebagai penemuan yang menunjuk satu rujukan, bukan seluruh halaman.

Tentukan siapa pemilik rujukan tidak selamat itu

Isih URL bermasalah mengikut tempat ia dihasilkan sebelum mengubah apa-apa. Jawapan itu menentukan sama ada anda boleh mengeluarkan pembaikan hari ini, sama ada vendor perlu mengeluarkannya, atau sama ada kebergantungan itu perlu meninggalkan halaman. Bacanya dari lajur Initiator dalam panel Rangkaian, kerana penanda di skrin selalunya dipasang semasa masa jalan.

Apabila hos sudah menjawab pada 443 dan hanya rujukannya yang berkata http, pembaikannya setempat: ubah rujukan, kosongkan cache halaman dan sahkan baris itu bertukar kepada https. Hos yang hanya mendengar pada port 80 tidak boleh dijadikan patuh melalui penyuntingan, jadi sumber itu berpindah, diletakkan sesuatu yang anda kawal di hadapannya, atau hilang. URL yang disuntik pengurus tag masih muncul walaupun templat anda sendiri bersih, dan kes itu tergolong dalam tiket dengan URL tepat dan baris konsol dilampirkan. Menyuruh kakitangan membenarkan kandungan tidak selamat bukan salah satu pilihan ini, kerana ia mematikan pemeriksaan bagi setiap laman yang dilawati profil pelayar itu.

Baiki rujukan, bukan tetapan pelayar

Muat semula aliran yang gagal dengan log rangkaian dikekalkan dan tapis panel mengikut hos yang anda syaki. Konsol menamakan URL dan direktif, yang memutuskan sama ada permintaan ditolak atau ditingkatkan sebelum anda menyentuh templat.

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

Dua kawalan sokongan patut diketahui, dan kedua-duanya tidak menggantikan pembaikan. Pengepala Content-Security-Policy dengan upgrade-insecure-requests membuat pelayar menulis semula URL sub-sumber http sebelum meninggalkan halaman, yang menangkap rujukan lama yang belum anda temui. Permintaan yang ditulis semula masih gagal apabila hos sasaran tidak menyajikan HTTPS, jadi pengepala itu hanya mengubah URL mana yang dicuba pelayar. HSTS berkuat kuasa mengikut hos, bermakna dasar pada domain anda sendiri tidak melakukan apa-apa untuk CDN pihak ketiga yang tidak pernah menghantar pengepala itu. Selepas mengubah templat, kosongkan cache halaman dan cari nama hos lama dalam HTML yang dipaparkan, kerana URL yang sama juga boleh datang melalui separa, rentetan terjemahan atau medan pangkalan data.

Ikuti juga ubah hala, kerana rantaian yang bermula pada https:// boleh mendarat di lokasi http:// dan pelayar menilai lompatan terakhir. Bentuk -L arahan kedua di atas mencetak URL berkesan itu untuk anda. Jika lompatan terakhir ialah http tulen, rujukan itu masih salah walaupun pautan yang anda sunting kelihatan baik.

Sahkan halaman dengan konsol dan panel rangkaian

Muat semula dengan cache dimatikan dan lalui aliran itu sekali lagi, termasuk butang yang memuatkan kandungan atas permintaan. Pemuatan pertama halaman menyembunyikan widget lambat, jubin peta dan skrip pemain yang hanya muncul selepas klik. Konsol sepatutnya tidak membawa entri kandungan bercampur dan setiap baris yang anda sentuh sepatutnya memaparkan https. Tangkap konsol dan baris permintaan sebelum menutup tiket, kerana keadaan itu sukar dibina semula selepas penggunaan seterusnya.

Apabila sumber itu milik orang lain, hantar empat perkara: URL tepat, jenis permintaan, teks konsol dan halaman tempat ia muncul. Sembunyikan pengecam sesi dalam semua yang anda tampal ke dalam tiket. Laporan yang hanya berkata imej rosak tidak memberi pemiliknya apa-apa untuk dicari.

Terowong terus menjalankan tugasnya sendiri sementara pembaikan berada dalam rujukan yang menghasilkan permintaan itu. Selepas penggunaan, cari nama hos sekali lagi dalam templat dan bundel vendor, dan tutup kes hanya apabila tiada entri kandungan bercampur yang disekat tinggal dalam konsol.