Revidér WordPress? Start med dine plugins

Resumé

De fleste WordPress-sikkerhedsrevisioner er bagvendte: de lægger vægt på kerneopdateringer og scannerrapporter, mens de sårbarheder, der faktisk bider, lever i plugins. En SANS-hvidbog viste, at over 96 % af økosystemets sårbarheder stammer fra tredjepartsplugins, og omkring 43 % kræver ingen autentificering. Denne artikel gennemgår en plugin-først-revision for et lille internt marketingteam ved hjælp af historien om et websted, der blev hacket, fordi alle scannede det forkerte lag. Du lærer at opgøre og klassificere hvert plugin, teste uautentificerede angrebsflader, manuelt gennemgå brugere og logfiler og oversætte resultaterne til et risksprog, som en ikke-teknisk chef forstår. Resultatet er et kvartalsvist triage-ritual i stedet for en afkrydsningsøvelse.

De fleste WordPress-sikkerhedsrevisioner er teater. Du bruger en eftermiddag på at opdatere kernen, ændre admin-adgangskoden og køre en plugin-scanner, der stolt rapporterer "Ingen kritiske problemer." I mellemtiden sidder det plugin, der accepterede filupload og sidst blev opdateret for tre år siden, stille og roligt i din uploads-mappe og venter på en, der ikke står på gæstelisten.

Tallene bakker dette op. En SANS-hvidbog om scanning af WordPress-plugins viste, at mere end 96 % af sårbarhederne i WordPress-økosystemet stammer fra tredjepartsplugins, med temaer på 4 % og kernen under 1 %. Omkring 43 % af disse fejl kan udnyttes uden nogen autentificering. Så når din revision bruger det meste af sin energi på kernen, undersøger du træerne, mens en skovbrand starter i plugin-mappen ved siden af.

Dette er ikke en opfordring til panik omkring kernen. Kerne-sårbarheder som wp2shell RCE-fejlene, der for nylig fik offentlige exploits, bør patche den dag, de annonceres. Men de er sjældne nok til, at de ikke fortjener hovedparten af dine revisionstimer. Hovedparten tilhører plugins, og det er der, den virkelige arbejdsgang begynder.

Forestil dig før-scenariet: en søndag morgen omdirigerer dit websted til en kasinoside, og din chef sender en e-mail: "Jeg troede, vi havde sikkerhed." Du havde faktisk sikkerhed — du havde en afkrydsningsrevision. Efter-scenariet er et triagesystem, der behandler plugins som den angrebsflade, de faktisk er, tester dem udefra og tjekker de ting, scannere ikke kan se.

Du er på et lille marketingteam med et WordPress-websted, der har kørt siden 2017. Det har et tilpasset eventregistreringsplugin, som en freelancer byggede i 2019, et kontaktformularplugin med et filuploadfelt og et slider-plugin, der blev solgt og ikke længere har en offentlig opdateringsside. Dette er ikke en usædvanlig stak. Det er her, din revision starter.

---

Plugin-opgørelsen er din sikkerhedspolitik

Tag opgørelse over hvert plugin og tema. Skriv versionen ned, den seneste opdateringsdato, om leverandøren stadig er aktiv, og om nogen faktisk bruger det. Klassificér derefter hvert enkelt i en kategori: vedligeholdt og brugt, vedligeholdt og ubrugt, forladt men brugt, forladt og ubrugt. Fjern de ubrugte med det samme. Ignorer forsvaret "det koster kun $50 om måneden" — et ubrugt plugin er en forpligtelse, ikke en funktion. For de forladte, men brugte, skal du beslutte: erstat det, eller accepter risikoen og skriv det ned i et risikoregister, som din chef har set.

Eventregistreringspluginet falder i kategorien forladt, men brugt. Det tager betalinger og sender bekræftelsesmails, og at erstatte det er et projekt, så du beholder det foreløbigt. Men du skriver en note, der siger: "dette er den mest sandsynlige kilde til et fremtidigt brud," og du tilføjer det til toppen af testlisten.

Angrebsflade	Andel af kendte WordPress-sårbarheder	Revisionsprioritet
Tredjepartsplugins	Over 96%	Højeste — opgør, scan, test, erstat
Temaer	Cirka 4%	Middel — kun hvis tilpassede eller forældede
WordPress-kernen	Under 1%	Lav — hold patchet, gå videre

Da SecurityWeek talte mere end 8.000 nye WordPress-sårbarheder i 2024, var langt de fleste af denne type: plugin-problemer, ikke kerneopdateringer. En scanner fortæller dig om dem, der er blevet offentliggjort og har fået en CVE. Den fortæller dig ikke om den tilpassede freelancer-kode uden CVE, fordi ingen nogensinde har set nøje på den. Det manuelle blik er din opgave. For en dybere gennemgang af pluginspecifikke tjek, se denne guide til at revidere dine WordPress-plugins for sårbarheder.

---

Test det som en fremmed: de 43 %, der ikke kræver adgangskode

Din scanner har allerede fortalt dig, at der ikke er noget galt. Gør nu det, den ikke kan: sondér webstedet udefra uden login. Start med hvert filuploadfelt, hver formular, der behandler en POST, hvert admin-ajax-endepunkt. Tjekker uploadet faktisk filens indhold eller kun filtypen? Hvor lander de uploadede filer, og kan webserveren udføre PHP i den mappe? De 43 % af plugin-fejlene, der ikke kræver autentificering, sidder normalt præcis disse steder: uautentificeret lagret XSS, vilkårlig filupload og PHP-objektinjektion.

Kontaktformularpluginet lader besøgende vedhæfte et CV. Det omdøber filen ved hjælp af den besøgendes oprindelige filnavn, så du uploader "resume.php", og det gemmer den i en /uploads/contact/-mappe, der er skrivbar efter design. Hvis serveren også tillader at køre PHP i den mappe, har angriberen lige fået en webshell. Fastly har dokumenteret aktiv udnyttelse af uautentificeret lagret XSS i WordPress-plugins — dette er ikke en niche-risiko fra en præsentation. Din test er enkel: opret en fil med kendt indhold, upload den, og se, om den kommer tilbage med sit oprindelige navn og type. Prøv derefter at uploade en .php-fil. Hvis den kommer tilbage som .php, har du lige fundet et udnytteligt hul.

Det er også her, argumentet "men vores sikkerhedsplugin har en WAF" bryder sammen. En WAF kan blokere en kendt payload, men de sti-normaliseringsregler, den er afhængig af, afviger ofte fra, hvad serveren faktisk gør. OWASP Web Security Testing Guide er en bedre reference end noget dashboard: den beskriver, hvordan man metodisk tester for filupload-fejl og lagret XSS. Og hvis du opdager, at pluginet er forladt, er det tid til at anvende oprydningsprotokollen: den skjulte fare ved forladte WordPress-plugins forklarer, hvorfor det er værre at lade en død udvidelse blive på plads end at fjerne den og justere din arbejdsgang.

---

Hvad scanneren ikke kan se: brugere, logfiler og gammel kode

Dynamiske test fanger det, der er eksponeret lige nu. Den manuelle gennemgang fanger det, der allerede er indeni. Start med brugerkonti: Åbn admin-listen, og se efter konti, du ikke har oprettet. En admin med navnet "support" med en gratis mailadresse og intet menneske bag er en bagdør, ikke en kollega. Tjek fil-tidsstempler i wp-content/uploads for noget, der for nylig er ændret, og som ikke er dit indhold. Tjek serveradgangsloggen for anmodninger, der ligner en bots curl-kommando snarere end en persons browser.

Eventpluginet har en upload til "speakerfoto", der gemmer i uploads/event-headshots/. Under testen finder du en fil, der ikke er en af dine — en lille PHP-fil med et tilfældigt udseende navn. Det er din webshell. Den kom der gennem den samme upload-fejl, du testede for to uger siden, og nu ville en scanner stadig ikke "se" den, fordi det ikke er en plugin-sårbarhed; det er bevis på en. Den manuelle gennemgang finder den, sletter den og tjekker loggen for den IP-adresse, der lagde den der. Invicti har bemærket, at PHP-objektinjektion i plugins er stigende, og den er næsten usynlig for black-box-scanninger, fordi det ondsindede objekt først materialiseres under udførelse. Den eneste måde at opdage det på er at læse kode for farlige mønstre som at kalde unserialize() på brugerleveret input. At læse et par hundrede linjer af det tilpassede plugin er billigere end at betale en incident-response-retainer.

Det er også her, det standardråd om at "bare installere flere sikkerhedsplugins" når sin grænse. Hvis du stabler tre sikkerhedsplugins, får du overlappende WAF-regler, der blokerer hinanden, en strøm af dobbelte logmails og lejlighedsvis en "du er udelukket"-fejl på dit eget admin-login. Ét aktivt sikkerhedsplugin, der er konfigureret godt, er nok. Læs om hvorfor for mange sikkerhedsplugins giver bagslag, før du tilføjer noget andet til bunken.

---

Sig sandheden til din chef uden at skabe panik

Din chef er ligeglad med CVSS-score eller PHP-objektinjektion. Han bekymrer sig om, at webstedet går ned, at butikken ikke tager imod ordrer, og IT-budgettet. Oversættelsen er enkel: "Dette plugin har en kendt uautentificeret fjernkodeudførelsesfejl. En fremmed kan slette vores webstedsindhold eller installere en bagdør. Vi skal erstatte det i dette kvartal." Vis derefter prioritetslisten: erstat eventpluginet, deaktiver kontaktformularens filupload, indtil den validerer filtyper korrekt, roter alle admin-legitimationsoplysninger, og planlæg den næste kvartalsvise gennemgang.

Du har også en sproglig fordel: CISA vedligeholder kataloget over kendte udnyttede sårbarheder, som fortæller dig præcis, hvilke offentliggjorte fejl der aktivt udnyttes i naturen. Hvis nogle af dine plugins optræder der, er argumentet ikke længere teoretisk — en kendt exploit findes, og uret tikker. Hvis de ikke gør, så brug det alligevel som en standard for, hvad "haster" betyder. CISAs sporing gør det lettere at overbevise en ikke-teknisk chef om, at dette ikke er en phishing-mail; det er en offentlig database over, hvad angribere gør lige nu. Når kvartalet slutter, vil du have en afhjælpningsarbejdsgang, ikke en engangs-afkrydsningsøvelse. En arbejdsgang til at omdanne sårbarheder til en patch-cyklus holder vanen i live.

---

Før-scenariet var et ødelagt websted, en hektisk e-mail og en ren scannerrapport, der sagde, at der ikke var noget galt. Efter-scenariet er et kvartalsritual: opgør, klassificér, test udefra, gennemgå brugere og logfiler, og skriv de beslutninger, du traf, og de risici, du accepterede, ned. Scanneren bliver et kort over, hvor du skal kigge, ikke et sundhedscertifikat. Pluginsene bliver en liste, du kender ved navn. Og næste gang din chef spørger til revisionen, vil du have et svar, der ikke involverer at krydse fingre.