Revidere WordPress? Start med pluginene dine

Sammendrag

De fleste WordPress-sikkerhetsrevisjoner er bakvendt: de vektlegger kjernoppdateringer og skannerrapporter, mens sårbarhetene som faktisk biter, lever i plugins. En SANS-hvitbok fant at over 96 % av økosystemets sårbarheter stammer fra tredjepartsplugins, og omtrent 43 % krever ingen autentisering. Denne artikkelen går gjennom en plugin-først-revisjon for et lite internt markedsteam, ved å bruke historien om et nettsted som ble hacket fordi alle skannet feil lag. Du lærer å kartlegge og klassifisere hver plugin, teste uautentiserte angrepsflater, manuelt gjennomgå brukere og logger, og oversette funn til et riskspråk en ikke-teknisk sjef forstår. Resultatet er et kvartalsvis triageritual i stedet for en avkrysningsøvelse.

De fleste WordPress-sikkerhetsrevisjoner er teater. Du bruker en ettermiddag på å oppdatere kjernen, endre admin-passordet og kjøre en plugin-skanner som stolt rapporterer «Ingen kritiske problemer». I mellomtiden sitter plugin-en som godtok filopplastinger og sist ble oppdatert for tre år siden, stille i uploads-mappen din og venter på noen som ikke står på gjestelisten.

Tallene bekrefter dette. En SANS-hvitbok om skanning av WordPress-plugins fant at mer enn 96 % av sårbarhetene i WordPress-økosystemet stammer fra tredjepartsplugins, med temaer på 4 % og kjernen under 1 %. Omtrent 43 % av disse feilene kan utnyttes uten autentisering. Så når revisjonen din bruker mesteparten av energien på kjernen, undersøker du trærne mens en skogbrann starter i plugin-katalogen ved siden av.

Dette er ikke en oppfordring til å få panikk over kjernen. Kjernesårbarheter som wp2shell RCE-feilene som nylig fikk offentlige utnyttelser, bør lappes samme dag som de annonseres. Men de er sjeldne nok til at de ikke fortjener hovedtyngden av revisjonstimene dine. Hovedtyngden tilhører plugins, og det er der den virkelige arbeidsflyten begynner.

Se for deg før-scenariet: en søndag morgen omdirigerer nettstedet ditt til en kasinoside, og sjefen din sender e-post: «Jeg trodde vi hadde sikkerhet.» Du hadde sikkerhet — du hadde en avkrysningsrevisjon. Etter-scenariet er et triagesystem som behandler plugins som den angrepsflaten de faktisk er, tester dem fra utsiden og sjekker tingene skannere ikke kan se.

Du er i et lite markedsteam med et WordPress-nettsted som har vært i drift siden 2017. Det har en tilpasset eventregistreringsplugin som en frilanser bygget i 2019, et kontaktskjema-plugin med et filopplastingsfelt, og en slider-plugin som ble solgt og ikke lenger har en offentlig oppdateringsside. Dette er ikke en uvanlig teknisk stabel. Dette er der revisjonen din begynner.

---

Pluginoversikten er din sikkerhetspolicy

Ta oversikt over hver plugin og tema. Skriv ned versjonen, siste oppdateringsdato, om leverandøren fortsatt er aktiv, og om noen faktisk bruker den. Klassifiser deretter hver enkelt i en bøtte: vedlikeholdt og brukt, vedlikeholdt og ubrukt, forlatt men brukt, forlatt og ubrukt. Fjern de ubrukte umiddelbart. Ignorer forsvaret «det koster bare $50/måned» — en ubrukt plugin er en forpliktelse, ikke en funksjon. For de forlatte, men brukte, bestem deg: erstatt den, eller aksepter risikoen og skriv den ned i et risikoregister sjefen din har sett.

Eventregistreringspluginen faller i bøtten forlatt-men-brukt. Den tar betaling og sender bekreftelses-e-poster, og å erstatte den er et prosjekt, så du beholder den foreløpig. Men du skriver en merknad som sier: «dette er den mest sannsynlige kilden til et fremtidig brudd», og du legger den øverst på testlisten.

Angrepsflate	Andel av kjente WordPress-sårbarheter	Revisjonsprioritet
Tredjepartsplugins	Over 96 %	Høyest — oversikt, skann, test, erstatt
Temaer	Omtrent 4 %	Middels — bare hvis egendefinert eller utdatert
WordPress-kjernen	Under 1 %	Lav — hold lappet, gå videre

Da SecurityWeek talte mer enn 8 000 nye WordPress-sårbarheter i 2024, var de aller fleste av denne typen: plugin-problemer, ikke kjernelapper. En skanner forteller deg om de som er offentliggjort og har fått en CVE. Den forteller deg ikke om den egendefinerte frilanskoden uten CVE, fordi ingen noen gang har sett nøye på den. Den manuelle gjennomgangen er din jobb. For en dypere gjennomgang av pluginspesifikke sjekker, se denne veiledningen om å revidere WordPress-pluginene dine for sårbarheter.

---

Test den som en fremmed: de 43 % som ikke trenger passord

Skanneren din har allerede fortalt deg at ingenting er galt. Gjør nå det den ikke kan: sonde nettstedet fra utsiden, uten pålogging. Start med hvert filopplastingsfelt, hvert skjema som behandler en POST, hvert admin-ajax-endepunkt. Sjekker opplastingen faktisk filinnholdet, eller bare utvidelsen? Hvor havner de opplastede filene, og kan webserveren kjøre PHP i den katalogen? De 43 % av plugin-feilene som ikke krever autentisering, sitter vanligvis akkurat på disse stedene: uautentisert lagret XSS, vilkårlig filopplasting og PHP-objektinjeksjon.

Kontaktskjemapluginen lar besøkende legge ved et CV. Den endrer navnet på filen ved å bruke den besøkendes opprinnelige filnavn, så du laster opp «resume.php» og den lagres i en /uploads/contact/-mappe som er skrivbar av design. Hvis serveren også tillater å kjøre PHP i den katalogen, har angriperen nettopp fått et webshell. Fastly har dokumentert aktiv utnyttelse av uautentisert lagret XSS i WordPress-plugins — dette er ikke en nisjepresentasjonsrisiko. Testen din er enkel: lag en fil med kjent innhold, last den opp, og se om den kommer tilbake med sitt opprinnelige navn og type. Prøv deretter å laste opp en .php-fil. Hvis den kommer tilbake som .php, har du nettopp funnet et utnyttbart hull.

Det er også her argumentet «men sikkerhetspluginen vår har en WAF» bryter sammen. En WAF kan blokkere en kjent nyttelast, men sti-normaliseringsreglene den stoler på, avviker ofte fra det serveren faktisk gjør. OWASP Web Security Testing Guide er en bedre referanse enn ethvert dashbord: den beskriver hvordan du metodisk tester for filopplastingsfeil og lagret XSS. Og hvis du oppdager at pluginen er forlatt, er det på tide å bruke oppryddingsprotokollen: den skjulte faren ved forlatte WordPress-plugins forklarer hvorfor det er verre å la en død utvidelse ligge enn å fjerne den og justere arbeidsflyten.

---

Det skanneren ikke kan se: brukere, logger og gammel kode

Dynamiske tester fanger det som er eksponert akkurat nå. Den manuelle gjennomgangen fanger det som allerede er inne. Start med brukerkontoer: åpne admin-listen og se etter kontoer du ikke har opprettet. En admin som heter «support» med en gratis e-postadresse og ingen menneske bak, er en bakdør, ikke en kollega. Sjekk filtidsstempler i wp-content/uploads for noe nylig endret som ikke er innholdet ditt. Sjekk serverens tilgangslogg for forespørsler som ser ut som en bots curl-kommando snarere enn en persons nettleser.

Eventpluginen har en «speakerfoto»-opplasting som lagres i uploads/event-headshots/. Under testen finner du en fil som ikke er din — en liten PHP-fil med et tilfeldig navn. Det er webshellet ditt. Den kom dit gjennom den samme opplastingsfeilen du testet for to uker siden, og nå ville fortsatt ikke en skanner «se» den fordi den ikke er en plugin-sårbarhet; det er bevis på en. Den manuelle gjennomgangen finner den, sletter den og sjekker loggen for IP-adressen som la den der. Invicti har bemerket at PHP-objektinjeksjon i plugins er økende, og den er nesten usynlig for black-box-skannere fordi det ondsinnede objektet bare materialiseres under kjøring. Den eneste måten å oppdage den på er å lese kode for farlige mønstre som å kalle unserialize() på brukerangitt input. Å lese noen hundre linjer med den egendefinerte pluginen er billigere enn å betale for en beredskapsavtale.

Det er også her den vanlige oppfordringen om å «bare installere flere sikkerhetsplugins» når grensen sin. Å stable tre sikkerhetsplugins gir deg overlappende WAF-regler som blokkerer hverandre, en strøm av dupliserte logg-e-poster og den sporadiske «du er utestengt»-feilen på din egen admin-pålogging. Én aktiv sikkerhetsplugin, godt konfigurert, er nok. Les om hvorfor for mange sikkerhetsplugins slår tilbake før du legger noe annet til haugen.

---

Fortelle sjefen sannheten uten å utløse panikk

Sjefen din bryr seg ikke om CVSS-score eller PHP-objektinjeksjon. Han bryr seg om at nettstedet går ned, at butikken ikke tar imot bestillinger, og IT-budsjettet. Oversettelsen er enkel: «Denne pluginen har en kjent uautentisert feil som tillater ekstern kodekjøring. En fremmed kan slette nettstedsinnholdet vårt eller installere en bakdør. Vi må erstatte den dette kvartalet.» Vis deretter prioriteringslisten: erstatt eventpluginen, deaktiver kontaktskjemaets filopplasting til den validerer filtyper riktig, roter alle admin-legitimasjoner, og planlegg neste kvartalsvise gjennomgang.

Du har også en språkfordel: CISA vedlikeholder katalogen over kjente utnyttede sårbarheter, som forteller deg nøyaktig hvilke publiserte feil som aktivt brukes i naturen. Hvis noen av pluginene dine vises der, er argumentet ikke lenger teoretisk — en kjent utnyttelse finnes, og klokka tikker. Hvis de ikke gjør det, bruk den likevel som en standard for hva «haster» betyr. CISAs sporing gjør det lettere å overbevise en ikke-teknisk sjef om at dette ikke er en phishing-e-post; det er en offentlig database over hva angripere gjør akkurat nå. Når kvartalet er over, har du en utbedringsarbeidsflyt, ikke en engangsavkrysningsøvelse. En arbeidsflyt for å gjøre sårbarheter om til en lappesyklus holder vanen i live.

---

Før var et ødelagt nettsted, en hektisk e-post og en ren skannerrapport som sa at ingenting var galt. Etter er et kvartalsvis ritual: oversikt, klassifiser, test fra utsiden, gjennomgå brukere og logger, og skriv ned beslutningene du tok og risikoene du aksepterte. Skanneren blir et kart over hvor du skal se, ikke et helsesertifikat. Pluginene blir en liste du kjenner ved navn. Og neste gang sjefen din spør om revisjonen, vil du ha et svar som ikke innebærer å krysse fingrene.