En HTTPS-sida som laddar skript över HTTP gör två förfrågningar med två olika skyddsnivåer, och hänglåset beskriver bara den första. En tunnel ändrar inte detta, eftersom den skyddar transportören och inte resursens eget schema. Webbläsaren berättar redan vilken förfrågan som misslyckades, om du läser konsolen i stället för adressfältet. Tre kontroller tar dig från en delvis fungerande sida till en faktisk reparation.

Läs förfrågan, inte adressfältet

Ett dokument hämtat över HTTPS kan referera till ett skript, en stilmall, ett typsnitt eller en ram över vanlig HTTP. Den referensen är en egen förfrågan, och det är den webbläsaren klagar på. Huvuddokumentets skydd färdas inte tillbaka in i den, och tunneln som bär båda strömmarna ändrar inget av schemana. Sidan kan därför vara både verkligt säker och verkligt trasig samtidigt.

Att kalla resursen bara en inkluderad fil gör inte utbytet av den ofarligt.

Om osäkert skriptinnehåll kan ändras på vägen och sedan köras, kan det ändra hur sidan beter sig, vilket är ett större problem än ett kosmetiskt fel. Bilder bär en mindre men verklig risk när de ändras på vägen. Hänglåset ljuger inte om någonting. Det svarar på en snävare fråga än den du ställde till det.

Vet vilka resurser som blockeras och vilka som uppgraderas

Webbläsare behandlar inte alla typer av resurser likadant. vägledningen om blandat innehåll skiljer förfrågningar som uppgraderas till HTTPS från förfrågningar som blockeras helt, där skript, stilmallar och programmatiska förfrågningar finns på den blockerade sidan, medan bilder och medier i stället kan uppgraderas eller markeras.

Skillnaden förklarar de förvirrande rapporterna. En sida med ett blockerat skript förlorar en funktion helt, medan en sida med en uppgraderad bild ser bra ut och tyst har ändrat sin förfrågan. De dokumenterade kategorierna har också undantag, så utgå inte från att varje URL av en viss typ uppgraderas framgångsrikt. Läs vad konsolen säger om den specifika förfrågan i stället för att resonera utifrån en filändelse.

En blockerad widget är inte bevis på att tunneln misslyckades. Det är bevis på att webbläsaren gjorde sitt jobb.

Reparera referensen vid källan

För en ägare av en webbplats hör reparationen hemma där den osäkra URL:en skrevs: en mall, en stilmall, ett skript som sätter ihop URL:er eller en tredjepartskomponent. Att ändra den synliga sidadressen lämnar allt detta orört. Sök i källan efter värden och reparera varje referens, inte bara den enda som konsolen råkade nämna.

Bekräfta sedan att resursen verkligen levereras över HTTPS med giltig identitet, eftersom ett schemabyte inte kan trolla fram en tjänst som aldrig publicerades där.

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

Följ också omdirigeringar, eftersom en referens som börjar med HTTPS fortfarande kan hamna på en leveransväg med klartext. När ett beroende helt enkelt inte har säker leverans, ta bort eller ersätt det genom den vanliga ändringsprocessen i stället för att leverera en kringgång. För en användare, låt webbläsarens skydd vara på och rapportera resursens URL, dess typ och konsolmeddelandet till webbplatsens ägare. Sprid aldrig instruktioner som ber personalen tillåta osäkert innehåll för en sida, eftersom det undantaget överlever incidenten som utlöste det.

Testa sidan igen så som användarna rör vid den

Öva de operationer som laddar resurser vid behov, inte bara det första dokumentet. Sidor hämtar extra kod, data och nedladdningar efter ett knapptryck, och de förfrågningarna är ofta de osäkra. Bekräfta de specifika förfrågningarna och det synliga beteendet med skyddet fortfarande på. Ett test som börjar med en uppmjukad webbläsarprofil kan inte visa dig vad en vanlig användare ser.

Tunneln har fortfarande sitt eget jobb, och det jobbet är nätverksåtkomst och inte sidintegritet.

När trafiken lämnar tunnelns ändpunkt har varje kvarvarande HTTP-hämtning inte vunnit något från transportören. Reparera resursvägen och behåll genomdrivandet i webbläsaren. Att behandla ännu ett transportlager som en reparation av ett osäkert beroende är hur ett team till slut har ett helpdesk-skript som stänger av kontrollen som fungerade korrekt.

Relaterade artiklar