Säkerhetsbrister handlar inte alltid om kodmissar eller felaktig konfiguration. Ibland är problemet betydligt djupare, det finns redan i själva designen av systemet. Därför hamnar osäker design på plats fyra i OWASP:s lista över de tio vanligaste sårbarheterna i moderna applikationer, A04:2021 Insecure Design.
Men vad betyder det egentligen att något är osäkert i designen?
Osäker design handlar om brister i applikationens arkitektur, affärslogik eller flöden, innan en enda rad kod skrivits. Det är alltså inte ett kodfel i sig, utan att systemet aldrig byggts med säkerhet i första hand.
Det kan till exempel vara att en funktion låter användaren ändra sin e-postadress utan att verifiera ägarskapet, att man tillåter obegränsat antal inloggningsförsök utan någon spärr, eller att viktiga affärsregler bara ligger i frontend, där de kan manipuleras av vem som helst.
Skillnaden mot andra sårbarheter är att det här inte alltid går att fixa med bättre kod. Problemet ligger i hur systemet fungerar från början.
Ett exempel på osäker design är den sårbarhet som upptäcktes i Amazon Alexa. Forskare visade att Alexa kunde acceptera röstkommandon även när ingen person var närvarande, vilket möjliggjorde attacker där angripare kunde öppna dörrar eller göra beställningar utan användarens vetskap. Detta berodde på att Alexa förlitade sig på enkel autentisering och saknade fysisk närvarokontroll. Det räckte att spela upp ljud ur en högtalare för att aktivera assistenten.
När affärslogik eller säkerhetskrav inte får plats i arkitekturen blir det svårt att reparera senare. Osäker design kan leda till dataläckor, ekonomiska förluster eller säkerhetsfunktioner som går att kringgå. Och till skillnad från vanliga sårbarheter som ofta kan hittas med en scanner, är designfel ofta osynliga för automatiska tester.
En välmenande funktion, som till exempel återställning av lösenord, API-rate limiting, eller betalningsflöden, kan missbrukas om de inte är byggda med säkerhet i åtanke. Ofta upptäcks dessa brister först när någon redan utnyttjat dem.
Det finns flera orsaker till att osäker design uppstår:
Resultatet blir ofta att säkerheten hamnar på efterkälken, eller att det krävs dyra och komplicerade ingrepp för att lappa ihop något som aldrig byggdes säkert från början.
Att förebygga osäker design kräver ett skifte i tankesätt, från att se säkerhet som en efterkontroll till att bygga den in i varje steg av systemets livscykel.
Här är några viktiga strategier:
1. Inkludera säkerhetskrav i designfasen
Sätt tydliga säkerhetsmål tidigt, redan när kravspecen skrivs. Vilken data hanteras? Vem får göra vad? Hur ser flödena ut i bästa, och sämsta, fall? Skriv krav inte bara på vad som ska hända, utan också på vad som inte får hända.
2. Använd threat modeling
Genom att modellera potentiella hot och missbruksscenarier får teamet bättre förståelse för vad som kan gå fel. Det är billigare att tänka bort risker på whiteboarden än att reparera dem i efterhand. Exempelvis STRIDE- och DREAD-modellerna kan vara bra hjälpmedel.
3. Bygg in säkerhetsprinciper i logiken
Affärsregler, autentisering och behörigheter bör ligga i backend. Oavsett vad som visas i gränssnittet ska reglerna gälla i det som faktiskt exekveras på serversidan. Det gäller både för webb, API och mobilappar.
4. Designa för felhantering och begränsning
Fundera på hur systemet beter sig under press: vad händer vid tiotusen inloggningsförsök? Går det att avbryta viktiga flöden mitt i steget? Har du spärrar mot missbruk? Ett säkert system är inte bara korrekt när allt går rätt, utan även robust när något går fel.
5. Skapa tvärfunktionella team
Låt utvecklare, arkitekter, testare och säkerhetsspecialister samarbeta redan från början. En säker design är inte en enskild persons ansvar, den kräver gemensam förståelse för systemets syfte och risker.
Osäker design är som att bygga en bro utan att räkna på hur mycket vikt den ska tåla. Du kan förstärka den i efterhand, men risken är att den redan börjat spricka. Det är säkrare, och billigare, att tänka på belastningen redan i ritningen.
Det handlar om att förstå flöden, roller, affärsregler och potentiella missbruk, och att göra säkerheten till en del av varje beslut. Genom att bygga säker arkitektur från grunden minskar risken för exploaterbara brister, och det gör systemen både robustare och tryggare att använda.
Vill du se hur det här fungerar i praktiken? Kolla in vår video här nedan, där visar vi hur en osäker design kan se ut, och hur lätt det kan gå fel.
Är du osäker på om ditt system har en säker design? Kontakta vårt AppSec-team på appsec@decerno.se. Vi hjälper dig att bygga en säkrare utvecklingsprocess och att hitta designproblem innan de blir till säkerhetsincidenter.
AppSec specialist
Kul att du vill veta mer! Applikationssäkerhet behöver inte vara komplicerat – men det är avgörande. Jag bollar gärna tankar om hur ni kan stärka säkerheten i era digitala lösningar.
Som specialist på applikationssäkerhet hjälper jag våra kunder att bygga robusta och säkra system – från arkitektur till implementation. Hör gärna av dig om du vill veta mer om hur vi kan säkra din digitala tjänst.
När du bokar ett möte med oss kan du förvänta dig:
