HTTP-sikkerhetshoder: CSP og HSTS

Du implementerte applikasjonen. Sidene lastes inn, skjemaene fungerer, og ingenting ser ødelagt ut. Deretter kjører du en skanning og den kommer tilbake med en liste over funn om overskrifter - og ingenting av det er åpenbart.

Det er en normal første reaksjon. Overskrifter vises ikke på skjermen, så det er vanskelig å si om de betyr noe eller om skanneren bare er masete. Denne guiden går gjennom overskriftene du vil se oftest, hva hver enkelt faktisk gjør på vanlig språk, og hvordan du sjekker dine uten gjetting.

Sikkerhetsoverskrifter er instruksjoner som serveren sender til nettleseren ved siden av siden. Nettleseren leser dem og justerer hvordan den håndterer innholdet ditt: hvilke skript som kan kjøres, om siden kan lastes over vanlig HTTP, om et annet nettsted kan bygge det inn i en ramme.

Ingenting på siden endres. Det er nettopp derfor disse funnene føles abstrakte - nettstedet kan se ut og oppføre seg perfekt mens det mangler et sett med beskyttelser som vil ha betydning den dagen noe går galt.

Den ærlige innrammingen er denne: overskrifter reduserer en bestemt risikoklasse. De gjør ikke et nettsted sikkert på egen hånd, og en ren overskriftssjekk beviser ikke at et nettsted er helt sikkert. Tenk på dem som ett lag blant flere, og et av de billigste lagene å få riktig.

Når en nettleser ber om en side, svarer serveren din med siden og en blokk med metadata kalt responsoverskrifter. Du kan se dem selv: åpne nettleserens utviklerverktøy, gå til fanen Nettverk, last inn siden på nytt og klikk på den øverste forespørselen. Overskriftene er der.

Sikkerhetsoverskrifter er ganske enkelt de som forteller nettleseren å håndheve en regel. Noen er strenge, noen er rådgivende, og alle er satt i serverkonfigurasjonen, rammeverket eller vertsplattformen - ikke i HTML-en.

CSP forteller nettleseren hvilke innholdskilder som har lov til å laste inn på siden din. Det er den kraftigste headeren her og den som folk synes er mest skremmende.

I praksis staver en CSP ut ting som: skript kan bare komme fra ditt eget domene og en pålitelig CDN; bilder kan komme fra hvor som helst over HTTPS; siden kan ikke være innrammet av et annet nettsted. Hvis noe prøver å laste fra en kilde du ikke tillot, blokkerer nettleseren det og logger forsøket i konsollen.

CSP er et ekstra forsvar mot skriptinjeksjon, sammen med sikker utdatakoding og rensing. Det er også headeren som mest sannsynlig bryter noe hvis du setter den for aggressivt. Den praktiske veien for en nybegynner er å starte i bare rapportmodus, se hva som ville blitt blokkert, fikse de virkelige problemene og deretter håndheve det.

HSTS ber nettleseren om å bare snakke med nettstedet ditt over HTTPS, i en definert periode. Når en nettleser har sett denne overskriften, vil den nekte å opprette en usikker HTTP-tilkobling til domenet ditt - selv om en bruker skriver http:// eller følger en gammel lenke.

Når nettleseren kjenner HSTS-policyen, oppgraderer den HTTP-forespørsler før de sendes. Det første besøket kan fortsatt bruke HTTP med mindre domenet allerede er dekket av en HSTS forhåndsinnlasting.

Den ene tingen å respektere her er engasjement. HSTS huskes av nettleseren så lenge du spesifiserer, så start med en kort varighet mens du bekrefter at hvert underdomene fungerer over HTTPS, og forleng det så snart du er sikker.

X-Frame-Options kontrollerer om et annet nettsted kan laste inn sidene dine i en ramme - en <iframe> på en annens side.

Hvorfor bry seg? Fordi innramming er mekanismen bak clickjacking, der en angriper overlegger den virkelige siden din med usynlige eller forkledde elementer slik at en bruker klikker noe de ikke mente. Hvis appen din har en pålogget handling - en sletteknapp, en betaling, en endring av innstillinger - er det en risiko du ikke ønsker å ramme den andre steder.

Den vanlige innstillingen er SAMEORIGIN, som lar dine egne sider ramme inn hverandre, men blokkerer alle andre. Hvis du aldri har tenkt å bli innrammet, er det vanligvis riktig standard.

Referrer-Policy bestemmer hvor mye av URL-en din som deles med andre nettsteder når en bruker klikker på en kobling bort fra siden din. Moderne nettlesere bruker normalt strict-origin-when-cross-origin: hele URL-en kan sendes på forespørsler med samme opprinnelse, mens HTTPS-forespørsler med kryssopprinnelse bare mottar opprinnelsen. En eksplisitt svakere politikk kan avsløre mer.

Det er viktig fordi fullstendige nettadresser noen ganger inneholder sensitive verdier i søkestrenger - tokens, ID-er, e-postadresser, søkeord. Å lekke dem til en tredjepart er stille og lett å gå glipp av.

En fornuftig grunnlinje er å sende bare opprinnelsen, eller ingenting i det hele tatt, på forespørsler på tvers av nettsteder. Det koster deg nesten ingenting og fjerner en utilsiktet datalekkasje.

Noen flere overskrifter dukker opp ofte nok til å vite etter navn:

• X-Content-Type-Options: nosniff stopper nettleseren fra å gjette en filtype, som ellers kan gjøre en opplastet fil til et kjørbart skript.

• Permissions-Policy slår av nettleserfunksjoner du ikke bruker, for eksempel kamera, mikrofon eller geolokalisering.

• Cross-Origin-Opener-Policy og relaterte overskrifter med kryssopprinnelse isolerer siden din fra andre, noe som bidrar til å inneholde visse angrep.

Du trenger ikke alle på dag én. Å vite hva de gjør hjelper deg å lese en skannerapport uten å få panikk.

Du har to måter å se på.

Først den manuelle ruten: utviklerverktøy, fanen Nettverk, klikk på sideforespørselen og les svarhodene. Dette er nyttig for å bekrefte at en enkelt overskrift er tilstede og angi slik du forventer.

For det andre, den praktiske ruten for mer enn én side: kjør en skanning. En skanner henter nettstedet ditt slik en nettleser ville gjort, og rapporterer hvilke sikkerhetshoder som finnes, hvilke som mangler og hva hvert gap avslører. Det gir deg en prioritert liste i stedet for en vegg med rå tekst - og det sjekker sidene du ikke ville ha tenkt å åpne manuelt.

Et generellt verktøy som VICEs gratis lette sikkerhetsskanning vil flagge overskriftsfunn sammen med andre problemer, med bevisene bak hvert enkelt slik at du kan se hvorfor det ble reist.

Overskrifter lever i konfigurasjon, så de fleste rettelser er små: legg til en linje i serverkonfigurasjonen din, en innstilling i rammeverket ditt eller et alternativ i vertens dashbord. Endre én overskrift om gangen og bekreft at nettstedet fortsatt fungerer.

Skann deretter på nytt. Dette er trinnet folk hopper over. Å redigere en konfigurasjon betyr ikke at overskriften nå er riktig på hver side, og å merke noe som løst i et dashbord er ikke det samme som å bekrefte det. Bare en ny skanning over samme omfang forteller deg at endringen faktisk trådte i kraft.

Start med en gratis skanning, se på hva overskriftene dine egentlig gjør, og fiks de beste funnene én om gangen. Det er en rimelig første pasning - og en mye bedre plassering enn å håpe at standardverdiene var fine.