Webapplikasjoner og API-er
Penetrasjonstest av webapplikasjoner og API-er
De alvorligste funnene i en webapplikasjon er sjelden tekniske i klassisk forstand. De handler om at én bruker kan se en annen brukers data, eller at et steg i en betalingsflyt kan hoppes over. Slikt finner du ikke med en skanner.
Typisk 2–4 uker fra oppstart til rapport. Retesting er inkludert.
Testområder
Der vi finner mest
Vi følger OWASP-metodikken systematisk, men bruker mest tid der erfaring tilsier at feilene faktisk sitter.
Tilgangskontroll mellom brukerroller
Vi logger inn som flere roller samtidig og prøver systematisk å nå data og funksjoner vi ikke skal ha. Mangelfull tilgangskontroll er den vanligste alvorlige feilen vi finner, og den nesten aldri fanges opp av automatiske verktøy.
Feil i forretningslogikken
Kan et steg hoppes over? Kan en rabatt brukes to ganger? Kan en ordre endres etter godkjenning? Dette krever at testeren forstår hva applikasjonen skal gjøre — ikke bare hvilke HTTP-forespørsler den tar imot.
Autentisering og sesjonshåndtering
Innlogging, tofaktor, glemt passord, invitasjonslenker, tokenhåndtering og utlogging. Vi ser særlig etter flyter som er lagt til i ettertid, for det er der de logiske hullene pleier å oppstå.
API-er, REST og GraphQL
Vi tester endepunktene direkte, ikke bare gjennom brukergrensesnittet. GraphQL får egen behandling: introspeksjon, dybdeangrep og felter som er tilgjengelige selv om de aldri brukes av frontend-en.
Injeksjon og datavalidering
SQL-injeksjon, kommandoinjeksjon, malinjeksjon, SSRF og usikker deserialisering. Verifisert manuelt, med bevis, slik at ingen bruker tid på å diskutere om funnet er en falsk positiv.
Filopplasting og integrasjoner
Opplastingsfunksjoner, webhooks, tredjepartsintegrasjoner og interne tjenester som stoler litt for mye på hverandre. Det er ofte her veien fra en vanlig brukerkonto til serveren går.
DAST-verktøy eller manuell test?
Vi bruker begge deler i et oppdrag, men de dekker helt ulike deler av risikobildet.
| Automatisert DAST | Manuell penetrasjonstest | |
|---|---|---|
| Kjørefrekvens | Kan kjøres hver natt, i hver byggejobb. | Planlagt oppdrag, typisk før store slipp eller årlig. |
| Tilgangskontroll | Ser sjelden forskjell på hva ulike roller skal få lov til. | Testes systematisk mellom alle roller vi får tilgang til. |
| Forretningslogikk | Ingen dekning. Verktøyet kjenner ikke prosessen din. | Hovedfokus. Her ligger de dyreste feilene. |
| Flerstegsflyter | Feiler ofte på handlekurv, tofaktor og veivisere. | Gjennomgås manuelt, steg for steg. |
| Resultat | Lang liste, mye støy, uklar prioritering. | Færre funn, hvert av dem verifisert og prioritert. |
| Bruk som dokumentasjon | Sjelden tilstrekkelig alene. | Godtas som testbevis mot PCI DSS, ISO 27001 og SOC 2. |
Krav
Kravene som treffer webapplikasjoner i Norge
Vi merker funnene mot rammeverket du rapporterer i, slik at kartleggingen ikke blir en jobb du må gjøre etterpå.
PCI DSS
Tar du imot kortbetaling, krever PCI DSS penetrasjonstesting av applikasjonslaget minst årlig og etter vesentlige endringer. Rapporten dokumenterer omfang, metodikk og resultat i det formatet en QSA forventer, og retesten dekker kravet om at funn skal verifiseres som lukket.
Personopplysningsloven og GDPR
En webapplikasjon som behandler personopplysninger, faller rett inn under kravet i artikkel 32 om testing av tekniske tiltak. Har du hatt et avvik, er en dokumentert penetrasjonstest også noe av det første Datatilsynet vil se etter i vurderingen av om tiltakene var forsvarlige.
Digitalsikkerhetsloven og NIS2
Er du leverandør inn mot en sektor som omfattes, vil kunden din videreføre kravene i kontrakt. NIS2 er EØS-relevant og innlemmes i EØS-avtalen, og leverandørkjeden er et eksplisitt tema. En fersk testrapport er ofte det raskeste svaret på et leverandørspørreskjema.
ISO 27001 og sikker utvikling
Kravene til sikkerhet i utviklingsløpet og til teknisk sårbarhetshåndtering forutsetter at applikasjonene faktisk testes. Vi leverer omfangsbeskrivelse, funnliste og retestbevis som tre separate deler, fordi det er slik revisor pleier å be om dem.
Gjennomføring
Fem steg fra oppstart til bekreftet lukking
- 01
Oppstart og tilganger
Vi går gjennom applikasjonen sammen, får testbrukere for hver rolle og avklarer hvilke miljøer som er i omfang. Én time godt brukt her sparer flere dager senere.
- 02
Kartlegging
Vi kartlegger alle endepunkter, parametre, roller og flyter — inkludert de som ikke er synlige i brukergrensesnittet, men som fortsatt svarer på forespørsler.
- 03
Manuell testing
Hoveddelen av oppdraget. Tilgangskontroll, logikk, autentisering, injeksjon og integrasjoner testes for hånd, og alt som ser lovende ut forfølges til det er avklart.
- 04
Rapport og gjennomgang
Rapport med bevis og reproduksjonssteg, etterfulgt av en gjennomgang der utviklerne kan stille spørsmål direkte til testeren som fant funnet.
- 05
Retest
Vi verifiserer utbedringene og oppdaterer rapporten. Ubegrenset og inkludert, slik at du har ferdig dokumentasjon når revisjonen kommer.
Ofte stilte spørsmål
Om testing av webapplikasjoner
Relaterte tjenester
Finn hullene i applikasjonen før kundene dine gjør det
Send oss en kort beskrivelse av applikasjonen, så foreslår vi omfang og gir deg et fastpristilbud.
Be om tilbud