Hvorfor bry deg om HTTP-headere? Jo, fordi visse HTTP-headere er et viktig verktøy som kan bidra til å stoppe eller vanskeliggjøre ulike typer angrep mot dem som besøker nettstedet ditt.
Her er 11 headere som kan øke sikkerheten på siden din, og 1 header du skal unngå for en hver pris.
1. HSTS – Strict Transport Security
En av de viktigste headerne er HSTS. Denne forhindrer at en angriper enkelt kan utføre Man-In-The-Middle angrep på siden din. På sider som ikke implementerer HSTS kan nemlig en angriper strippe vekk TLS/SSL, slik at trafikken ikke går via en kryptert HTTPS tunnel, men heller ruller gjennom vanilla HTTP.
Ved å sette HSTS header krever siden din at nettleseren skal benytte HTTPS for kommunikasjon. Man kan sette dette enten på applikasjonsnivå eller på web-servernivå.
2. CSP – Content Security Policy
Content Security Policy spesifiserer hvilken type ressurser siden din har lov til å laste. Dette kan bidra til å forhindre en rekke injection-baserte angrep, spesielt Cross-Site Scripting angrep. Baksiden ved CSP er at den kan være komplisert å implementere. Jobber du med forvaltning av en eksisterende side kan det være mye klundring og heft å få en god CSP på plass. Mozilla tilbyr en extension som heter Laboratory som genererer en CSP basert på at du surfer rundt på siden som deretter kan implementeres. Man kan sette CSP til å bare rapportere hendelser, men ikke blokkere. Dette kan være første steg på eksisterende applikasjoner. Jobber man med nyutvikling blir det raskt enklere.
Les mer: Input Validering: 10 populære Injection-baserte angrepsvektorer
3. X-Frame-Options
Dette er en «Response header» som styrer om siden din skal kunne bli vist i en IFrame eller ikke. Dette forhindrer Clickjacking angrep hvor en ondsinnet side benytter en IFrame til å laste inn din side. Angriper kan plukke opp museklikk fra brukeren som tror de trykker på din side. CSP kan også bidra til å forhindre siden din å lastes i en IFrame, men X-Frame-Options anbefales å sette uansett.
4. X-Content-Type-Options
Response header som sikrer at nettlesere bare bruker MIME types som applikasjonen har spesifisert som godkjent i Content-Type. Minimerer risiko for injection-baserte angrep og øker forutsigbarhet for nettleser som slipper å gjette på MIME type.
5. X-XSS-Protection
Response header som hindrer å laste siden hvis det detekteres XSS i Requesten. Bare støttet i Internet Explorer, Chrome, og Safari. Mozilla Firefox støtter ikke X-XSS-Protection header, Chrome planlegger å slutte støtte og Edge har avsluttet sin støtte. Årsaken til at denne går mot deprecated er fordi CSP header erstatter den.
Hvordan utføre sikkerhetstesting gjennom hele utviklingsløpet? Last ned guide og få konkrete tips:
6. Referrer-Policy
Response header som styrer informasjon som sendes i Referrer headeren ved Requests. Referrer header inneholder adressen til hvor brukeren kommer fra. Dette brukes til analyse og caching, men også for sporing.
I følge Mozilla sin dokumentasjon kan en Reset-Password side med link-knapper til sosiale medier gjøre at f.eks. Facebook også mottar din reset-passord URL, og i verste tilfelle benytte den sensitive informasjonen. For å unngå slike situasjoner har man headeren Referrer-Policy, som kan eksplisitt sette type info som skal være i Referrer headern, og ved å sette no-referrer fjerner Referrer headeren totalt.
Støttes ikke av Internet Explorer, Edge, eller Safari eldre enn 11.1.
Les mer: Hva skjer med stjålne data?
7. Feature-Policy
Feature-Policy er en Response header som styrer bruk av nettleser funksjoner som kan brukes på din side. Kan hindre bruk av APIer som styrer kamera og mikrofon, blokkere deprecated APIer, styre størrelse på bilderessurser, hvilke origins kan benytte hvilke funksjoner, etc.
Støttes ikke av Internet Explorer, Edge, eller Safari eldre enn 11.1.
8. Access-Control-Allow-Origin
Access-Control-Allow-Origin er en Response header som forteller nettleser hvilke eksterne nettsider JavaScript får lov til å gjøre kall i mot. Nettleseren gjør en Request til en side, og i Responsen ligger denne headeren som forteller nettleseren at ressurser fra spesifiserte (eller alle (*), ikke anbefalt) eksterne sider kan lastes sammen med siden.
9. Cache-Control
En generell header. Caching kan være utfordrende og by på overraskelser. Bare spør Altinn og Kenneth (36). Hvis forrige setning ikke hang på greip så kan les deg opp på hendelsen rundt skattelistene 2012, hvor en mann som het Kenneth fikk deler av sine personlige data eksponert til andre som logget seg inn for å se på selvangivelsen sin. Liten digresjon: Altinn jurister konkluderte med at det ikke var beskyttelsesverdige eller sensitive data som var eksponert og mente at han ikke hadde krav på erstatning (de punget ut 15 000kr allikevel grunnet sakens mediadekning…Kenneth krevde 100K). Altinn hadde nok ikke kunne kjørt samme strategi i dag mtp. GDPR.
Alle sider som behandler data som er sensitiv, bør være hemmelig eller er gradert må ikke benytte caching. Statiske sider som sjelden endres, og visse typer ressurser som JavaScript, CSS, bilder, etc. kan vurderes for caching.
10. Expires
Setter tiden hvor cachet innhold skal utløpe. Hvis applikasjonen ikke skal cache så sett denne til 0.
11. Set-Cookie
XSS angrep prøver ofte å hente ut informasjon lagret i Cookies (som på Norsk heter noe så fint som Informasjonskapsler). For å forhindre at Cookies sendes i over HTTP eller at JavaScript skal få tilgang bør man sette Set-Cookie flaggene Secure og HttpOnly.
12. HPKP – HTTP Public Key Pinning
HPKP Header gjør at web server sender et sett med public keys til klientens nettleser, og at bare disse nøklene kan benyttes til fremtidig kommunikasjon med siden. Mange har trodd at det er sertifikatene som «pinnes», men det er bare den offentlige nøkkelen (public key) som «pinnes». Målet med teknikken var å forhindre MITM (Man-In-The-Middle) angrep. Tanken var god, men funksjonaliteten kunne ha noen katastrofale følger.
HPKP er en såkalt TOFU (Trust on First Use) teknikk. Dette betyr at første gangen nettleseren går til siden mottar nettleseren en rekke Public Keys og disse blir lagret i nettleseren i en satt tidsperiode. All kommunikasjon videre skal benytte disse nøklene, og de forventes å bli funnet som del av et root-sertifikat i nettleseren. Problemet oppstår når et sertifikat er kommet på avveie eller at du må skifte ut nøkler. Da må du faktisk vente til tidsperioden er utløpt eller sette opp siden din under et nytt domene.
HPKP blir nå ansett som deprecated etter at Google valgte å avslutte støtte for det i Chrome. Mozilla Firefox støtter heller ikke HPKP lenger.
Hvordan sørge for at dine data er sikre?
Last ned guide: Slik utfører du sikkerhetstesting gjennom hele utviklingsløpet
