Test med og uden login: hvad en udleveret konto ændrer

Skal testeren have en konto til kundeportalen, eller skal testen foregå uden? Svaret afhænger af, hvem I er bekymrede for: en test uden login viser, hvad en fremmed kan opnå, mens en test med login viser, hvad en registreret bruger kan opnå ud over det, rollen giver lov til.

Forskellen er større, end den lyder. I en løsning som kundeportalen ligger ordrehistorik, kundeoplysninger, fakturaer, administration og integrationer bag login. De dele er kun synlige for den, der er logget ind. En test, der stopper ved loginsiden, ser derfor kun en lille del af løsningen.

Uden login: den åbne dør

En test uden login tager udgangspunkt i en person, der ikke har nogen konto. Testeren undersøger de dele af løsningen, alle kan nå: forsiden, søgning, kontaktformularer, oprettelse af konto, nulstilling af adgangskode og selve loginfunktionen.

Spørgsmålene er fx: Kan en fremmed få adgang til oplysninger, der burde kræve login? Kan loginfunktionen omgås? Afslører løsningen oplysninger om sine brugere eller sin opbygning? Er der administrative sider, der er synlige udefra? → Login og adgangskoder i en penetrationstest

Varianten er relevant, når løsningen har en stor offentlig del, fx webshoppen, eller når bekymringen især handler om personer uden nogen tilknytning til virksomheden. Den er også relevant som en del af en bredere test, fordi loginfunktionen er indgangen til alt det andet.

Med login: det, der sker bag døren

En test med login tager udgangspunkt i en person, der har en gyldig konto med en bestemt rolle. Det kan være en almindelig kunde i kundeportalen, en forhandler i en B2B-løsning eller en medarbejder i ERP-systemet.

Her handler spørgsmålene om adskillelse og rettigheder. Kan en kunde se en anden kundes ordrer? Kan en almindelig bruger nå funktioner, der er tiltænkt administratorer? Kan en bruger ændre oplysninger, de kun burde kunne læse? Kan en forhandler åbne aftaler og vilkår, der hører til en anden forhandler? → Kunders data holdt adskilt

Den slags spørgsmål kan næsten ikke besvares uden en konto. Svaghederne ligger i, hvordan løsningen behandler en bruger, der allerede er inde. OWASP Web Security Testing Guide beskriver test af autorisation og forretningslogik som selvstændige områder, og begge forudsætter typisk, at testeren kan logge ind.

Hvorfor en konto ikke gør testen mindre realistisk

Nogle købere er bekymrede for, at en udleveret konto gør testen for let eller urealistisk. Overvej i stedet, hvor let det er at få en konto. I en webshop kan alle oprette sig. I en kundeportal kan en konto blive misbrugt, hvis en kundes adgangskode bliver kendt. En medarbejderkonto kan blive overtaget gennem en mail.

En test med login svarer derfor på et realistisk spørgsmål: hvad sker der, når nogen har en konto, de ikke burde have, eller bruger en konto til mere, end de må? At udlevere kontoen sparer testeren for at bruge tid på at skaffe den og giver mere tid til de funktioner, der betyder noget. Valget mellem forskellige grader af forhåndsviden er beskrevet i → Black box, grey box og white box.

Begge varianter i samme opgave

En opgave kan godt rumme begge dele. Testeren begynder uden konto og undersøger den offentlige del og selve loginfunktionen. Derefter bruges de udleverede konti til funktionerne bagved. Bed om, at rapporten skelner mellem de to dele, så det er tydeligt, hvilke fund der kræver en konto, og hvilke en fremmed kan nå. Det har stor betydning for prioriteringen af rettelserne.

Hvilke konti skal testeren have?

Én konto er sjældent nok, når adskillelse skal undersøges. For at påvise, at kunde A ikke kan se kunde B’s oplysninger, skal testeren have to kundekonti. For at undersøge, om en almindelig bruger kan nå administrative funktioner, skal testeren kende begge roller.

Skriv en kort oversigt over de roller, løsningen har, og hvad hver rolle må. Vælg derefter, hvilke roller der skal med. Det kan fx være to almindelige kunder, en kunde med flere brugere og en administrator i kundeportalen. Oversigten hjælper også testeren til at skelne en tilladt funktion fra en fejl. → Testkonti og testdata

Tænk på data. Konti i produktion kan give adgang til rigtige kunders oplysninger. Overvej, om der kan oprettes testkunder med fiktive data, og aftal, hvad testeren gør, hvis der alligevel dukker rigtige oplysninger op.

Login, der hænger sammen med andre systemer

Kundeportalen kan bruge fælles login, tofaktorgodkendelse eller login gennem en ekstern tjeneste. Det påvirker testen. Hvis kundeportalen bruger virksomhedens fælles loginløsning, skal det aftales, om selve loginløsningen er med, eller kun portalen bag. → Single sign-on og penetrationstest

Tofaktorgodkendelse kræver praktisk planlægning. Testeren skal kunne logge ind med den anden faktor, uden at det kræver, at en medarbejder sidder klar hele testperioden. Aftal løsningen i god tid før start. Det kan fx være en særskilt testbruger, hvor den anden faktor er knyttet til en enhed eller et nummer, som testeren har adgang til i perioden. Beslutningen skal tages af den, der ejer loginløsningen, og registreres, så undtagelsen fjernes igen, når testen er afsluttet.

Et API, som portalen eller en integration bruger, har ofte sit eget login med nøgler eller tokens. Hvis API’et er med, skal adgangen til det også udleveres og beskrives. → Penetrationstest af API’er

Det skal I lade være med

At give kun én konto, når adskillelse skal testes · Testeren skal have mindst to brugere for at påvise, at de er adskilt.
At regne en test uden login for en test af hele løsningen · Funktionerne bag login er ikke undersøgt.
At udlevere en administratorkonto alene · Den viser ikke, hvad en almindelig bruger kan nå ud over sin rolle.
At glemme tofaktor · Uden en plan kan testeren ikke logge ind, og testtid går tabt.
At bruge rigtige kundekonti uden aftale · Opret testkunder, hvor det er muligt, og aftal håndtering af rigtige data.
At lade kontiene leve efter testen · Luk dem, når arbejdet er slut.

Hvad kan og ikke kan konkluderes

En test uden login kan vise, hvad en fremmed kunne opnå fra den offentlige del af løsningen på testtidspunktet. Den kan ikke sige noget om adskillelse og rettigheder bag login.

En test med login kan vise, hvad brugere med de udleverede roller kunne opnå. Den kan ikke sige noget om roller, der ikke indgik. Rapporten bør derfor nævne præcist, hvilke konti og roller der blev brugt. → Penetrationstest af webapplikationer

Tjekliste før testkonti udleveres

☐ Er det besluttet, om testen skal foregå med login, uden login eller begge dele?
☐ Findes der en oversigt over roller og hvad hver rolle må?
☐ Er der mindst to konti pr. rolle, hvor adskillelse skal testes?
☐ Kan der bruges testkunder med fiktive data?
☐ Er tofaktorgodkendelse og fælles login planlagt?
☐ Er adgang til tilknyttede API’er beskrevet?
☐ Er det aftalt, hvem der lukker kontiene efter testen?