HTTP-sikkerhedsheadere: CSP og HSTS

Du implementerede applikationen. Siderne indlæses, formularerne virker, og intet ser ødelagt ud. Så kører du en scanning, og den kommer tilbage med en liste over fund vedr overskrifter - og intet af det er indlysende.

Det er en normal første reaktion. Overskrifter vises ikke på skærmen, så det er svært at sige, om de betyder noget, eller om scanneren bare er kræsen. Denne guide gennemgår de overskrifter, du oftest vil se, hvad hver enkelt faktisk gør i almindeligt sprog, og hvordan du tjekker dine uden at gætte.

Sikkerhedsheaders er instruktioner, som din server sender til browseren ved siden af siden. Browseren læser dem og justerer, hvordan den håndterer dit indhold: hvilke scripts der må køre, om siden kan indlæses over almindelig HTTP, om et andet websted kan indlejre det i en ramme.

Intet på siden ændres. Det er præcis derfor, at disse resultater føles abstrakte - siden kan se ud og opføre sig perfekt, mens den mangler et sæt beskyttelser, der ville have betydning, den dag noget går galt.

Den ærlige indramning er denne: overskrifter reducerer en bestemt risikoklasse. De gør ikke et websted sikkert på egen hånd, og et rent header-tjek beviser ikke, at et websted er fuldt sikkert. Tænk på dem som ét lag blandt flere og et af de billigste lag at få rigtigt.

Når en browser anmoder om en side, svarer din server med siden og en blok af metadata kaldet responsheaders. Du kan selv se dem: Åbn din browsers udviklerværktøjer, gå til fanen Netværk, genindlæs siden, og klik på den øverste anmodning. Overskrifterne er lige der.

Sikkerhedsheaders er simpelthen dem, der fortæller browseren at håndhæve en regel. Nogle er strenge, nogle er rådgivende, og alle er sat i din serverkonfiguration, dit framework eller din hostingplatform - ikke i din HTML.

CSP fortæller browseren, hvilke indholdskilder der må indlæses på din side. Det er den mest kraftfulde header her og den, folk finder mest skræmmende.

I praksis staver en CSP ting som: scripts må kun komme fra dit eget domæne og et betroet CDN; billeder kan komme fra hvor som helst over HTTPS; siden er muligvis ikke indrammet af et andet websted. Hvis noget forsøger at indlæse fra en kilde, du ikke har tilladt, blokerer browseren det og logger forsøget i konsollen.

CSP er et ekstra forsvar mod script-injektion sammen med sikker output-kodning og desinficering. Det er også den header, der med størst sandsynlighed knækker noget, hvis du indstiller den for aggressivt. Den praktiske vej for en nybegynder er at starte i kun rapporttilstand, se, hvad der ville være blevet blokeret, rette de reelle problemer og derefter håndhæve det.

HSTS fortæller browseren, at den kun skal tale med dit websted via HTTPS i en bestemt periode. Når først en browser har set denne overskrift, vil den nægte at oprette en usikker HTTP-forbindelse til dit domæne - også selvom en bruger indtaster http:// eller følger et gammelt link.

Når browseren kender HSTS-politikken, opgraderer den HTTP-anmodninger, før den sender dem. Det første besøg kan stadig bruge HTTP, medmindre domænet allerede er dækket af en HSTS preload-indgang.

Den ene ting at respektere her er engagement. HSTS huskes af browseren, så længe du angiver, så start med en kort varighed, mens du bekræfter, at hvert underdomæne fungerer over HTTPS, og forlænge det, når du er sikker.

X-Frame-Options kontrollerer, om et andet websted kan indlæse dine sider inde i en ramme - en <iframe> på en andens side.

Hvorfor bekymre sig? Fordi framing er mekanismen bag clickjacking, hvor en angriber overlejrer din rigtige side med usynlige eller forklædte elementer, så en bruger klikker på noget, de ikke mente. Hvis din app har en handling, der er logget ind - en slet-knap, en betaling, en indstillingsændring - er det en risiko, at du ikke ønsker at ramme den et andet sted.

Den fælles indstilling er SAMEORIGIN, som tillader dine egne sider at ramme hinanden, men blokerer for alle andre. Hvis du aldrig har til hensigt at blive indrammet, er det normalt den rigtige standard.

Referrer-Policy bestemmer, hvor meget af din URL der deles med andre websteder, når en bruger klikker på et link væk fra din side. Moderne browsere bruger normalt strict-origin-when-cross-origin: den fulde URL kan sendes på anmodninger med samme oprindelse, mens HTTPS-anmodninger med krydsoprindelse kun modtager oprindelsen. En eksplicit svagere politik kan afsløre mere.

Det er vigtigt, fordi fulde URL'er nogle gange indeholder følsomme værdier i forespørgselsstrenge - tokens, id'er, e-mailadresser, søgetermer. At lække dem til en tredjepart er stille og let at gå glip af.

En fornuftig baseline er kun at sende oprindelsen, eller slet intet, på anmodninger på tværs af websteder. Det koster dig næsten ingenting og fjerner et utilsigtet datalæk.

Et par flere overskrifter dukker op ofte nok til at kende ved navn:

• X-Content-Type-Options: nosniff forhindrer browseren i at gætte en filtype, som ellers kan gøre en uploadet fil til et eksekverbart script.

• Permissions-Policy deaktiverer browserfunktioner, du ikke bruger, såsom kamera, mikrofon eller geoplacering.

• Cross-Origin-Opener-Policy og relaterede cross-origin headers isolerer din side fra andre, hvilket hjælper med at indeholde visse angreb.

Du behøver ikke dem alle på dag ét. At vide, hvad de gør, hjælper dig med at læse en scanningsrapport uden at gå i panik.

Du har to måder at se på.

Først den manuelle rute: udviklerværktøjer, fanen Netværk, klik på sideanmodningen og læs svaroverskrifterne. Dette er nyttigt til at bekræfte, at en enkelt overskrift er til stede og indstille den måde, du forventer.

For det andet, den praktiske rute for mere end én side: kør en scanning. En scanner henter dit websted, som en browser ville gøre, og rapporterer, hvilke sikkerhedsheadere der er til stede, hvilke der mangler, og hvad hvert hul afslører. Det giver dig en prioriteret liste i stedet for en mur af rå tekst - og det tjekker de sider, du ikke ville have troet at åbne manuelt.

Et generelt værktøj som VICE's gratis letvægtssikkerhedsscanning vil markere header-fund sammen med andre problemer med beviserne bag hver enkelt, så du kan se, hvorfor den blev rejst.

Headere lever i konfigurationen, så de fleste rettelser er små: Tilføj en linje til din serverkonfiguration, en indstilling i dit framework eller en mulighed i din værts dashboard. Skift én overskrift ad gangen, og bekræft, at webstedet stadig fungerer.

Scan derefter igen. Dette er det trin, folk springer over. At redigere en konfiguration betyder ikke, at overskriften nu er korrekt på hver side, og at markere noget som fast i et dashboard er ikke det samme som at bekræfte det. Kun en ny scanning over samme omfang fortæller dig, at ændringen faktisk trådte i kraft.

Start med en gratis scanning, se på, hvad dine overskrifter virkelig laver, og ret de vigtigste resultater én ad gangen. Det er et rimeligt førstepas - og en meget bedre position end at håbe på, at standardindstillingerne var fine.