Tar du säkerheten på din webbplats på allvar?

På samma sätt finns det en del säkerhetskonfiguration som kan användas på webbplatser för att öka säkerheten, men som idag saknas på de flesta webbplatser* och som vi nog lär se tillbaka på om några år och undra varför vi inte använt tidigare.

*Enligt en nyligen genomförd studie av securityheaders.com, som analyserade de 1 miljon bästa webbplatserna på webben, använder endast 5,5 % av webbplatserna CSP (content security policy).

Content Security Policy - Vad är det och vad kan en sådan förhindra?

I denna blogg kommer vi att titta på säkerhetsheaders som är en slags konfiguration som ger webbläsaren instruktioner om vad som är tillåtet på webbplatsen. Det finns olika slags säkerhetsheaders, i denna bloggpost ska vi fokusera på den som heter Content Security Policy (CSP). CSP ger dig möjlighet att kontrollera vilka externa källor som får ladda olika typer av innehåll på din webbplats och därmed kan du förhindra att skadlig kod injeceras på din webb. 

Låt oss titta på två konkreta exempel:

Vi hade för ett par år sedan en redaktör med hög behörighet hade råkat få in ett JavaScript i ett fritextfält tack vare en webbläsarplugin. Det går att förhindra att en redaktör ska kunna lägga in detta, men i det här fall var det tillåtet då kunden själv ville kunna göra det på webbplatsen för att slippa behöva gå till utvecklingsteamet för alla behov. Med tillgång till att kunna exekvera script i en webbläsare så är det möjligt att göra rätt mycket om det inte finns begräsningar uppsatta, t. ex. automatiskt låta användaren ”göra någonting" på webbplatsen (och som kanske inte alltid syns), eller att ändra information på sidan programmatiskt så att besökaren ser annat innehåll än originalinnehållet. I detta fall gjorde scriptet ingenting farligt, men det påvisade ett av flera sätt hur script av misstag kan komma in på en webbplats.

Ett vanligare scenario är att en ”elak” besökare kan försöka lägga in script i användargenererat innehåll, t. ex. i en kommentar på en produkt eller tjänst. Det är förstås utvecklarteamets ansvar att se till att detta inte sker, ändå är det inte helt ovanligt då det kräver en viss kompetens för att förhindra detta. Och det är ju inte säkert att det är utvecklarteamet som utvecklar själva tjänsten som behöver vara den som missar detta. I princip all utveckling idag bygger på att man använder sig av olika ramverk och moduler, och dessa fel kan även finnas här, möjligheten att lägga in kommentarer är till exempel vanligt att man lägger in som en tredjepartstjänst.

Så vad kan man då göra för att minska risken för detta?

Det är här Content Security Policy kommer in. Mozilla beskriver Content Security Policy (förkortat CSP) som ett extra lager av säkerhet som hjälper till att upptäcka och mildra vissa typer av attacker, inklusive Cross-Site Scripting (XSS) och datainjektionsattacker. Det CSP gör är att definiera vilka slags resurser som får laddas in och användas av en webbplats, t. ex. script och stilmallar men även bilder och filer. Detta betyder att även om man av någon anledning utsätts för att någon har lyckats få in laddning av ovälkomna resurser på webbplatsen så kommer denna inte nödvändigtvis att få användas. Det är lite som att ha vakter innanför entrén till kontoret – även om någon lyckas ta sig innanför dörren som kräver en aktiv kodbricka, så kommer vakten att utifrån sina regler att kontrollera vem du är och om du verkligen får komma in. Ju mer specifika regler vakten har för vilka som ska få komma in, desto större är sannolikheten att man kan undvika en attack.

Hur man konfigurerar Content Security Policies

Låt oss kika lite mer på olika sätt att konfigurera CSPs. Förenklat kan man säga att man på varje sida på webbplatsen/tjänsten berättar för webbläsaren vad som är tillåtet att göra utifrån några direktiv, t. ex. vilka källor (domäner) som är tillåtna för att ladda script och stilmallar. Dessa direktiv kan vara samma för hela webbplatsen, eller skilja sig mellan olika sidor. Låt oss säga att man har konfigurerat upp CSP:s för webbplatsen och sagt att man tillåter script och stilmallar från sin egen domän. Om en sida nu försöker ladda en video från YouTube via ett script så kommer denna video inte att laddas. För den tekniskt lagda så kommer man att kunna se ett felmeddelande i utvecklarverktygen som säger att en video har förhindrats från att laddas. Lösningen är att tillåta att ladda videor (eller egentligen script då de används för att ladda in videon) från YouTube för hela lösningar, alternativt för sidor som faktiskt har en sådan video.

På samma sätt så behöver man lägga till motsvarande konfiguration för andra externa tjänster som webbplatsen använder sig av för att det ska fortsätta fungera. Ni kanske laddar script från Google Analytics, Google TagManager eller Hotjar (analysverktyg)? Dessa behöver läggas till. Kör ni Optimizely Search and Navigation så är det troligt att ni behöver godkänna script för tracking av sökstatistik. För en enkel tjänst som till stor del är kontrollerad av utvecklare så är det relativt lätt att sätta upp CSP:s men för en dynamisk redaktörsdriven webb där en hel del kommer in via t. ex. en tagmanager* så kan det kräva lite mer tid för att få det rätt.

*Tagmanager är ett verktyg för att hantera så kallade taggar, ett slags ”kodsnuttar” som man använder för att tillföra funktionalitet till en webbplats. 

Hantering av Inline Script

Script på en webbplats kan hanteras på två olika sätt. Antingen laddar man en scriptfil från en källa (kan vara från egna domänen eller en tredjepartstjänst) eller så lägger man in en så kallad script-tag direkt på sidan. Inline-script har fördelen att det kan genereras dynamiskt och det kan vara en fördel om man behöver anpassa själva scriptet för individen men i de flesta fall så är det bättre att använda separata scriptfiler.

Exempel på när inlinescript används

Ett vanligt exempel på inline-scripts är tredjepartssystem för att hantera cookies där det är vanligt att de lägger in både inline script och styles. Det finns även vissa Optimizely-moduler, t. ex. Optimizely Forms, som dynamiskt kommer att lägga in inline-script på en sida med ett formulär.

Hur hanterar man inline-script?

Att hantera scriptfiler från en källa gick vi igenom i föregående avsnitt, men hur gör man om man har behov av att ha inline-script? Om man har slagit på CSP:s för sin lösning och inte hanterar dessa, så kommer funktionaliteten troligtvis inte att fungera som förväntat - så vi behöver kunna hantera det.

Självklart så finns det en lösning även för detta. Lösningen är att man lägger in en så kallad nonce-key på sidan samt i script-taggen som skall få exekveras vilket man skulle kunna beskriva som en sorts kodnyckel. Denna skall automatgenereras och vara relativt unik. Detta gör att det är möjligt att skapa en sådan nyckel vid generering av sidan som sedan även då kan läggas in i alla inline-script på sidan, och som då indikerar att detta script skall tillåtas att exekveras - lite som en engångskod. Detta skillnad från det scriptet som en användare, medvetet eller omedvetet, har lagt in på en sida och som då inte får exekvera då den inte har en godkänd kod. Det är möjligt att för en enskild sida tillåta att alla inline-script exekveras vilket kan vara ett alternativ om ett script läggs in på sidan utan att man äger kontrollen över hur detta görs – men då innebär det också att man tar bort skyddet för andra att exekvera script på den sidan. Här gäller det att vara pragmatisk när man implementerar CSP: s. Bättre att få in så mycket skydd som möjligt och att man t. ex. tillåter inline-script i vissa fall än att inte göra någonting alls då man på så sätt minskar attackvektorn för någon som vill injicera script på en sida.

Hur vet jag hur bra säkerhet min webbplats har?

Säkerhet på webben beror på många olika faktorer, men om vi fokuserar på säkerhetsheaders så kan du gå in på https://securityheaders.com/ och skriva in din domän, så får du ett snabbt svar på vilka av dessa som är implementerade på din lösning, och vilka som saknas.

I nästa blogg så ska vi gå igenom penetrationstester och hur man kan använda dessa för att öka säkerheten på en webbplats.

Vill du veta mer om säkerhet, kvalitetssäkring eller prata webb i allmänhet? Kontakta oss så hjälper vi gärna till att svara på frågor, och att öka säkerheten på just din lösning.