WORDS

Navigera i webbdjungeln: Säkerhet för webbplatser

Webbsäkerhet är ett delområde inom datasäkerhet, vilket jag har beskrivit närmare i en egen artikelserie. Här beskrivs istället översiktligt det viktigaste för dig som skapar webbplatser.

Attacker

Eftersom webben är en komplex plattform, så finns många olika typer av attacker. Här följer två av dom vanligaste.

Webbkodinjektion (xss). (engelska: cross-site scripting) Om en webbserver tar input från en användare och sedan visar denna information på en webbsida, så finns risk för webbkodinjektion. Exempelvis om man söker efter "kattungar<script>alert('xss')</script>" och denna inputtext inkluderas som del av sökresultatets HTML-kod, så kan en angripare potentiellt stjäla inloggningssessioner och göra allt som den inloggade användaren kan göra. För att skydda sig mot denna typ av säkerhetshål ser man till att escape-koda all dynamisk text. I HTML ändrar man t.ex. < till &lt;.

SQL-injektion. Om webbservern vid en sökning genererar en SQL-fråga dynamiskt, så kan en angripare potentiellt förstöra eller komma åt data som hen inte ska ha behörighet till. Om man exempelvis genererar SQL-frågan med "SELECT * FROM users WHERE username = '" + $username + "'" så kan en angripare radera hela user-tabellen genom att söka efter bob'; DROP TABLE users --. Den resulterande SQL-koden blir alltså (med radbrytningar för läsbarheten):

SELECT *
FROM users
WHERE username = 'bob';
DROP TABLE users --'

För att skydda sig mot SQL-injektioner är det bästa att använda parametriserade SQL-frågor.

Inloggning

Att skapa sitt eget inloggningssystem är riskfyllt. Om man ändå behöver skapa ett, så bör man tänka på några saker.

  • Lösenordshashning. Spara inte lösenorden i databasen. Använd istället en säker hash-algoritm (gärna Bcrypt eller Argon2; SHA-256 och SHA-3 är också acceptabla), med salt. I PHP finns en särskild funktion för detta syfte (password_hash).

  • Tvåfaktorautentisering. Med tvåfaktorautentisering (också kallad multifaktorautentisering) räcker det inte att användaren ger sitt lösenord vid inloggning, utan hen måste också mata in en kod från någon annan kommunikationskanal. Exempelvis kan man få ett mejl eller sms med en kod, eller mata in en kod från någon fysisk dosa, via Yubikey, Google Authenticator eller andra liknande lösningar.

HTTPS och serverinställningar

HTTPS och andra serverinställningar kan skydda din webbplats och dess användare från en rad olika attacker. HTTPS kan man idag få gratis via Let's Encrypt, och certifikaten förnyar man automatiskt varannan månad (för dom är bara giltiga i tre månader).

Dina kodberoenden

Om du utvecklat en sajt, så använder du troligen någon typ av beroenden på kod som andra har skrivit, och som inte heller ingår i språkets standardbibliotek. Oavsett om det bibliotek, ramverk eller plugin, oavsett om det är från NPM, Nuget, Pip eller någon annanstans, så utsätter du din egen dator, byggmiljön och servern för risker. Det är svårt att undvika, men du kan försöka att:

  • Använda så få beroenden som möjligt (också transitiva beroenden: undvik paket som är beroende av många andra paket)
  • Bara använda paket från författare du litar på

Slutsatser

Om du bara tar med dig en lärdom från den här artikeln, låt det vara denna:

Lita inte på information som du får från webbläsaren, oavsett om det är som del av url:en, POST-data eller en header.

Vidare läsning

Mozilla har ett flertal bra resurser som i mer detalj beskriver webbsäkerhet.

  • Website security. Beskriver några sårbarheter och principer för webbsäkerhet. Ger en bra introduktion.

  • Web security. Portal med länkar till ett stort antal artiklar om olika aspekter av webbsäkerhet.

  • Web security cheat sheet. En prioriterad lista över hur man bör ställa in sin webbserver för att direkt på servernivå hindra så många sårbarheter som möjligt.