Halve siden rendres, ett stilark står grået ut i nettverkspanelet, og VPN-klienten rapporterer fortsatt en sunn tunnel. Alle tre observasjonene er sanne samtidig, fordi nettleseren vurderte en forespørsel siden gjorde, og tunnelen hadde ingen stemme i den vurderingen. Det som lukker saken er en beslutning og ikke en innstilling: reparer referansen, eskaler den til den som eier verten, eller slipp avhengigheten. Hvert av disse alternativene har en billig test, og å velge feil koster en støtterunde.

Hvorfor tunnelen ikke kan dekke en underressurs

Blandet innhold begynner med et HTTPS-dokument som ber om en underressurs over vanlig HTTP. Hver adresse vurderes etter sitt eget skjema, så beskyttelsen til det overordnede dokumentet strekker seg aldri til en underordnet forespørsel. Kryptering som legges til under nettleseren endrer hva som går over linjen, ikke det http:// som markupen ba om.

Dagens nettlesere sorterer disse forespørslene i to grupper og behandler dem ulikt. Skript, stilark, iframes og kall via fetch, XMLHttpRequest eller WebSocket avvises blankt, uten et oppgraderingsforsøk først. Bilder, lyd og video skrives om til https:// og forespørres på nytt, og innlastingen avbrytes når den sikre hentingen mislykkes. En underressursadresse der verten er en bar IP-adresse er unntatt fra oppgradering, så et HTTP-bilde på en IP-vert forblir blokkert i stedet for å bli stille reparert. Splittingen, inkludert det unntaket på den oppgraderbare siden, er dokumentert i Mozillas veiledning om blandet innhold. Chrome bruker en lignende avvisning på usikre nedlastinger som startes fra en sikker side, og det er derfor en PDF-lenke kan dø mens den omkringliggende siden ser intakt ut.

Den gråete raden er altså beviset på at kontrollen virker, ikke beviset på at tunnelen lakk klartekst. Behandle raden som et funn som peker på én referanse og ikke på hele siden.

Avgjør hvem som eier den usikre referansen

Sorter den anstøtelige adressen etter hvor den oppstår før du redigerer noe. Det svaret avgjør om du kan sende ut en rettelse i dag, om en leverandør må gi ut en, eller om avhengigheten må forlate siden. Les det i kolonnen Initiator i nettverkspanelet, fordi markupen på skjermen ofte settes sammen ved kjøring.

Hvor adressen kommer fraHvem som kan rette denFørste steg
Hardkodet i en mal eller del som du sender utDuErstatt den med https://-formen og tøm deretter hurtiglageret
Injisert av en taggbehandler eller en leverandørpakkeLeverandøren, med din sakSend den nøyaktige adressen, forespørselstypen og konsollinjen
Kun servert på port 80 uten TLS-lytterEieren av vertenBe om TLS, sett noe eget foran, eller slipp den

Når verten allerede svarer på 443 og bare referansen sier http, er reparasjonen lokal: endre referansen, tøm sidehurtiglageret og bekreft at raden blir https. En vert som bare lytter på port 80 kan ikke redigeres til å oppfylle kravet, så ressursen flytter, får noe foran som du kontrollerer, eller forsvinner. En adresse som injiseres av en taggbehandler dukker fortsatt opp, selv når din egen mal er ren, og det tilfellet hører hjemme i en sak med den nøyaktige adressen og konsollinjen vedlagt. Å fortelle personalet at de skal tillate usikkert innhold er ikke ett av disse alternativene, fordi det slår av kontrollen for hvert nettsted den nettleserprofilen besøker.

Reparer referansen i stedet for nettleserinnstillingen

Last inn den feilende flyten på nytt med nettverksloggen bevart og filtrer panelet på verten du mistenker. Konsollen navngir adressen og direktivet, noe som avgjør om en forespørsel ble avvist eller oppgradert før du rører en mal.

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

To støttende kontroller er verdt å kjenne, og ingen av dem erstatter reparasjonen. En Content-Security-Policy-header med upgrade-insecure-requests får nettleseren til å skrive om http-underressursadresser før de forlater siden, noe som fanger gamle referanser du ennå ikke har funnet. Den omskrevne forespørselen mislykkes fortsatt når målverten ikke tilbyr HTTPS, så headeren endrer bare hvilken adresse nettleseren prøver. HSTS virker per vert, noe som betyr at en policy på ditt eget domene ikke gjør noe for et CDN fra tredjepart som aldri sendte headeren. Etter en malendring tømmer du sidehurtiglageret og søker i den rendrede HTML-en etter det gamle vertsnavnet, fordi den samme adressen også kan komme via en del, en oversettelsesstreng eller et databasefelt.

Følg også omdirigeringer, fordi en kjede som starter på https:// kan lande på en http://-plassering og nettleseren vurderer det siste hoppet. Den -L formen av den andre kommandoen ovenfor skriver ut den effektive adressen for deg. Hvis det siste hoppet er ren http, er referansen fortsatt feil, selv om lenken du redigerte så fin ut.

Bekreft siden med konsollen og nettverkspanelet

Last inn på nytt med hurtiglageret deaktivert og gå gjennom flyten igjen, inkludert knappene som laster innhold ved behov. En første sideinnlasting skjuler late widgeter, kartfliser og spillerskript som først dukker opp etter et klikk. Konsollen bør ikke ha noen poster om blandet innhold, og hver rad du rørte bør vise https. Ta vare på konsollen og forespørselsraden før du lukker saken, fordi den tilstanden er vanskelig å gjenskape etter neste utrulling.

Når ressursen tilhører noen andre, sender du fire ting: den nøyaktige adressen, forespørselstypen, konsollteksten og siden der den vises. Sladd sesjonsidentifikatorer i alt du limer inn i en sak. En rapport som bare sier at bilder er ødelagt gir eieren ingenting å søke etter.

Tunnelen gjør fortsatt sin egen jobb mens rettelsen ligger i referansen som laget forespørselen. Søk i malen og leverandørpakken etter vertsnavnet én gang til etter utrullingen, og lukk saken først når ingen blokkert post om blandet innhold er igjen i konsollen.

Relaterte artikler