Plugins og tredjepartskode: hvorfor de skal med i overvejelsen

Penetrationtest: opslagsværk om penetrationstest på dansk

Meget af den kode, der kører i en webshop eller en kundeportal, er skrevet af andre end virksomheden og dens leverandør. Om den skal med i en penetrationstest, afhænger af, hvad koden har adgang til, hvem der vedligeholder den, og om virksomheden har lov til at lade den undersøge.

Som regel hører tredjepartskoden med i overvejelsen om scope, fordi den er en del af den løsning, kunderne bruger. Men den kræver andre oplysninger og andre forbehold end den kode, jeres egen udvikler har skrevet. En test kan sige noget om, hvordan en udvidelse er installeret og opfører sig hos jer. Den kan ikke vurdere udgiverens arbejde i almindelighed.

Kode, som ingen hos jer har skrevet

Plugins, moduler, temaer og biblioteker gør det muligt at bygge en løsning hurtigt. Webshoppen får fragtberegning, nyhedsbrev og anmeldelser, uden at nogen skriver funktionerne fra bunden. Kundeportalen bruger færdige komponenter til login, formularer og visning af dokumenter.

Prisen er, at virksomheden overtager kode, den ikke kender indholdet af. Hver udvidelse har sin egen udgiver, sine egne opdateringer og sin egen tidsplan for rettelser. Nogle udgivere er store organisationer, andre er enkeltpersoner, der for længst har stoppet arbejdet. For bestilleren er det afgørende ikke, hvem der skrev koden, men at den kører med de rettigheder, løsningen giver den.

OWASP Top 10 behandler afhængigheden af komponenter fra andre som et særskilt risikoområde i webapplikationer. Kendte svagheder i udbredte komponenter registreres ofte med et nummer i et fælles katalog, så de kan genkendes på tværs af virksomheder. → CVE forklaret

Hvor tredjepartskoden findes

Start med et overblik. Tredjepartskode findes flere steder end i listen over plugins.

Udvidelser · plugins, moduler og temaer i webshoppen, på hjemmesiden eller i intranettet.
Biblioteker · færdige kodestykker, som udvikleren har bygget kundeportalen med.
Eksterne scripts · chatvinduer, statistik, cookiebannere og betalingsvinduer, som hentes fra en anden parts server.
Moduler i standardsystemer · tilkøbte funktioner i ERP-systemet eller et kundesystem.
Færdige forbindelser · koblinger mellem webshoppen og fragt, regnskab eller markedsføring.

Eksterne scripts kræver særlig opmærksomhed. De ligger ikke på jeres server, men de kører i kundens browser på jeres side. Ændres et script hos udbyderen, ændres jeres side også. PCI DSS krav 11 indeholder et krav om at opdage uautoriserede ændringer på betalingssider, sådan som kunden ser dem. Det viser, at indhold fra andre kan være en del af virksomhedens eget ansvar. → Betaling i webshoppen

Hvad testen kan sige om en udvidelse

En penetrationstest undersøger løsningen, som den er sat op hos jer. Den kan afdække, om en installeret version har en kendt svaghed, om en udvidelse giver adgang til mere, end den burde, og om dens indstillinger åbner for oplysninger, der skulle være lukket. Det er spørgsmål om jeres installation, ikke om udvidelsen i alle andre installationer.

Testen kan også vise samspillet. To udvidelser, der hver for sig er i orden, kan tilsammen give en bruger adgang til en funktion, som ingen havde tænkt sig. En formular fra ét plugin kan sende oplysninger videre til et andet. Den slags opstår i den konkrete sammensætning og står ikke i udgiverens dokumentation.

Det, testen ikke gør, er at gennemgå udgiverens kildekode i bund. En grundig gennemgang af en tredjeparts kode er en anden opgave med andre forudsætninger, og den kræver ofte udgiverens medvirken. Ligger et fund i selve udvidelsen, bliver rettelsen udgiverens sag, mens virksomheden må beslutte, hvad der gøres i mellemtiden. → Fund i tredjepartssoftware

Ansvaret ligger flere steder

Tredjepartskode har mindst tre ejere: udgiveren, der skriver den, den part, der installerer og opdaterer den, og virksomheden, der har valgt at bruge den. Er ansvaret ikke skrevet ned, falder opdateringerne let mellem to stole.

Afklar, hvem der holder hver udvidelse opdateret. Er det webbureauet, hostingfirmaet eller en medarbejder? Hvem følger med i, om udgiveren har udsendt en rettelse? En penetrationstest kan finde en forældet version på testdagen, men opdateringen bagefter hører til driften. → Patchstyring og penetrationstest

Tilladelsen er også et spørgsmål. Kode, der ligger på jeres egen server, kan normalt indgå i testen efter aftale med den, der driver serveren. Et eksternt script eller en tjeneste, der kører hos en anden part, er noget andet. Testen kan se på, hvordan tjenesten bruges på jeres side, men tjenesten selv hører til udbyderen. → Er en penetrationstest lovlig?

Det skal med i bestillingen

En test bliver mere præcis, når testeren får en liste over den kode, der ikke er jeres egen. Listen behøver ikke være teknisk. Den skal fortælle, hvad der er installeret, og hvad det bruges til.

Navn og version · for hver udvidelse, hvert modul og hvert eksternt script.
Formål · hvad funktionen gør for kunderne eller medarbejderne.
Rettigheder · om udvidelsen kan se kundedata, ordrer eller administrationsdelen.
Ejer · hvem der opdaterer, og hvem der har kontakten til udgiveren.
Status · om udvidelsen er i brug, eller om den blot er installeret.

Spørg også den, der har bygget løsningen, om noget af koden er tilpasset. En udvidelse, som udvikleren har ændret i, er ikke længere den samme som udgiverens version. En opdatering fra udgiveren kan overskrive tilpasningen, eller tilpasningen kan forhindre opdateringer. Det er en oplysning, som både testeren og den driftsansvarlige har brug for.

Listen har værdi i sig selv. En udvidelse, der ikke bruges, kan fjernes, og en udvidelse uden aktiv udgiver kan udskiftes. Sådanne beslutninger kræver ikke en tester. Hvordan en hjemmeside på WordPress vurderes, er beskrevet i → Ny hjemmeside på WordPress.

Det skal I lade være med

At antage, at populære udvidelser er gennemprøvede · udbredelse siger intet om jeres version eller opsætning.
At glemme de scripts, der hentes udefra · de kører på jeres sider, selv om de ligger hos andre.
At lade ubrugte udvidelser blive liggende · det, der er installeret, kan stadig nås.
At teste en anden parts tjeneste uden lov · lov til test gives af den part, som driver tjenesten.
At bruge testen i stedet for opdateringer · rapporten beskriver én dag, mens nye versioner kommer løbende.

Hvad kan og ikke kan konkluderes

En test kan vise, om de udvidelser og scripts, der var med, havde svagheder i den version og opsætning, som blev undersøgt. Den kan ikke sige noget om senere versioner, nye udvidelser eller udgiverens øvrige kode. Rapporten bør nævne versionerne, så resultatet senere kan holdes op mod den aktuelle løsning.

Et resultat uden fund i en udvidelse er en oplysning om jeres installation på testdagen. Det er ikke en godkendelse af udgiveren.

Tjekliste over tredjepartskoden

☐ Er udvidelser, moduler og biblioteker listet med version?
☐ Er eksterne scripts på siderne med på listen?
☐ Er det angivet, hvad hver udvidelse har adgang til?
☐ Har hver udvidelse en ejer, der står for opdateringer?
☐ Er ubrugte udvidelser fjernet før testen?
☐ Er det afklaret, hvilke tjenester der tilhører andre?

Kilder

OWASP Top 10: komponenter fra andre og forsyningskæden i software som risikoområde i webapplikationer.
CVE: det fælles katalog over kendte sårbarheder.
PCI DSS krav 11 (Microsoft Learn): krav 11.6.1 om at opdage uautoriserede ændringer på betalingssider.

Senest gennemgået: oktober 2026.