Puolet sivusta renderöityy, yksi tyylitiedosto seisoo harmaana Verkko-paneelissa ja VPN-asiakas raportoi edelleen terveestä tunnelista. Kaikki kolme havaintoa ovat totta samaan aikaan, koska selain arvioi sivun tekemän pyynnön eikä tunnelilla ollut ääntä siinä arviossa. Asian sulkee päätös, ei asetus: korjaa viittaus, eskaloi se isännän omistajalle tai luovu riippuvuudesta. Jokaisella näistä vaihtoehdoista on halpa testi, ja väärän valitseminen maksaa yhden tukikierroksen.

Miksi tunneli ei voi kattaa aliresurssia

Sekasisältö alkaa HTTPS-dokumentista, joka pyytää aliresurssia tavallisella HTTP:llä. Jokainen URL arvioidaan oman skeemansa mukaan, joten ylätason asiakirjan suoja ei koskaan ulotu alitason pyyntöön. Selainta alemman tason lisätty salaus muuttaa sitä, mikä kulkee johdolla, ei sitä http://-osoitetta, jota merkintä pyysi.

Nykyiset selaimet jakavat nämä pyynnöt kahteen ryhmään ja kohtelevat niitä eri tavoin. Skriptit, tyylitiedostot, iframe-kehykset ja kutsut fetchin, XMLHttpRequestin tai WebSocketin kautta hylätään heti ilman ennakkoon tehtyä päivitysyritystä. Kuvat, ääni ja video kirjoitetaan uudelleen https://-muotoon ja pyydetään uudelleen, ja lataus keskeytetään, kun se suojattu haku epäonnistuu. Aliresurssin URL, jonka isäntä on paljas IP-osoite, on vapautettu päivityksestä, joten HTTP-kuva IP-isännässä pysyy estettynä sen sijaan, että se korjattaisiin hiljaisesti. Jako, mukaan lukien kyseinen poikkeus päivitettävällä puolella, on dokumentoitu Mozillan sekasisältöoppaassa. Chrome soveltaa vastaavaa hylkäystä suojatulta sivulta aloitetuille suojaamattomille latauksille, minkä vuoksi PDF-linkki voi kuolla, kun ympäröivä sivu näyttää ehjältä.

Harmaa rivi on siis todiste siitä, että valvonta toimii, ei todiste siitä, että tunneli päästi selkokielistä tekstiä läpi. Käsittele riviä löytönä, joka osoittaa yhteen viittaukseen eikä koko sivuun.

Selvitä, kuka suojaamattoman viittauksen omistaa

Järjestä ongelmallinen URL sen mukaan, missä se syntyy, ennen kuin muutat mitään. Se vastaus ratkaisee, voitko julkaista korjauksen tänään, täytyykö toimittajan julkaista yksi vai täytyykö riippuvuuden poistua sivulta. Lue se Verkko-paneelin Initiator-sarakkeesta, koska näytön merkintä kootaan usein suorituksen aikana.

Mistä URL tuleeKuka voi korjata senEnsimmäinen askel
Kovakoodattu malliin tai osaan, jonka otat käyttöönSinäKorvaa se https://-muodolla ja tyhjennä sitten välimuisti
Tunnisteenhallinnan tai toimittajan nipun lisäämäToimittaja, lipukkeesi kanssaLähetä tarkka URL, pyynnön tyyppi ja konsolirivi
Tarjoillaan vain portissa 80 ilman TLS-kuuntelijaaIsännän omistajaPyydä TLS, aseta eteen jotain omaa tai luovu siitä

Kun isäntä vastaa jo portissa 443 ja vain viittaus sanoo http, korjaus on paikallinen: muuta viittausta, tyhjennä sivun välimuisti ja vahvista, että rivistä tulee https. Isäntää, joka kuuntelee vain portissa 80, ei voi saada vaatimusten mukaiseksi muokkaamalla, joten resurssi siirtyy, sen eteen asetetaan jotain, mitä hallitset, tai se katoaa. Tunnisteenhallinnan lisäämä URL ilmestyy edelleen, vaikka oma mallisi olisi puhdas, ja se tapaus kuuluu lipukkeeseen, johon on liitetty tarkka URL ja konsolirivi. Henkilöstölle sanominen, että he sallivat suojaamattoman sisällön, ei ole mikään näistä vaihtoehdoista, koska se kytkee tarkistuksen pois päältä jokaiselta sivustolta, jolla se selainprofiili vierailee.

Korjaa viittaus eikä selaimen asetusta

Lataa epäonnistuva kulku uudelleen verkko-loki säilyttäen ja suodata paneeli epäilyttävän isännän mukaan. Konsoli nimeää URL:n ja direktiivin, mikä ratkaisee, hylättiinkö pyyntö vai päivitettiinkö se, ennen kuin kosket mallia.

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

Kaksi tukevaa valvontaa kannattaa tuntea, eikä kumpikaan korvaa korjausta. Content-Security-Policy-otsake, jossa on upgrade-insecure-requests saa selaimen kirjoittamaan http-aliresurssien URL:t uudelleen ennen kuin ne lähtevät sivulta, mikä nappaa vanhoja viittauksia, joita et ole vielä löytänyt. Uudelleen kirjoitettu pyyntö epäonnistuu silti, kun kohdeisäntä ei tarjoa HTTPS:ää, joten otsake muuttaa vain sitä, mitä URL:ää selain yrittää. HSTS toimii isäntäkohtaisesti, mikä tarkoittaa, että oman verkkotunnuksesi käytäntö ei tee mitään kolmannen osapuolen CDN:lle, joka ei koskaan lähettänyt otsaketta. Mallin muutoksen jälkeen tyhjennä sivun välimuisti ja etsi renderöidystä HTML:stä vanha isäntänimi, koska sama URL voi tulla myös osan, käännöstehtävän tai tietokantakentän kautta.

Seuraa myös uudelleenohjauksia, koska https://-osoitteesta alkava ketju voi päätyä http://-sijaintiin ja selain arvioi viimeisen hypyn. Toisen komennon -L muoto tulostaa sen tehokkaan URL:n puolestasi. Jos viimeinen hyppy on puhdasta http:tä, viittaus on edelleen väärä, vaikka muokkaamasi linkki näytti hyvältä.

Vahvista sivu konsolilla ja verkkopaneelilla

Lataa uudelleen välimuisti poissa käytöstä ja käy kulku läpi uudelleen, mukaan lukien painikkeet, jotka lataavat sisältöä pyynnöstä. Sivun ensimmäinen lataus piilottaa laiskat widgetit, karttalaatat ja soittimen skriptit, jotka ilmestyvät vasta napsautuksen jälkeen. Konsolissa ei pitäisi olla sekasisältömerkintöjä ja jokaisen koskemasi rivin pitäisi näyttää https. Tallenna konsoli ja pyyntörivi ennen lipukkeen sulkemista, koska sitä tilaa on vaikea rakentaa uudelleen seuraavan käyttöönoton jälkeen.

Kun resurssi kuuluu jollekin muulle, lähetä neljä asiaa: tarkka URL, pyynnön tyyppi, konsolin teksti ja sivu, jolla se näkyy. Peitä istunnon tunnisteet kaikesta, mitä liität lipukkeeseen. Raportti, joka vain sanoo, että kuvat ovat rikki, ei anna omistajalle mitään etsittävää.

Tunneli jatkaa omaa työtään, kun korjaus on viittauksessa, joka tuotti pyynnön. Etsi isäntänimi vielä kerran mallista ja toimittajan nipusta käyttöönoton jälkeen ja sulje asia vasta, kun konsoliin ei jää yhtään estettyä sekasisältömerkintää.

Aiheeseen liittyvät artikkelit