Granskar du WordPress? Börja med dina plugins

Sammanfattning

De flesta WordPress-säkerhetsgranskningar är bakvända: de betonar kärnuppdateringar och skannerrapporter medan de sårbarheter som faktiskt biter lever i plugins. En SANS-vitbok fann att över 96% av ekosystemets sårbarheter härrör från tredjepartsplugins, och ungefär 43% kräver ingen autentisering. Den här artikeln går igenom en plugin-först-granskning för ett litet internt marknadsföringsteam, med hjälp av historien om en webbplats som hackades eftersom alla skannade fel lager. Du får lära dig att inventera och klassificera varje plugin, testa oautentiserade attackytor, manuellt granska användare och loggar och översätta resultat till ett riskspråk som en icke-teknisk chef förstår. Resultatet är en kvartalsvis triageritual istället för en kryssa-i-rutan-övning.

De flesta WordPress-säkerhetsgranskningar är teater. Du tillbringar en eftermiddag med att uppdatera kärnan, byta adminlösenord och köra en pluginskanner som stolt rapporterar "Inga kritiska problem". Under tiden sitter pluginprogrammet som tog emot filuppladdningar och senast uppdaterades för tre år sedan tyst i din uploads-katalog och väntar på någon som inte står på gästlistan.

Siffrorna stödjer detta. En SANS-vitbok om att skanna WordPress-plugin fann att mer än 96% av sårbarheterna i WordPress-ekosystemet härrör från tredjepartsplugins, med teman på 4% och kärnan under 1%. Ungefär 43% av dessa brister kan utnyttjas utan någon autentisering. Så när din granskning lägger större delen av sin energi på kärnan, undersöker du träden medan en skogsbrand startar i plugin-katalogen bredvid.

Detta är inte en uppmaning att få panik över kärnan. Kärnsårbarheter som wp2shell RCE-bristerna som nyligen fick offentliga exploits bör patchas samma dag som de tillkännages. Men de är tillräckligt sällsynta för att inte förtjäna merparten av dina granskningstimmar. Merparten tillhör plugins, och det är där det verkliga arbetsflödet börjar.

Föreställ dig före-scenariot: en söndagsmorgon omdirigeras din webbplats till en kasinosida, och din chef mejlar: "Jag trodde vi hade säkerhet." Du hade säkerhet — du hade en kryssa-i-rutan-granskning. Efter-scenariot är ett triagesystem som behandlar plugins som den attackyta de faktiskt är, testar dem utifrån och kontrollerar saker som skannrar inte kan se.

Du sitter i ett litet marknadsföringsteam med en WordPress-webbplats som har varit igång sedan 2017. Den har ett anpassat evenemangsregistreringsplugin som en frilansare byggde 2019, ett kontaktformulärsplugin med ett filuppladdningsfält och ett sliderplugin som såldes och inte längre har en offentlig uppdateringssida. Detta är inte en ovanlig stack. Det är här din granskning börjar.

---

Plugininventeringen är din säkerhetspolicy

Inventera varje plugin och tema. Skriv ner versionen, senaste uppdateringsdatum, om leverantören fortfarande lever och om någon faktiskt använder det. Klassificera sedan var och en i en hink: underhållen och använd, underhållen och oanvänd, övergiven men använd, övergiven och oanvänd. Ta bort de oanvända omedelbart. Ignorera försvaret "det kostar bara $50/månad" — ett oanvänt plugin är en skuld, inte en funktion. För de övergivna men använda, bestäm: ersätt det, eller acceptera risken och skriv ner det i en riskregister som din chef har sett.

Evenemangsregistreringspluginet hamnar i hinken övergiven men använd. Det tar betalningar och skickar bekräftelsemejl, och att ersätta det är ett projekt, så du behåller det tills vidare. Men du skriver en anteckning som säger: "detta är den mest troliga källan till ett framtida intrång", och du lägger till det högst upp på testlistan.

Attackyta	Andel av kända WordPress-sårbarheter	Granskningsprioritet
Tredjepartsplugins	Över 96%	Högst — inventera, skanna, testa, ersätt
Teman	Cirka 4%	Medel — endast om anpassade eller föråldrade
WordPress-kärnan	Under 1%	Låg — håll patchar, gå vidare

När SecurityWeek räknade mer än 8 000 nya WordPress-sårbarheter under 2024 var den stora majoriteten av denna typ: pluginproblem, inte kärnpatcher. En skanner berättar om de som har offentliggjorts och fått en CVE. Den berättar inte om den anpassade frilansarkoden utan CVE, eftersom ingen någonsin har tittat på den noggrant. Den manuella titten är ditt jobb. För en djupare genomgång av pluginspecifika kontroller, se den här guiden om att granska dina WordPress-plugin för sårbarheter.

---

Testa det som en främling: de 43% som inte behöver lösenord

Din skanner har redan sagt att inget är fel. Gör nu det den inte kan: sondera webbplatsen utifrån, utan inloggning. Börja med varje filuppladdningsfält, varje formulär som bearbetar en POST, varje admin-ajax-slutpunkt. Kontrollerar uppladdningen faktiskt filens innehåll, eller bara filtillägget? Var hamnar de uppladdade filerna, och kan webbservern köra PHP i den katalogen? De 43% av pluginbristerna som inte kräver autentisering sitter vanligtvis på exakt dessa ställen: oautentiserad lagrad XSS, godtycklig filuppladdning och PHP-objektinjektion.

Kontaktformulärspluginet låter besökare bifoga ett CV. Det byter namn på filen med besökarens ursprungliga filnamn, så du laddar upp "resume.php" och det sparas i en /uploads/contact/-mapp som är skrivbar av design. Om servern också tillåter att köra PHP i den katalogen har angriparen precis fått en webbskal. Fastly har dokumenterat aktiv exploatering av oautentiserad lagrad XSS i WordPress-plugin — detta är inte en nischad slide-deck-risk. Ditt test är enkelt: skapa en fil med känt innehåll, ladda upp den och se om den kommer tillbaka med sitt ursprungliga namn och typ. Försök sedan ladda upp en .php-fil. Om den kommer tillbaka som .php har du just hittat ett exploaterbart hål.

Det är också här som argumentet "men vår säkerhetsplugin har en WAF" faller samman. En WAF kan blockera en känd nyttolast, men de sökvägsnormaliseringsregler som den förlitar sig på avviker ofta från vad servern faktiskt gör. OWASP Web Security Testing Guide är en bättre referens än någon instrumentpanel: den beskriver hur man metodiskt testar för filuppladdningsbrister och lagrad XSS. Och om du upptäcker att pluginet är övergivet är det dags att tillämpa saneringsprotokollet: den dolda faran med övergivna WordPress-plugin förklarar varför det är värre att lämna en död tilläggsmodul kvar än att ta bort den och justera ditt arbetsflöde.

---

Vad skannern inte kan se: användare, loggar och gammal kod

Dynamiska tester fångar det som är exponerat just nu. Den manuella granskningen fångar det som redan finns inuti. Börja med användarkonton: öppna adminlistan och leta efter konton som du inte skapade. En admin vid namn "support" med en gratis e-postadress och ingen människa bakom är en bakdörr, inte en kollega. Kontrollera tidsstämplar för filer i wp-content/uploads för allt som nyligen ändrats som inte är ditt innehåll. Kontrollera serverns åtkomstlogg efter förfrågningar som ser ut som en bots curl-kommando snarare än en persons webbläsare.

Evenemangspluginet har en "talarbild"-uppladdning som sparar i uploads/event-headshots/. Under testet hittar du en fil som inte är din — en liten PHP-fil med ett slumpmässigt namn. Det är din webbskal. Den kom dit genom samma uppladdningsfel som du testade för två veckor sedan, och vid det här laget skulle en skanner fortfarande inte "se" den eftersom det inte är en plugin-sårbarhet; det är bevis på en sådan. Den manuella granskningen hittar den, tar bort den och kontrollerar loggen för IP-adressen som placerade den där. Invicti har noterat att PHP-objektinjektion i plugins är på uppåtgående, och den är nästan osynlig för black-box-skannningar eftersom det skadliga objektet bara materialiseras under exekvering. Det enda sättet att upptäcka det är att läsa kod efter farliga mönster som att anropa unserialize() på användarinmatade data. Att läsa några hundra rader av det anpassade pluginet är billigare än att betala en incidenthanteringskonsult.

Det är också här som det standardråd om att "bara installera fler säkerhetsplugin" når sin gräns. Att stapla tre säkerhetsplugin ger dig överlappande WAF-regler som blockerar varandra, en ström av dubbla loggmejl och enstaka "du är bannad"-fel vid din egen admininloggning. Ett aktivt säkerhetsplugin, väl konfigurerat, räcker. Läs om varför alltför många säkerhetsplugin slår tillbaka innan du lägger till något annat i högen.

---

Att berätta sanningen för din chef utan att utlösa panik

Din chef bryr sig inte om CVSS-poäng eller PHP-objektinjektion. Han bryr sig om att webbplatsen går ner, att butiken inte tar emot beställningar och IT-budgeten. Översättningen är enkel: "Det här pluginet har en känd oautentiserad fjärrkodsexekvering. En främling kan radera vårt webbplatsinnehåll eller installera en bakdörr. Vi måste ersätta det under det här kvartalet." Visa sedan prioriteringslistan: ersätt evenemangspluginet, inaktivera kontaktformulärets filuppladdning tills det validerar filtyper korrekt, rotera alla adminuppgifter och boka in nästa kvartalsvisa granskning.

Du har också ett språkligt försprång: CISA underhåller katalogen Known Exploited Vulnerabilities, som talar om exakt vilka publicerade brister som aktivt utnyttjas i naturen. Om några av dina plugins finns där är argumentet inte längre teoretiskt — en känd exploit finns, och du är på klockan. Om de inte finns, använd den ändå som en standard för vad "brådskande" betyder. CISA:s spårning gör det lättare att övertyga en icke-teknisk chef om att detta inte är ett nätfiskemejl; det är en offentlig databas över vad angripare gör just nu. När kvartalet är slut har du ett åtgärdsarbetsflöde, inte en engångsövning med kryssa-i-rutan. Ett arbetsflöde för att förvandla sårbarheter till en patchcykel håller vanan vid liv.

---

Före var en trasig webbplats, ett frenetiskt mejl och en ren skannerrapport som sa att inget var fel. Efter är en kvartalsvis ritual: inventera, klassificera, testa utifrån, granska användare och loggar, och skriv ner de beslut du fattade och de risker du accepterade. Skannern blir en karta över var du ska titta, inte ett hälsocertifikat. Plugins blir en lista du känner vid namn. Och nästa gång din chef frågar om granskningen har du ett svar som inte innebär att du håller tummarna.