Eksempel: Sådan testede vi en kundes applikation for sikkerhed
Sikkerhed er ikke længere et valg – det er en nødvendighed. I takt med at flere virksomheder flytter deres tjenester til skyen og lancerer webapplikationer, bliver truslen fra cyberangreb mere aktuel end nogensinde før. I dette blogindlæg får du et indblik i, hvordan vi hos [indsæt firmanavn] gennemførte en komplet sikkerhedstest – også kaldet en pentest – på en kundes applikation. Vi viser processen, resultaterne og de vigtigste læringer undervejs.
Baggrund: En kundes udfordring med applikationssikkerhed
Kunden, en mellemstor SaaS-virksomhed, havde for nylig lanceret en ny platform til deres brugere. Applikationen var kompleks med integrationer til både betalingsgateways og CRM-systemer, og den indeholdt følsomme brugerdata. Kunden kontaktede os, fordi de ønskede en uvildig vurdering af, hvor sikker deres løsning egentlig var.
De havde allerede investeret i grundlæggende sikkerhed som HTTPS, adgangskontrol og firewalls, men de manglede konkret viden om, hvorvidt en angriber kunne finde og udnytte svagheder i koden eller arkitekturen.
Vores tilgang: En kombination af manuel og automatiseret pentest
Vi valgte at strukturere arbejdet i tre faser: planlægning, aktiv test og rapportering.
1. Planlægning
I den indledende fase holdt vi møder med kundens tekniske team for at forstå applikationens funktioner, brugerflows og arkitektur. Det var vigtigt for os at få adgang til både staging- og produktionsmiljøer, så vi kunne identificere forskelle og potentielle misforhold.
Vi aftalte omfanget af testen: hvilke endpoints der måtte angribes, hvor meget trafik systemet kunne tåle, og hvilke værktøjer vi måtte benytte.
2. Aktiv test
I testfasen benyttede vi både automatiserede scanningværktøjer som OWASP ZAP og Burp Suite samt manuelle teknikker. De manuelle tests fokuserede på at efterligne realistiske angreb, fx:
- SQL-injection mod søgefunktioner og loginfelter
- Cross-site scripting (XSS) i brugerkommentarer
- Uautoriseret adgang via svage sessionstokens
- Fejl i adgangskontroller (horizontal privilege escalation)
Vi forsøgte også at misbruge API-endpoints med ugyldige tokens, forkerte permissions og ændrede anmodningsdata. Vores tilgang var ikke blot at identificere sårbarheder, men også at validere, hvorvidt de kunne udnyttes til at få adgang til følsom information.
3. Rapportering
Efter testen leverede vi en detaljeret rapport med fundne sårbarheder kategoriseret efter risikoniveau (kritisk, høj, middel, lav). Hver sårbarhed blev beskrevet med:
- Teknisk forklaring
- Eksempler på udnyttelse
- Screenshots og anmodningslog
- Forslag til løsning
Vi afholdt også en workshop med kundens udviklingsteam, hvor vi gennemgik rapporten og rådgav om, hvordan de bedst kunne implementere sikkerhedsforbedringerne.
Resultater: Konkrete fund og forbedringer
Testen afslørede flere væsentlige sikkerhedshuller, herunder:
- En alvorlig XSS-sårbarhed, der kunne bruges til session hijacking
- Uautoriseret adgang til en API-endpoint, som gav adgang til brugernes profilbilleder og emailadresser
- Manglende rate limiting på loginfunktionen, hvilket åbnede for brute force-angreb
Heldigvis var kunden hurtig til at reagere. De lukkede alle kritiske sårbarheder inden for en uge og lavede en intern proces for løbende sikkerhedsreviews. Vores pentest blev også starten på, at de indførte automatiseret sikkerhedstest som en del af deres CI/CD-pipeline.
Hvad kan andre virksomheder lære af denne case?
Der er mange pointer fra denne proces, men de vigtigste er:
- Sikkerhed er ikke et engangsprojekt. Det kræver løbende opmærksomhed og bør integreres i udviklingscyklussen.
- Manuelle tests er afgørende. Automatisering finder de lavthængende frugter, men manuelle tests afdækker de komplekse sårbarheder.
- Transparens og samarbejde med udviklingsteamet er nøglen. Når sikkerhedsfolk og udviklere arbejder sammen, opstår de bedste løsninger.
- Det er billigere og mindre skadeligt at finde fejl internt end at lade hackere gøre det.
Derfor er det en god investering at test din applikation med en professionel pentest – før det går galt.
Afslutning: Sikkerhed som konkurrencefordel
I dag bruger kunden vores rapport aktivt som dokumentation overfor partnere og brugere, når de skal vise, at deres systemer er sikre. Sikkerhed er ikke kun et teknisk behov – det er også en branding- og salgsparameter. Når man kan vise, at man har gennemgået en professionel sikkerhedstest og har styr på processerne, skaber det tillid.
Hvis du selv står med en applikation – stor eller lille – og ikke har fået lavet en uafhængig sikkerhedstest, så er tiden inde. Det handler ikke om at finde fejl for fejlens skyld, men om at styrke dit produkt og beskytte dine brugere.
