Jaukts saturs aiz VPN: labojiet resursu, ne tuneli

HTTPS lapa, kas ielādē skriptus pa HTTP, veic divus pieprasījumus ar diviem dažādiem aizsardzības līmeņiem, un slēdzene apraksta tikai pirmo. Tunelis to nemaina, jo tas aizsargā pārvadātāju, nevis paša resursa shēmu. Pārlūks jau pasaka, kurš pieprasījums neizdevās, ja lasāt konsoli, nevis adreses joslu. Trīs pārbaudes ved no daļēji strādājošas lapas līdz īstam labojumam.

Lasiet pieprasījumu, nevis adreses joslu

Pa HTTPS iegūts dokuments var atsaukties uz skriptu, stila lapu, fontu vai rāmi pa vienkāršu HTTP. Šī atsauce ir atsevišķs pieprasījums, un tieši par to sūdzas pārlūks. Galvenā dokumenta aizsardzība neatgriežas tajā, un tunelis, kas pārvadā abas plūsmas, nemaina nevienu no abām shēmām. Tāpēc lapa vienlaikus var būt patiešām droša un patiešām salauzta.

Resursa saukšana vienkārši par iekļautu failu nepadara tā aizstāšanu nekaitīgu.

Ja nedroša skripta saturu var ceļā izmainīt un pēc tam izpildīt, tas var mainīt lapas uzvedību, un tā ir lielāka problēma nekā kosmētisks defekts. Attēli rada mazāku, bet reālu risku, kad tiek ceļā izmainīti. Slēdzene par neko nemelo. Tā atbild uz šaurāku jautājumu nekā to, ko jūs tai uzdevāt.

Ziniet, kuri resursi tiek bloķēti un kuri paaugstināti

Pārlūki neizturas pret katru resursa veidu vienādi. jauktā satura vadlīnijas atdala pieprasījumus, kas tiek paaugstināti uz HTTPS, no pieprasījumiem, kas tiek pilnībā bloķēti: skripti, stila lapas un programmatiskie pieprasījumi ir bloķētajā pusē, savukārt attēli un mediji tā vietā var tikt paaugstināti vai atzīmēti.

Šī atšķirība izskaidro mulsinošos ziņojumus. Lapa ar bloķētu skriptu pilnībā zaudē funkciju, bet lapa ar paaugstinātu attēlu izskatās labi un klusi ir mainījusi savu pieprasījumu. Dokumentētajām kategorijām ir arī izņēmumi, tāpēc nepieņemiet, ka katrs noteikta veida URL tiks veiksmīgi paaugstināts. Lasiet, ko konsolē teikts par konkrēto pieprasījumu, nevis spriediet pēc faila paplašinājuma.

Bloķēts logrīks nav pierādījums, ka tunelis cieta neveiksmi. Tas ir pierādījums, ka pārlūks izdarīja savu darbu.

Izlabojiet atsauci tās avotā

Vietnes īpašniekam labojums pieder vietai, kur tika ierakstīts nedrošais URL: veidne, stila lapa, skripts, kas saliek URL, vai trešās puses komponente. Redzamās lapas adreses maiņa to visu atstāj neskartu. Meklējiet avotā resursdatoru un izlabojiet katru atsauci, ne tikai to vienu, ko konsolē nejauši nosauca.

Tad pārliecinieties, ka resurss patiešām tiek pasniegts pa HTTPS ar derīgu identitāti, jo shēmas maiņa nevar radīt pakalpojumu, kas tur nekad nav publicēts.

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

Sekojiet arī pāradresācijām, jo atsauce, kas sākas ar HTTPS, tomēr var nonākt vienkārša teksta piegādes ceļā. Ja atkarībai vienkārši nav drošas piegādes, noņemiet vai aizstājiet to parastajā izmaiņu procesā, nevis piegādājiet apiešanas risinājumu. Lietotājam atstājiet pārlūka aizsardzības ieslēgtas un ziņojiet vietnes īpašniekam resursa URL, tā veidu un konsoles ziņojumu. Nekad neizplatiet norādes, kas liek darbiniekiem atļaut nedrošu saturu vienai lapai, jo šis izņēmums pārdzīvo incidentu, kas to izraisīja.

Vēlreiz pārbaudiet lapu tā, kā lietotāji to aizskar

Praktizējiet darbības, kas ielādē resursus pēc pieprasījuma, ne tikai pirmo dokumentu. Lapas pēc pogas nospiešanas ielādē papildu kodu, datus un lejupielādes, un šie pieprasījumi bieži ir nedrošie. Apstipriniet konkrētos pieprasījumus un redzamo uzvedību, kamēr aizsardzība vēl ir ieslēgta. Tests, kas sākas ar atslābinātu pārlūka profilu, nevar parādīt, ko redz parasts lietotājs.

Tunelim joprojām ir savs darbs, un šis darbs ir tīkla piekļuve, nevis lapas integritāte.

Kad trafiks atstāj tuneļa galapunktu, neviens atlikušais HTTP pieprasījums nav ieguvis neko no pārvadātāja. Izlabojiet resursa ceļu un saglabājiet pārlūka izpildi savā vietā. Vēl viena transporta slāņa uzskatīšana par nedrošas atkarības labojumu ir ceļš, kā komanda nonāk pie palīdzības dienesta skripta, kas izslēdz kontroli, kura strādāja pareizi.