Penetrationstest før lancering af en ny webshop

En penetrationstest, der lægges få dage før en ny webshop åbner, kan finde alvorlige fejl uden at efterlade tid til at rette dem. Det rigtige tidspunkt hviler på to betingelser: webshoppen skal være færdig nok til, at testen undersøger det, kunderne faktisk møder, og der skal være tid til rettelser og en efterfølgende kontrol, før dørene åbnes.

Planlæg derfor testen baglæns fra lanceringsdatoen. Først kommer den sidste kontrol af rettelserne, før den kommer tiden til at rette, og før den selve testen. Hvor meget tid hvert led kræver, afhænger af webshoppens størrelse, leverandørens kapacitet og hvor mange fund der viser sig, så planen bør have luft.

Hvad skal være færdigt, før testen giver mening?

En test af en halvfærdig webshop giver et halvt svar. De funktioner, der behandler kunders oplysninger og penge, bør være på plads: oprettelse af konto, login, kurv, bestilling, ordrehistorik og de administrative sider, hvor medarbejdere håndterer ordrer og kunder.

Integrationer bør også være koblet på. Hvis webshoppen sender ordrer til ERP-systemet, henter lagerstatus fra en partner eller bruger en ekstern betalingsløsning, ændrer forbindelserne både funktionaliteten og eksponeringen. En test uden integrationerne siger ikke meget om den løsning, der går i drift.

Det samme gælder opsætningen hos hostingfirmaet. Domæne, certifikater, administrative adgange og sikkerhedsindstillinger bør svare til det, der skal bruges ved lanceringen. Den nærmere afgrænsning af funktioner, roller og integrationer i en webtest er beskrevet i → Penetrationstest af webapplikationer.

Små ændringer efter testen er uundgåelige. Det afgørende er, at de store byggesten ligger fast, så testen ikke skal gentages, fordi arkitekturen blev lavet om i sidste øjeblik.

Læg tiden til rettelser ind i planen

Den hyppigste planlægningsfejl er at behandle testen som det sidste punkt før lanceringen. Fundene kræver tid hos udviklerne eller platformleverandøren, og nogle rettelser kan kræve ændringer i flere dele af løsningen. → Testen ligger lige før lanceringen uden tid til at rette

Aftal med leverandøren, før testen begynder, hvordan kritiske fund håndteres. Skal de rettes med det samme, eller samles de til rapporten? Hvem prioriterer, og hvem beslutter, om en rettelse er god nok til lanceringen? Det er lettere at aftale den slags i ro end midt i en presset slutfase.

Afsæt også tid til at efterprøve de vigtigste rettelser. En meddelelse fra leverandøren om, at et fund er rettet, er ikke det samme som en kontrol. → Retest efter penetrationstest

Testmiljø eller den kommende produktion

Før lanceringen findes webshoppen ofte i et testmiljø og eventuelt i den produktion, der endnu ikke er åben. Begge kan bruges, men de besvarer ikke helt det samme. Et testmiljø kan mangle den rigtige hosting, den rigtige betalingsopsætning eller de rigtige integrationer. Den kommende produktion er tættere på virkeligheden, men skal måske skånes for testdata. → Penetrationstest i produktion eller testmiljø

Et særligt hensyn før lancering er, at produktionen endnu ikke har rigtige kunder. Det kan gøre det lettere at teste i den rigtige opsætning uden at berøre personoplysninger. Til gengæld skal testdata og testkonti fjernes, før webshoppen åbner.

Vælger I testmiljøet, så skriv ned, hvor det adskiller sig fra den kommende drift. Måske bruger testmiljøet en anden betalingsopsætning, færre servere eller en kopi af produktkataloget uden rigtige priser. Forskellene behøver ikke gøre testen mindre værd, men de skal fremgå af rapporten, så ingen senere læser resultatet som en vurdering af noget, der ikke blev undersøgt. Når webshoppen er flyttet til produktion, kan en kort kontrol af de vigtigste forskelle være en god afslutning.

Betaling, plugins og hosting: afklar grænserne

En webshop er sjældent bygget helt fra bunden. Betalingen håndteres ofte af en betalingsudbyder, funktioner kommer fra plugins eller moduler, og driften ligger hos et hostingfirma. Hver af disse parter har sin egen del af ansvaret, og testen skal vide, hvor grænsen går.

Afklar med betalingsudbyderen, hvilke dele I selv står for, og hvilke dele udbyderen tester og vedligeholder. Den grænse har betydning både for testens scope og for eventuelle krav fra kortbranchen. → Betaling i webshoppen

Notér også, hvilke plugins og moduler der er i brug. De er kode, I ikke selv har skrevet, men som kører i jeres løsning og med jeres kunders data. OWASP Top 10 beskriver blandt andet sårbare og forældede komponenter som en udbredt risiko i webapplikationer.

Hvis lanceringsdatoen ikke kan flyttes

Nogle gange ligger datoen fast på grund af en kampagne, en sæson eller en aftale med en partner. Så handler det om at træffe en bevidst beslutning om de fund, der ikke kan nås. Hvilke fund skal være rettet, før webshoppen åbner, og hvilke kan vente med en midlertidig foranstaltning og en fast plan?

Den beslutning bør tages af en person med ansvar for webshoppen og skrives ned med begrundelse. Det gør det muligt at følge op efter lanceringen og at forklare valget senere. Sæt samtidig en dato for, hvornår de udskudte rettelser skal være gennemført, og hvem der kontrollerer dem. → Risikoaccept

Efter lanceringen begynder et nyt kapitel. Løbende ændringer, kampagner og nye plugins gør, at testen før åbningen ikke kan stå alene i årene efter. → Penetrationstest for webshops i drift

Det skal I lade være med

At teste en webshop uden integrationer · Ordreflow, lager og betaling er en del af den løsning, der går i drift.
At lægge testen som sidste punkt · Uden tid til rettelser bliver rapporten en liste over kendte problemer på åbningsdagen.
At lade leverandørens melding stå for en kontrol · De vigtigste rettelser skal efterprøves.
At glemme testkonti og testdata · De skal fjernes, før rigtige kunder kommer til.
At antage, at betalingsudbyderen dækker alt · Afklar grænsen for jeres eget ansvar.
At skubbe beslutningen om udeståender · Kendte rester skal godkendes af en ansvarlig.

Hvad kan og ikke kan konkluderes

En test før lancering kan vise, hvordan webshoppen stod i den opsætning og på det tidspunkt, testen blev gennemført. Sammen med efterprøvede rettelser kan den give et godt grundlag for beslutningen om at åbne.

Den kan ikke sige noget om ændringer efter testen, og den dækker kun de funktioner og integrationer, der var med i scope. Webshoppen vil ændre sig i drift, og vurderingen må følge med.