HTTP-säkerhetsrubriker: CSP och HSTS

Du distribuerade applikationen. Sidorna laddas, formulären fungerar och ingenting ser trasigt ut. Sedan kör du en skanning och den kommer tillbaka med en lista med fynd om rubriker - och inget av det är uppenbart.

Det är en normal första reaktion. Rubriker visas inte på skärmen, så det är svårt att avgöra om de spelar någon roll eller om skannern bara är kinkig. Den här guiden går igenom de rubriker du kommer att se oftast, vad var och en faktiskt gör på vanligt språk och hur du kontrollerar dina utan gissningar.

Säkerhetsrubriker är instruktioner som din server skickar till webbläsaren bredvid sidan. Webbläsaren läser dem och justerar hur den hanterar ditt innehåll: vilka skript som kan köras, om sidan kan laddas över vanlig HTTP, om en annan webbplats kan bädda in den i en ram.

Ingenting på sidan ändras. Det är precis därför dessa fynd känns abstrakta - sajten kan se ut och bete sig perfekt samtidigt som den saknar en uppsättning skydd som skulle ha betydelse den dag något går fel.

Den ärliga inramningen är denna: rubriker minskar en specifik riskklass. De gör inte en webbplats säker på egen hand, och en ren rubrikkontroll bevisar inte att en webbplats är helt säker. Se dem som ett lager bland flera, och ett av de billigaste lagren att få rätt.

När en webbläsare begär en sida svarar din server med sidan och ett block av metadata som kallas svarsrubriker. Du kan se dem själv: öppna webbläsarens utvecklarverktyg, gå till fliken Nätverk, ladda om sidan och klicka på den övre begäran. Rubrikerna är precis där.

Säkerhetsrubriker är helt enkelt de som säger åt webbläsaren att tillämpa en regel. Vissa är strikta, vissa är rådgivande och alla är inställda i din serverkonfiguration, ditt ramverk eller din värdplattform - inte i din HTML.

CSP talar om för webbläsaren vilka innehållskällor som får laddas på din sida. Det är den mest kraftfulla rubriken här och den som folk tycker är mest skrämmande.

I praktiken stavar en CSP saker som: skript får bara komma från din egen domän och en betrodd CDN; bilder kan komma från var som helst över HTTPS; sidan får inte ramas in av en annan webbplats. Om något försöker ladda från en källa som du inte tillät, blockerar webbläsaren det och loggar försöket i konsolen.

CSP är ett ytterligare försvar mot skriptinjektion, tillsammans med säker utkodning och sanering. Det är också den rubrik som mest sannolikt bryter något om du ställer in den för aggressivt. Den praktiska vägen för en nybörjare är att börja i rapportläge, se vad som skulle ha blockerats, åtgärda de verkliga problemen och sedan genomdriva det.

HSTS säger åt webbläsaren att bara någonsin prata med din webbplats över HTTPS, under en bestämd period. När en webbläsare väl har sett denna rubrik kommer den att vägra göra en osäker HTTP-anslutning till din domän - även om en användare skriver http:// eller följer en gammal länk.

När webbläsaren känner till HSTS-policyn uppgraderar den HTTP-förfrågningar innan de skickas. Det första besöket kan fortfarande använda HTTP om inte domänen redan täcks av en HSTS preload-post.

En sak att respektera här är engagemang. HSTS kommer ihåg av webbläsaren så länge du anger, så börja med en kort varaktighet medan du bekräftar att varje underdomän fungerar över HTTPS, förläng den sedan när du är säker.

X-Frame-Options styr om en annan webbplats kan ladda dina sidor i en ram - en <iframe> på någon annans sida.

Varför bry sig? Eftersom inramning är mekanismen bakom clickjacking, där en angripare lägger över din riktiga sida med osynliga eller förklädda element så att en användare klickar på något de inte menade. Om din app har någon inloggad åtgärd - en raderingsknapp, en betalning, en inställningsändring - att rama in den någon annanstans är en risk du inte vill ha.

Den vanliga inställningen är SAMEORIGIN, som låter dina egna sidor rama in varandra men blockerar alla andra. Om du aldrig tänker bli inramad är det vanligtvis rätt standard.

Referrer-Policy bestämmer hur mycket av din webbadress som delas med andra webbplatser när en användare klickar på en länk bort från din sida. Moderna webbläsare använder normalt strict-origin-when-cross-origin: den fullständiga URL-adressen kan skickas på begäranden med samma ursprung, medan HTTPS-förfrågningar med flera ursprung endast får ursprunget. En explicit svagare politik kan avslöja mer.

Det är viktigt eftersom fullständiga webbadresser ibland innehåller känsliga värden i frågesträngar - tokens, ID:n, e-postadresser, söktermer. Att läcka dem till en tredje part är tyst och lätt att missa.

En förnuftig baslinje är att bara skicka ursprunget, eller ingenting alls, på förfrågningar över platsen. Det kostar dig nästan ingenting och tar bort en oavsiktlig dataläcka.

Några fler rubriker dyker upp tillräckligt ofta för att känna till namnet:

• X-Content-Type-Options: nosniff stoppar webbläsaren från att gissa en filtyp, vilket annars kan förvandla en uppladdad fil till ett körbart skript.

• Permissions-Policy stänger av webbläsarfunktioner som du inte använder, som kamera, mikrofon eller geolokalisering.

• Cross-Origin-Opener-Policy och relaterade rubriker med kors ursprung isolerar din sida från andra, vilket hjälper till att innehålla vissa attacker.

Du behöver inte alla på dag ett. Att veta vad de gör hjälper dig att läsa en skanningsrapport utan att få panik.

Du har två sätt att se på.

Först, den manuella rutten: utvecklarverktyg, fliken Nätverk, klicka på sidförfrågan och läs svarsrubriken. Detta är användbart för att bekräfta att en enstaka rubrik finns och ställa in som du förväntar dig.

För det andra, den praktiska vägen för mer än en sida: kör en skanning. En skanner hämtar din webbplats som en webbläsare och rapporterar vilka säkerhetsrubriker som finns, vilka som saknas och vad varje lucka avslöjar. Det ger dig en prioriterad lista istället för en vägg av rå text - och det kontrollerar de sidor du inte skulle ha tänkt att öppna manuellt.

Ett allmänt verktyg som VICE:s kostnadsfria lätta säkerhetsskanning kommer att flagga rubrikfynd tillsammans med andra problem, med bevisen bakom var och en så att du kan se varför den togs upp.

Rubriker lever i konfiguration, så de flesta korrigeringar är små: lägg till en rad i din serverkonfiguration, en inställning i ditt ramverk eller ett alternativ i din värds instrumentpanel. Ändra en rubrik i taget och bekräfta att webbplatsen fortfarande fungerar.

Skanna sedan igen. Detta är steget folk hoppar över. Att redigera en konfiguration betyder inte att rubriken nu är korrekt på varje sida, och att markera något som fixat i en instrumentpanel är inte detsamma som att bekräfta det. Endast en ny skanning över samma omfattning berättar att ändringen faktiskt trädde i kraft.

Börja med en gratis skanning, titta på vad dina rubriker verkligen gör och fixa de bästa fynden en i taget. Det är en rimlig första pass - och en mycket bättre position än att hoppas att standardvärdena var bra.