Når webshoppen sender ordrer til ERP-systemet, eller kundeportalen henter oplysninger fra økonomisystemet, er forbindelsen mellem dem et system i sig selv med egne konti, egne rettigheder og egne svagheder. Den skal med i testen, når den flytter følsomme data eller giver adgang til et vigtigt system, og bestillingen skal beskrive, hvilke forbindelser der indgår, og hvor den anden ende ligger.
Integrationer overses let, fordi de ikke har et skærmbillede. De kører i baggrunden og bliver først bemærket, når de holder op med at virke. Netop derfor kan de rumme adgange, som ingen har set på i lang tid.
Forbindelsen er et system for sig
En test af en webapplikation ser typisk på de funktioner, brugerne møder. Integrationerne ligger bagved og bliver kun en del af testen, hvis bestillingen nævner dem. Hvordan en webløsning bestilles som helhed, står i → Penetrationstest af webapplikationer. Her er vinklen forbindelserne selv.
En integration kan være et API, en filoverførsel med faste mellemrum, en integrationsplatform, der flytter data mellem flere systemer, eller en direkte forbindelse til en database. Formen har betydning for, hvordan den kan undersøges, men for køberen er spørgsmålene de samme: hvad flytter den, hvem kan bruge den, og hvad stoler den på?
Når integrationen er et API, hører den også under → API-test forklaret for købere.
Lav et kort over strømmene
Før testen bør virksomheden tegne, hvilke systemer der taler sammen, og hvilke data der flyttes. Et simpelt kort er nok. Det skal vise retningen og indholdet af hver forbindelse.
- Webshoppen og ERP-systemet · ordrer, kunder og lagerstatus i begge retninger.
- Kundeportalen og økonomisystemet · fakturaer og betalingsstatus.
- Lønsystemet og bogføringen · oplysninger om medarbejdere og udbetalinger.
- Eksterne partnere · fragtfirmaer, betalingsudbydere og andre, der modtager eller sender data.
Kortet viser, hvilke forbindelser der er mest følsomme, og det gør det lettere at vælge. Det afslører også ofte gamle integrationer, som ikke længere bruges, men aldrig er lukket. Systemet i centrum er ofte ERP-systemet. → ERP-systemet i en penetrationstest
Konti, som ingen logger ind med
Integrationer bruger konti, der ikke tilhører en person. De er oprettet til, at et system kan tale med et andet, og de har ofte brede rettigheder, fordi det var lettest, da integrationen blev sat op.
Bestillingen kan spørge, om disse konti kun har de rettigheder, integrationen kræver, om adgangsoplysningerne er beskyttet, og om nogen ved, hvem der ejer kontoen. En konto, der kan læse og skrive alt i ERP-systemet, er et attraktivt mål, også selv om integrationen kun skulle overføre ordrer.
Spørgsmålet er ikke, hvordan testeren skal finde kontoen, men hvad virksomheden vil vide om den. Formulér det som et krav til resultatet: rapporten skal sige, om integrationens rettigheder svarer til dens opgave.
Mange integrationskonti bliver oprettet af den leverandør, der byggede forbindelsen, og adgangsoplysningerne ligger nogle gange kun hos leverandøren. Hvis ingen hos virksomheden ved, hvor oplysningerne opbevares, eller hvem der kan skifte dem, er det et forhold, der bør afklares, uanset hvad testen viser. Notér ejeren af hver konto på kortet over strømmene.
Tillid mellem systemerne
Et system, der modtager data fra et andet system, stoler ofte på dem uden at kontrollere dem på samme måde, som det ville kontrollere data fra en bruger. Hvis den ene ende kan påvirkes, kan det få betydning for den anden.
OWASP’s oversigt over risici ved API’er nævner usikker brug af data fra andre API’er som en risiko i sig selv. For køberen betyder det, at testen kan spørge, om ERP-systemet behandler data fra webshoppen med passende forsigtighed, og om en fejl i den ene ende kan føre til mere adgang i den anden. Spørgsmålet er særligt relevant, når et API åbnes for partnere. → Når et API åbnes for partnere
Den anden ende af forbindelsen
Mange integrationer går til systemer, som virksomheden ikke selv ejer. Fragtfirmaets system, betalingsudbyderens platform og leverandørens skytjeneste kan ikke testes uden ejerens tilladelse.
Afgræns derfor hver forbindelse. Testen kan ofte undersøge virksomhedens egen ende: hvad der sendes, hvordan det modtages, og hvilke rettigheder der er givet. Den anden ende må stå som en undtagelse, medmindre ejeren har givet lov. Notér undtagelserne i bestillingen, så rapporten kan vise, hvilke dele af forbindelsen der ikke blev vurderet. En læser skal kunne se forskel på en forbindelse uden fund og en forbindelse, hvor kun den ene halvdel indgik.
Virksomhedens aftaler med partnerne kan også have betydning. Nogle aftaler kræver, at partneren orienteres om test, der kan påvirke deres systemer, også selv om testen kun foregår i virksomhedens egen ende. Hvis testen finder et problem i et produkt, som en leverandør står for, er det beskrevet i → Fund i tredjepartssoftware.
Testdata, der rejser videre
En integration gør, hvad den er sat op til. Hvis testeren opretter en ordre i webshoppen, kan den blive sendt videre til ERP-systemet, fragtfirmaet og bogføringen. Det kan give rigtige forsendelser, rigtige fakturaer eller forvirring hos en partner.
Aftal på forhånd, hvordan testdata håndteres. Kan testen foregå i et testmiljø, hvor integrationerne peger på testsystemer? Skal bestemte forbindelser slås fra under testen? Hvem rydder op i systemerne bagefter? Partnere, der kan modtage testdata, bør have besked, så en uventet ordre ikke bliver behandlet som rigtig. Valget mellem produktion og testmiljø har særlig betydning her, fordi integrationerne ofte er sat anderledes op i de to. → Penetrationstest i produktion eller testmiljø
Det skal I lade være med
- At nøjes med brugernes funktioner · integrationerne kommer kun med, hvis bestillingen nævner dem.
- At bestille uden et kort · tegn strømmene, før scope skrives.
- At overse integrationskonti · de har ofte bredere rettigheder end nødvendigt.
- At teste den anden ende uden lov · partnernes systemer kræver ejerens tilladelse.
- At glemme testdata · ordrer og fakturaer kan rejse videre til rigtige partnere.
- At lade gamle integrationer stå · forbindelser, der ikke bruges, bør lukkes, før de testes.
Hvad kan og ikke kan konkluderes
En test kan vise, hvordan de udvalgte forbindelser og deres konti fremstod på testtidspunktet, og om virksomhedens egen ende behandlede data som forventet. Den kan pege på rettigheder, der er bredere end opgaven kræver.
Den kan ikke sige noget om partnernes systemer ud over det, der var aftalt, og den kan ikke vise, hvordan en integration opfører sig efter næste opdatering i den ene ende. Nye forbindelser skal vurderes for sig.
Tjekliste til integrationerne
- ☐ Findes der et kort over forbindelser og dataflow?
- ☐ Er det valgt, hvilke forbindelser testen omfatter?
- ☐ Er integrationskonti og deres ejere kendt?
- ☐ Er den anden ende afgrænset for hver forbindelse?
- ☐ Er håndteringen af testdata aftalt?
- ☐ Er valget mellem produktion og testmiljø truffet?
Kilder
- OWASP API Security Project: oversigt over risici ved API’er, herunder usikker brug af data fra andre API’er.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: ERP-systemet i en penetrationstest · Testkonti og testdata
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
