HTTP-nedgradering og risici ved mixed content

HTTP Strict Transport Security (HSTS)-headeren instruerer browsere i kun at oprette forbindelse til et websted via HTTPS i en angivet periode. Når browseren har modtaget headeren, afviser den HTTP-forbindelser og opgraderer automatisk URL'er fra http:// til https://.

En typisk HSTS-header er: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". max-age er angivet i sekunder (31536000 = 1 år). Når den er gemt i cachen, håndhæver browseren HTTPS i ét år uden involvering fra nogen server.

Parameteren max-age angiver, hvor længe browseren skal håndhæve forbindelser, der kun bruger HTTPS, i sekunder. På produktionswebsteder anbefales værdier på mindst ét år (31536000).

Direktivet includeSubDomains udvider HSTS-håndhævelsen til alle underdomæner. Det forhindrer angreb, hvor en angriber nedgraderer en underdomæneforbindelse til HTTP og bruger den til at stjæle cookies, der er angivet uden Secure-flaget på hoveddomænet.

Browsere leveres med en hårdkodet liste over domæner, der altid kun bruger HTTPS, også ved det allerførste besøg. Listen vedligeholdes på hstspreload.org og omfatter tusindvis af større websteder.

Preloading fjerner sårbarheden ved det første besøg: Uden preloading kunne en førstegangsbesøgende blive aflyttet, før HSTS-headeren blev modtaget. Websteder på preload-listen bruger kun HTTPS fra den allerførste anmodning, uanset HSTS-cachetilstanden.

SSL-stripping, som blev offentliggjort af Moxie Marlinspike på Black Hat i 2009, er et MITM-angreb, der nedgraderer HTTPS-forbindelser til HTTP. Angriberen opfanger brugerens første HTTP-anmodning, sender HTTPS-anmodninger til den rigtige server på brugerens vegne og videresender indholdet til brugeren over HTTP.

Offeret ser indholdet som normalt, men over HTTP. Alle legitimationsoplysninger, der indtastes, sendes til angriberen. Før HSTS var dette angreb meget effektivt, fordi brugerne ikke lagde mærke til den manglende hængelås.

HSTS stopper SSL-stripping, fordi browseren nægter at fortsætte med HTTP-forbindelser til domæner, der er tilmeldt HSTS. Selv hvis en angriber forsøger at levere en side over HTTP, nægter browseren ganske enkelt at oprette forbindelse og viser en fejl.

Browserens HSTS-håndhævelse sker, før nogen netværksanmodning sendes, så angriberen kan ikke blande sig. Den eneste resterende sårbarhed er det første besøg, før HSTS er modtaget, og den fjernes med preloading.

Blandet indhold opstår, når en HTTPS-side indlæser ressourcer over HTTP. Passivt blandet indhold omfatter billeder, lyd og video, der indlæses over HTTP. Det kan ikke ændre siden direkte, men kan afsløre brugeroplysninger via HTTP-headere og muliggøre sporing.

Aktivt blandet indhold omfatter scripts, typografiark, iframes og XMLHttpRequests, der indlæses over HTTP. Et HTTP-script kan kompromittere HTTPS-sidens sikkerhed fuldstændigt, fordi det har fuld adgang til DOM'en og kan læse cookies og formulardata.

Moderne browsere blokerer som standard aktivt blandet indhold (scripts, typografiark og iframes over HTTP), når den omsluttende side bruger HTTPS. Der vises en fejl i konsollen, og ressourcen indlæses ikke.

Fra og med Chrome 81 (2020) begyndte browsere automatisk at opgradere passivt blandet indhold til HTTPS. Hvis HTTPS-versionen findes, indlæses den. Hvis ikke, blokeres ressourcen.

Browserens udviklerkonsol viser advarsler og fejl om blandet indhold. I Chrome skal du åbne DevTools, gå til fanen Console og filtrere efter "Blandet indhold". For hver blokeret ressource vises den usikre URL, der skal opdateres.

Sikkerhedspanelet i DevTools viser et omfattende sikkerhedsoverblik: certifikatoplysninger, forbindelsesoplysninger og en liste over alle usikre ressourcer på siden.

Content Security Policy (CSP)-direktivet "upgrade-insecure-requests" instruerer browsere i automatisk at opgradere alle HTTP-anmodninger fra siden til HTTPS. Det håndterer ældre indhold med hårdkodede HTTP-URL'er.

I modsætning til blokering af blandet indhold forsøger upgrade-insecure-requests først at hente HTTPS-versionen. Det er nyttigt under overgangen fra HTTP til HTTPS, når det ville være upraktisk at opdatere alle indlejrede URL'er i ældre indhold.

Uden HTTPS kan internetudbydere (ISP'er) indsætte indhold i HTTP-svar. Flere internetudbydere er blevet taget i at indsætte reklamer på websteder, der ikke havde reklamer, tilføje sporingspixels eller indsætte advarselssider, når brugerne nærmer sig deres datagrænse.

Denne form for indholdsindsprøjtning er umulig på HTTPS-sider, fordi svaret er godkendt og krypteret. Enhver ændring ville få TLS-MAC-verifikationen til at mislykkes, hvilket ville resultere i en forbindelsesfejl i stedet for at levere ændret indhold.

Før en browser har set en HSTS-header for et domæne, er det allerførste besøg over HTTP sårbart. En angriber kan opfange denne første anmodning og udføre SSL-stripping uden at udløse browseradvarsler.

Denne sårbarhed ved "tillid ved første brug" er årsagen til, at HSTS-preload-listen findes. Hvis et websted indsendes til preload-listen, håndhæver browsere HTTPS for domænet fra den allerførste anmodning, så vinduet ved det første besøg lukkes helt.

HSTS instruerer browsere i at håndhæve forbindelser, der kun bruger HTTPS, for et domæne i en angivet periode. Preload-listen udvider beskyttelsen til de allerførste besøg ved at indbygge HSTS-politikker i browsere.

SSL-stripping (Moxie Marlinspike, 2009) nedgraderer HTTPS til HTTP, men HSTS stopper det. Aktivt blandet indhold (HTTP-scripts på HTTPS-sider) blokeres af browsere. CSP-direktivet upgrade-insecure-requests automatiserer overgangen fra HTTP til HTTPS for ældre indhold.