Penetrationstest af webapplikationer: hvad skal med, når løsningen har brugere og integrationer?

En test af en webapplikation kan efterlade væsentlige spørgsmål ubesvarede, hvis bestillingen kun nævner hjemmesidens adresse. Dækningen afhænger af de funktioner, brugerroller og forbindelser til andre systemer, der faktisk indgår i opgaven.

Forestil jer en kundeportal, hvor kunder ser ordrer, medarbejdere behandler henvendelser, og oplysninger kommer fra et ERP-system. Portalen er en samlet oplevelse for brugeren. For bestilleren er der flere dele at tage stilling til. Formålet er at få en undersøgelse, som passer til denne løsning, uden at antage, at alt bag adressen automatisk er omfattet.

Løsningen er mere end den offentlige side

En webapplikation kan være en webshop, en kundeportal eller et internt system, som bruges i en browser. Bestillingen bør begynde med løsningens funktion i virksomheden. Hvilke oplysninger og arbejdsopgaver er vigtige, og hvilken beslutning skal testen hjælpe med? → Typer af penetrationstest

For kundeportalen kan den offentlige del forklare produkter, mens ordrehistorikken først findes efter login. Hvis opgaven kun beskriver den offentlige del, mangler køberen et svar om kundernes egne funktioner. En test af hjemmesidens adresse er derfor ikke en præcis beskrivelse af begge dele.

Skeln også mellem testobjekt og perspektiv. En webapplikation kan undersøges fra forskellige udgangspunkter. Det er et særskilt valg, hvordan testeren får adgang til de aftalte dele. → Ekstern eller intern penetrationstest

Brugere og roller skal kunne skelnes

Beskriv de brugertyper, der betyder noget for formålet. I kundeportalen kan en almindelig kunde, en kundes administrator og en medarbejder have forskellige muligheder. Det skal være forståeligt, hvad hver rolle må se og gøre.

Det er ikke nødvendigvis nok at skrive, at testen sker med login. En konto til en almindelig kunde giver ikke automatisk grundlag for at vurdere medarbejdernes administration. Vælg rollerne bevidst, og få de udeladte roller vist som begrænsninger i dækningen.

Virksomhedens egen beskrivelse er en del af vurderingsgrundlaget. Hvis en erhvervskunde må se en hel afdelings ordrer, er det en anden adgang end den enkelte brugers personlige oversigt. Testeren skal kunne kende den tilsigtede forskel. → Black box, grey box og white box

Det gælder også fælles arbejdsgange. En kundeportal kan give en bruger ret til at oprette en ordre, mens en anden rolle skal godkende den. Bestillingen bør vise den forskel, hvis den er vigtig for spørgsmålet. En generel omtale af kundeadgang fortæller ikke, hvilke kombinationer af roller undersøgelsen skal belyse.

Vælg de forretningsfunktioner, der kræver et svar

Lav en oversigt over de centrale opgaver frem for kun en liste over skærmbilleder. I en webshop kan det være oprettelse af kunde, behandling af ordre og adgang til tidligere køb. I kundeportalen kan det være deling af dokumenter eller administration af medarbejdere.

Prioritér ud fra betydningen for virksomheden og dens kunder. Et spørgsmål om adgang til fakturaer kan kræve mere opmærksomhed end en informationsside uden kundespecifikke oplysninger. Prioriteringen skal kunne læses i bestillingen, så den ikke kun findes i projektlederens hoved.

Vær præcis om fravalg. Hvis webshoppen har flere butiksløsninger eller kundetyper, skal det fremgå, hvilke der indgår. En fælles forside gør ikke alle underliggende løsninger til én dækket opgave. → Scope i en penetrationstest

API’er og integrationer er også en del af valget

Et API er en grænseflade, som systemer kan bruge til at udveksle oplysninger og funktioner. I kundeportalen kan det være forbindelsen til ERP-systemets ordrer. Brugeren oplever måske blot et felt på skærmen, mens bestillingen skal skelne mellem de involverede dele.

OWASPs API Security-projekt behandler API’er som et selvstændigt sikkerhedsområde. For køberen er den praktiske pointe at spørge, hvilke forbindelser undersøgelsen omfatter. En test af portalens brugerfunktioner er ikke automatisk en fuldstændig vurdering af alle integrationer.

Beskriv derfor forbindelsen og dens rolle. Henter portalen blot oplysninger fra ERP-systemet, eller kan den også sætte arbejdsopgaver i gang? Det er ikke en teknisk testvejledning. Det er oplysninger om løsningen, som gør omfanget forståeligt for både projektleder, leverandør og tester.

Tredjepartsdele skal have en tydelig grænse

En webshop kan bruge en anden virksomheds betalingstjeneste, mens portalen ligger hos et hostingfirma. Bestillingen bør vise, hvilke dele der tilhører den aftalte løsning, og hvilke dele der ikke skal undersøges. Kundens samlede købsoplevelse og virksomhedens råderet er ikke det samme.

Skeln mellem forbindelsen til en tjeneste og hele tjenesten. At webshoppen bruger en betalingsudbyder, betyder ikke i sig selv, at undersøgelsen omfatter udbyderens øvrige platform. Rapporten bør senere bruge den samme afgrænsning, så der ikke opstår et forkert indtryk af dækningen.

Tilladelser og udbydervilkår skal være afklaret før opgaven. Den praktiske del hører til i → Før penetrationstesten. Brug leverandørernes viden om løsningen, men hold deres bidrag til dokumentationen adskilt fra vurderingen. → Uafhængig penetrationstest

Miljø og forhåndsoplysninger skal passe til spørgsmålet

En kopi af kundeportalen kan være velegnet til en afgrænset undersøgelse, men forskelle fra driften skal være kendte. Hvis kopien mangler ERP-forbindelsen, giver den ikke det samme grundlag for spørgsmål om integrationen. → Penetrationstest i produktion eller testmiljø

Beskriv også, hvilken udgave opgaven vedrører. Under udvikling af webshoppen kan nye funktioner blive klar tæt på testperioden. Det skal være muligt at forbinde rapportens dækning med den udgave, virksomheden senere vil træffe beslutning om.

Dokumentation om roller og funktioner kan gøre forventningerne tydeligere. En oversigt fra systemejeren behøver ikke være lang, men den skal kunne forklare, hvad de udleverede konti repræsenterer. Vigtige forskelle mellem kundetyper bør ikke kun være kendt af den udvikler, der har lavet dem.

Bestil dokumentation, der svarer til løsningen

Rapporten skal gøre det muligt at se forbindelsen mellem fund, funktion og brugerrolle. Et fund i kundeportalen bør ikke blot være placeret under systemets navn. Det skal kunne læses, hvilke dele og betingelser dokumentationen vedrører.

Henvisninger til en faglig guide bør også forklares i forhold til opgaven. Hvis tilbuddet nævner OWASP, så spørg, hvilke relevante områder i kundeportalen der omfattes, og hvad der holdes udenfor. Guidens navn er ikke en erstatning for en beskrivelse af det arbejde og den dokumentation, virksomheden bestiller.

Krav om rapportens indhold bør fremgå, før arbejdet begynder. Det gælder eksempelvis en oversigt over undersøgte områder, væsentlige begrænsninger og en forklaring af fundenes mulige betydning for virksomheden. → Sådan læser I en pentestrapport

Ved flere tilbud skal samme bestilling bruges som sammenligningsgrundlag. Et tilbud om webshoppen uden kundeadgang dækker noget andet end en opgave med kundetyper og integrationer. → Sammenlign tilbud på penetrationstest

Den samlede plan bør også vise, hvornår projektet skal bruge dokumentationen. Test af kundeportalen og beslutningen om åbning er forbundne, men forskellige opgaver. → Penetrationstest fra start til slut

Det skal I lade være med

At bruge en adresse som hele bestillingen. Kundeportalens funktioner og brugerroller skal også fremgå.
At lade en enkelt konto repræsentere alle. Medarbejderens adgang er ikke nødvendigvis den samme som kundens.
At forveksle skærmbilleder med hele løsningen. ERP-forbindelsen kræver sin egen plads i beskrivelsen af omfanget.
At tage tredjepartsplatforme for givet. Afgræns, hvad undersøgelsen må og skal omfatte.
At læse fund uden deres forudsætninger. Et resultat med en særlig kundetype skal kunne skelnes fra de øvrige roller.

Afklar tidligt, om behovet er en penetrationstest eller en anden form for gennemgang. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?

Hvad kan og ikke kan konkluderes

En test kan dokumentere påviste forhold i de omfattede funktioner under de beskrevne betingelser. Et fund i kundernes ordrehistorik er ikke automatisk en vurdering af hele ERP-systemet, selv om ordrene kommer derfra.

Manglende fund kan heller ikke stå alene. Hvis medarbejdernes administration ikke indgik, skal rapporten ikke bruges som svar om den del. Det samme gælder kundetyper og integrationer, der var udeladt. En fuld liste over løsningens funktioner er ikke bevis for, at alle funktionerne blev undersøgt.

Lad derfor konklusionen svare til den gennemførte opgave. En webshop kan have fået afklaret et vigtigt spørgsmål uden at være undersøgt udtømmende. De åbne spørgsmål bør kunne føres videre til virksomhedens plan, frem for at blive skjult bag betegnelsen testet.

Tjekliste til webshop og kundeportal

☐ Beskriv løsningens vigtigste opgaver og oplysninger.
☐ Udpeg de funktioner, som undersøgelsen skal give svar om.
☐ Forklar brugerroller og forskelle mellem kundetyper.
☐ Angiv relevante API’er og forbindelser til andre systemer.
☐ Skeln mellem egne dele og tredjepartsplatforme.
☐ Beskriv miljø og den udgave, resultatet skal vedrøre.
☐ Aftal dokumentation for dækning, fund og begrænsninger.
☐ Notér de dele af løsningen, som ikke bliver vurderet.

Kilder

OWASP Web Security Testing Guide: fagligt grundlag for afgrænsning af sikkerhedstest af webapplikationer.
OWASP API Security: API’er og sikkerheden omkring forbindelser og data.
NIST SP 800-115, afsnit 6.3 og 6.5 samt bilag C: valg, afgrænsning og applikationsundersøgelser.

Senest gennemgået: oktober 2026.