OWASP Top 10: säkerhetsluckor på webben

01Vad är OWASP och listan Top 10?

OWASP (Open Worldwide Application Security Project) är en öppen gemenskap som tar fram gratis resurser, verktyg och guider om mjukvarusäkerhet. Det mest kända arbetet är listan Top 10, som uppdateras med några års mellanrum.

Listan är varken en standard eller ett certifikat, utan ett medvetandedokument. Den tas fram genom att öppna data från verkligheten och expertutlåtanden vägs samman, och den säger till utvecklare: “se först upp för dessa”. I den här artikeln utgår vi från kategorierna i den allmänt vedertagna versionen från 2021.

Listan förändras med tiden, och i nya versioner byter kategorier plats eller slås ihop. Kontrollera alltid den aktuella versionen på den officiella källan owasp.org.

021–2. Åtkomstkontroll och kryptering

De två första platserna på listan gäller vem datan visas för och hur den skyddas. Båda hör till de vanligaste och mest allvarliga säkerhetshålen, eftersom de rör kunddata direkt.

Bruten åtkomstkontroll

Ett fel i åtkomstkontrollen innebär att en användare kan nå data eller åtgärder hon saknar behörighet till. Ett klassiskt exempel: en kund ändrar värdet siparis/1052 i adressfältet till 1053 och ser någon annans order.

Åtgärden är enkel men kräver disciplin: vid varje förfrågan, på serversidan, måste frågan “får den här användaren se den här posten?” ställas på nytt. Standardbeteendet bör vara att neka, och åtkomst ska bara öppnas i uttryckligen tillåtna fall.

Kryptografiska fel

Hit hör känslig data som överförs eller lagras okrypterad. Lösenord som lagras i klartext eller med svaga metoder, avsaknad av HTTPS och föråldrade krypteringsalgoritmer är de vanligaste exemplen.

För lösenord bör man använda långsamma hashmetoder som är gjorda för uppgiften, som bcrypt eller Argon2. All trafik ska gå över HTTPS, och krypteringsnycklar ska förvaras i en säker miljö, inte i koden.

033. Injektion: SQL injection och XSS

Att data från användaren körs som en del av ett kommando är en injektionssårbarhet. De mest kända typerna är SQL injection och XSS. I listan från 2021 behandlas även XSS under denna kategori.

Vad är SQL injection?

SQL injection innebär att en databasfråga ändras med specialtecken som skrivs in i ett formulär eller en adress. Angriparen kan stjäla eller radera data eller logga in obehörigt. Lösningen är att bygga frågan med förberedda frågor (prepared statements) i stället för att sätta ihop text.

// FEL: användarens inmatning läggs direkt in i frågan
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";

// RÄTT: förberedd fråga
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();

Vad är XSS?

XSS (Cross-Site Scripting) innebär att JavaScript som angriparen skrivit placeras på sidan. Ett skript som skrivs in i ett kommentarsfält kan köras i webbläsaren hos alla som öppnar sidan. De viktigaste åtgärderna är att göra kontextanpassad escaping när utdata skrivs ut och att lägga till rubriken Content Security Policy (CSP).

echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');

044–5. Osäker design och konfiguration

De här två kategorierna handlar mindre om själva koden än om beslut: hur systemet är uppbyggt och hur servern är inställd. Den goda nyheten är att båda till stor del kan förebyggas med processer och checklistor.

Osäker design

Den här kategorin beskriver mer ett designfel än ett kodfel. Exempel: att vid lösenordsåterställning enbart lita på en gissningsbar säkerhetsfråga, eller att en kampanjkod kan testas obegränsat. Även om koden är felfri täpps inte ett designhål till.

Åtgärden är att tänka på säkerhet i början av utvecklingen och inte i slutet: hotmodellering, missbruksscenarier och begränsning av antalet försök (rate limiting) ska diskuteras redan i designfasen.

Felkonfigurerad säkerhet

Hit hör standardlösenord som inte ändrats, serverdetaljer som visas i felmeddelanden, onödiga tjänster som lämnats öppna eller kataloglistning som är på. Det här är ofta de hål som är lättast att utnyttja.

Åtgärd: ta fram en skriftlig härdningslista för server och applikation, stäng av felinformation i produktionsmiljön, lägg till säkerhetsrubriker (som HSTS, CSP och X-Content-Type-Options) och granska konfigurationen regelbundet.

056–7. Komponenter och autentisering

Riskerna på plats sex och sju gäller delar som applikationen hämtar utifrån och hur man verifierar vem användaren är. Båda kräver regelbundet underhåll, det räcker inte att sätta upp dem en gång.

Föråldrade komponenter med sårbarheter

En modern applikation använder tiotals, ibland hundratals externa bibliotek. När ett säkerhetshål upptäcks i ett av dem hamnar din applikation i riskzonen, även om du inte gjort ett enda fel.

Åtgärd: för en lista över de komponenter som används, följ säkerhetsmeddelanden och uppdatera regelbundet. Granskningskommandon i pakethanterarna gör det lättare. Att ta bort oanvända beroenden är också en av de billigaste säkerhetsåtgärderna.

npm audit
composer audit

Fel i autentisering

Hit hör att tillåta svaga lösenord, vara öppen för obegränsade inloggningsförsök, lagra sessions-ID osäkert eller att inte avsluta sessionen vid utloggning.

Åtgärd: begränsa antalet försök, erbjud tvåstegsverifiering, kontrollera mot listor över läckta lösenord och ställ in sessionscookies med egenskaperna HttpOnly, Secure och SameSite.

068–10. Integritet, loggning och SSRF

Integritet i mjukvara och data

Att köra uppdateringar, tillägg eller en automatisk driftsättningskedja utan verifiering öppnar en dörr för angriparen. Signerade paket, pålitliga källor och granskning av leveranskedjan är grunden för åtgärden.

Brist på loggning och övervakning

Om en attack inte upptäcks växer skadan. Misslyckade inloggningar, behörighetsfel och kritiska åtgärder ska loggas, och ovanliga situationer ska ge en varning. Känslig data som lösenord får inte skrivas i loggarna.

SSRF

SSRF (Server-Side Request Forgery) innebär att servern tvingas skicka en förfrågan till en adress som kommer från användaren. På så vis kan angriparen nå tjänster i det interna nätverket. Den grundläggande åtgärden är att använda en tillåtelselista för de adresser som får anropas.

07Checklista för säker kodning

De flesta säkerhetshål kan förebyggas med några grundläggande vanor. Använd listan nedan vid kodgranskningar och kontroller före publicering. Hur testprocesser hänger ihop med säkerhet har vi gått igenom i artikeln vad är mjukvarutestning.

1. Lita aldrig på indata: validera all indata på serversidan.
2. Använd förberedda frågor: bygg inte SQL genom att sätta ihop text.
3. Escapa utdata: efter kontexten HTML, URL och JavaScript.
4. Kontrollera behörighet vid varje förfrågan: det räcker inte att dölja något i gränssnittet.
5. Håll hemlig information borta från koden: nycklar hör hemma i miljövariabler eller ett valv.
6. Håll beroenden uppdaterade: kör regelbundet granskningskommandot.
7. Logga och övervaka: upptäck misstänkta händelser.

08Vad säkra språk och verktyg bidrar med

Vissa typer av säkerhetshål kan också minskas genom val av språk och verktyg. Språk med minnessäkerhet förhindrar till exempel i stor utsträckning de buffertöverskridningar som är vanliga i C och C++, och det har vi beskrivit i artikeln vad är Rust. WebAssembly, som körs i en säker sandlåda i webbläsaren, bygger på en liknande isoleringslogik.

Ändå löser inget språk av sig självt fel i åtkomstkontroll eller design. I webbapplikationer beror största delen av säkerheten på teamets vanor och processer.

Hos Aurora Yazılım tillämpas de här grundprinciperna som en del av utvecklingsprocessen i projekt som branschanpassade mjukvarulösningar, företagswebbplatser och e-handelsplattformar.