Login og adgangskoder: hvad kan testen vise?

Login er stedet, hvor et system afgør, om en person er den, vedkommende udgiver sig for at være. En penetrationstest kan vise, om den afgørelse holder i de situationer, testen har fået lov at undersøge, men kun hvis bestillingen beskriver hele forløbet og ikke kun selve feltet til adgangskoden.

Hele forløbet rummer mere, end man umiddelbart tænker på: oprettelse af konti, nulstilling af glemte adgangskoder, låsning efter fejlforsøg, den tid, en bruger forbliver logget ind, og lukning af konti, når en medarbejder eller kunde stopper. Hver del er en mulig indgang, og hver del kan indgå i testen, hvis den nævnes.

Login er en kæde af funktioner

Login opleves af brugeren som ét skridt. For systemet er det en række funktioner, der hænger sammen. Den svageste af dem bestemmer i praksis, hvor godt indgangen er beskyttet. Et stærkt krav til adgangskoder hjælper ikke meget, hvis funktionen til glemt adgangskode kan omgås.

OWASPs vejledning til test af webapplikationer behandler identitet, autentifikation og håndtering af sessioner som selvstændige områder. For køberen er pointen, at de tre områder bør nævnes hver for sig i bestillingen, så det er tydeligt, om de alle er med. Bestillingen af en webapplikation som helhed er beskrevet i → Penetrationstest af webapplikationer.

Hvilke indgange findes?

De fleste virksomheder har flere loginsider, end de umiddelbart kan nævne. Lav en liste, før testen afgrænses.

Kundernes login · i webshoppen eller kundeportalen.
Medarbejdernes login · til mail, intranet og interne webløsninger.
Administratorernes login · til styring af webshop, hjemmeside og systemer.
Fjernadgang · VPN og andre adgange udefra.
Leverandørernes login · adgange, som partnere bruger til at vedligeholde systemer.

Administrationssider er værd at nævne særskilt. De er ofte mindre synlige end kundernes login, men de giver langt videre rettigheder. Fjernadgangen har sit eget opslag. → Fjernadgang og VPN i penetrationstesten

Hvis flere systemer bruger samme fælles login, er det en særlig situation, fordi en svaghed ét sted kan række til alle systemerne bag. → Fælles login (single sign-on) i testen

Spørgsmål om selve indgangen

Ved selve loginsiden kan køberens spørgsmål eksempelvis være, om systemet afslører, hvilke brugernavne der findes, om gentagne forsøg bliver bremset, og om oplysningerne sendes beskyttet. Testeren afgør, hvordan spørgsmålene besvares. Køberens opgave er at sige, hvilke indgange der er med, og hvad systemet efter virksomhedens opfattelse skal gøre.

Låsning efter fejlforsøg er et eksempel på, hvor virksomhedens egen hensigt skal være kendt. Hvis kunder skal låses ude efter et antal forsøg, kan testeren vurdere, om det sker. Hvis virksomheden bevidst har valgt ikke at låse, er det en forudsætning for at forstå resultatet. Aftal også, hvad der sker, hvis testen låser rigtige brugere ude.

Hvis login kræver en ekstra faktor ud over adgangskoden, rejser det særlige spørgsmål om, hvor faktoren gælder, og hvor den ikke gør. → Tofaktorlogin i testen

Glemt adgangskode, oprettelse og lukning

Funktionerne omkring login overses ofte, fordi de bruges sjældnere. Det er netop derfor, de bør nævnes.

Nulstilling af adgangskode er en anden vej ind. Køberens spørgsmål er, om den kun kan bruges af den rette person. Oprettelse af konti er relevant, hvis kunder selv kan registrere sig i webshoppen. Lukning af konti handler om, hvad der sker, når en kunde eller medarbejder stopper: forsvinder adgangen, eller ligger den gamle konto stadig og venter?

For at undersøge disse funktioner skal testeren normalt have testkonti, og nogle gange skal virksomheden kunne oprette og lukke konti undervejs. Det kræver planlægning med den, der administrerer brugerne. Husk at lukke testkontiene igen, når opgaven er slut, og at få bekræftet, at det er sket. → Testkonti og testdata

Når brugeren er logget ind

Login er ikke slut, når adgangskoden er godkendt. Systemet husker brugeren, så personen ikke skal logge ind ved hvert klik. Det rejser spørgsmål om, hvor længe en bruger forbliver logget ind, om et log ud faktisk afslutter adgangen, og om én bruger kan overtage en andens adgang.

Hvad en bruger kan se og gøre efter login, er et beslægtet, men andet spørgsmål. Det handler om rettigheder og adskillelse, ikke om login. Hvis kundeportalen har mange kunder, er adskillelsen mellem dem ofte det vigtigste spørgsmål af alle. → Kunders oplysninger skal holdes adskilt

Politik og praksis for adgangskoder

Mange virksomheder har en skrevet politik for adgangskoder. En penetrationstest kan sige noget om, hvorvidt de systemer, der indgår, håndhæver politikken. Den kan ikke sige, om medarbejderne følger den i andre systemer, eller om de genbruger adgangskoder privat.

Skriv politikken ind i bestillingen eller vedlæg den. Så kan testeren sammenholde det, systemet tillader, med det, virksomheden har besluttet. Afvigelser mellem politik og praksis er brugbare fund, også når de ikke i sig selv giver adgang.

Vær opmærksom på, at systemer ofte har forskellige regler. Webshoppens kunder kan være underlagt andre krav end medarbejderne i ERP-systemet, og et ældre system kan have regler, der ikke længere svarer til politikken. Beskriv de forskelle, I kender, så testeren ved, hvilke regler der gælder hvor. Hvis I ikke kender dem, er det i sig selv et godt spørgsmål at få besvaret, men det skal stå i opgaven som et spørgsmål og ikke forudsættes som kendt.

Det skal I lade være med

At nævne loginsiden og intet andet. Nulstilling, oprettelse og lukning af konti er en del af samme kæde.
At glemme administrationssiderne. De er mindre synlige, men giver bredere rettigheder.
At udelade virksomhedens hensigt. Testeren skal vide, hvad systemet efter jeres opfattelse skal gøre.
At teste uden en plan for låste konti. Rigtige kunder og medarbejdere skal kunne komme ind.
At forveksle login med rettigheder. Hvad brugeren må efter login, er et andet spørgsmål.

Hvad kan og ikke kan konkluderes

En test kan vise, hvordan de undersøgte indgange og funktioner opførte sig under testen, med de konti testeren havde. Den kan ikke vise, om indgange, der ikke stod på listen, er beskyttet på samme måde.

Den kan heller ikke sige noget om, hvor stærke medarbejdernes faktiske adgangskoder er, medmindre det udtrykkeligt er en del af opgaven, med de hensyn til fortrolighed det kræver. Et resultat uden fund ved login betyder, at de aftalte spørgsmål ikke gav anledning til fund. Det betyder ikke, at ingen kan komme ind.