Hva er en sikkerhetsrevisjon av WordPress
En sikkerhetsrevisjon er en skriftlig gjennomgang av ett WordPress-nettsted. Jeg heter Mariusz Szatkowski, har jobbet med WordPress siden 2006 og gjør revisjonen selv. Du får en rapport med funnene sortert etter hvor alvorlige de er, og et konkret tiltak for hvert av dem. Utbedringen kan du la din egen utvikler gjøre, eller bestille av meg som et eget oppdrag.
WordPress driver over 40 % av alle nettsteder ifølge W3Techs, og automatiserte roboter prøver kjente hull på dem hele døgnet. Revisjonen gir deg ingen garanti mot nye innbrudd. Den viser hvor nettstedet ditt står i dag, og hva som bør gjøres først.
Hva revisjonen omfatter
- Utvidelser og temaer: versjoner, kjente sårbarheter i WPScan og Patchstack, forlatte utvidelser og manuell kodegjennomgang av dem som tar imot brukerinput.
- Brukere: administratorkontoer, roller, Application Passwords og tofaktorinnlogging.
- Konfigurasjon:
wp-config.php, filrettigheter, filredigereren i kontrollpanelet, XML-RPC og det offentlige users-endepunktet i REST API. - Server: sikkerhetshoder i HTTP-svarene, TLS, PHP-versjon og om PHP kan kjøres i
uploads. - Sikkerhetskopier: hvor de ligger, hvor lenge de oppbevares, og om noen har prøvd å gjenopprette fra dem.
- Spor etter innbrudd: sjekksummer for kjernefiler, ukjente PHP-filer, databasen og logger.
Hvordan blir WordPress-sider hacket
De fleste innbruddene jeg rydder opp etter, går tilbake til noen få mønstre. Kjenner du dem, vet du hva du skal se etter i kode og logger.
Typiske sårbarhetsmønstre i utvidelser
- REST-endepunkter registrert med
permission_callback => '__return_true', slik at hvem som helst kan kalle dem uten innlogging. - Lagret XSS via kortkoder som skriver ut
$_GETeller metadata utenwp_kses_post(). - Vilkårlig filopplasting gjennom AJAX-handlere som godtar filen, men hopper over
wp_check_filetype_and_ext(). - Rettighetseskalering gjennom innstillinger som lagres uten nonce- og rettighetssjekk.
Revisjonen sjekker installerte utvidelser mot WPScan og Patchstack, og leser deretter selve kildekoden etter mønstrene over. En database over kjente sårbarheter fanger ikke hull som ennå ikke er registrert. AI-generert kode har ofte nettopp disse hullene: manglende nonce- og rettighetssjekker og usanitert $_GET rett ut på siden. Er nettstedet ditt bygd med et AI-verktøy, se redning av AI-bygde nettsider. Funn i egenutviklet kode retter jeg etter revisjonen som WordPress-spesialist.
Brukerenumerasjon i WordPress
?author=1 sender videre til /author/<slug>/ og avslører innloggingsnavnet til administratoren. Det samme gjelder /wp-json/wp/v2/users på installasjoner som aldri har stengt det offentlige users-endepunktet. På et herdet nettsted bør begge gi 404 eller en tom liste.
XML-RPC-angrep med system.multicall
/xmlrpc.php er et yndet mål for brute force. Med system.multicall kan én POST-forespørsel inneholde mange forsøk på wp.getUsersBlogs, så vanlig begrensning av innloggingsforsøk ser bare én forespørsel. Bruker du ikke Jetpack eller WordPress-appen, kan XML-RPC slås helt av. Bruker du dem, begrenser du tilgangen i brannmuren foran nettstedet.
Sjekkliste for WordPress-sikkerhetsrevisjon
Revisjonen følger samme rekkefølge hver gang, slik at to rapporter for samme nettsted kan sammenlignes.
| Trinn | Hva jeg gjør | Verktøy |
|---|---|---|
| 1. Ekstern skanning | Synlige infeksjoner, svartelister (Google Safe Browsing), sikkerhetshoder | WPScan, Sucuri SiteCheck |
| 2. Kjernefiler | Sammenligning med offisielle sjekksummer, søk etter bakdører | WP-CLI |
| 3. Utvidelser og temaer | Kjente sårbarheter, forlatte utvidelser, kodegjennomgang | WPScan, Patchstack |
| 4. Database | Injisert innhold, ukjente administratorer, skript i wp_options | SQL, WP-CLI |
| 5. Serverlogger | Spor etter inntrengning i access.log og error.log | SSH, grep, awk |
Ekstern skanning viser det en besøkende og Google ser: om nettstedet står på en svarteliste, om HTML-en inneholder fremmed kode, og om HTTP-sikkerhetshodene er satt.
Kjernefiler sjekkes med wp core verify-checksums. Avvik betyr endrede filer. Mappen wp-content dekkes ikke av sjekksummene, så den går jeg gjennom manuelt.
Utvidelser og temaer med kjente sårbarheter eller uten vedlikehold havner øverst i rapporten. En forlatt utvidelse bør byttes ut eller fjernes.
Databasen er ofte stedet der en infeksjon overlever en opprydding i filene: spam-lenker, skjulte administratorkontoer og skript lagret i wp_options.
Serverlogger viser mistenkelige forespørsler, uvanlige brukeragenter og forsøk på kjente sårbare endepunkter. Uten logger kan ingen si sikkert hvordan angriperen kom inn.
Vanligste skadevare i WordPress
Tre typer går igjen. Hvordan jeg rydder opp etter dem, står på siden om å fjerne skadevare fra WordPress.
1. Pharma-hack og japansk SEO-spam
Angriperen legger inn tusenvis av sider med japanske eller kinesiske tegn som reklamerer for falske produkter. Søk etter site:dittdomene.no i Google og se etter sider du ikke har laget. Sjekk også wp_posts etter innhold med uvanlige tegnsett.
2. Ondsinnede omdirigeringer
Besøkende sendes videre til gambling- eller pornonettsteder, ofte bare fra mobil, bare fra Google eller bare i visse land. Derfor ser eieren sjelden problemet selv. Omdirigeringen sitter som regel i header.php, .htaccess eller JavaScript i databasen.
3. PHP-bakdører
Skjulte skript, ofte kodet med base64, lar angriperen komme tilbake etter at passordene er byttet. De ligger gjerne i /wp-content/uploads/, i /wp-includes/ eller inne i en ellers legitim utvidelse. Hver mistenkelig fil må leses, ellers risikerer du å slette noe butikken trenger.
Sikkerhetsrevisjon av KI-bygde nettsteder og KI-utvidelser
Nettsteder bygd eller utvidet med KI-verktøy feiler revisjonen av forutsigbare grunner: manglende nonces, usaniterte inndata, åpne REST-ruter og mange utvidelser lagt til etter hverandre.
| Lag | Sjekk | Typisk funn |
|---|---|---|
| Kode | Egne utvidelser, functions.php | Manglende rettighetssjekker, SQL satt sammen av strenger |
| Flater | REST, AJAX, opplastinger | permission_callback => '__return_true' |
| Innhold | Duplikater, tall uten kilde | Påstander som ingen har kontrollert |
En egen risikoklasse er utvidelser som med vilje gir en KI-agent PHP-kjøring, databasespørringer og filoperasjoner, via MCP, CLI eller webhook. En CVE-skanner melder ingenting om dem, fordi funksjonen er dokumentert og tilsiktet. Risikoen ligger i hvem som har nøkkelen. Derfor har revisjonen fem ekstra punkter:
- Liste over utvidelser som gir KI-styrt kodekjøring, databasetilgang eller filoperasjoner.
- For hver: krever endepunktet autentisering, og er det nåbart fra internett.
- Hvor nøklene ligger (
wp-config.php, options-tabellen, miljøvariabler) og hvem som kan lese dem. - Om operasjonene logges slik at de kan rekonstrueres etter en hendelse.
- Min standardanbefaling: ikke i produksjon, og på staging bare med en liste over tillatte IP-adresser.
Utbedring går via redning av KI-bygde nettsider, koden via revisjon av KI-generert plugin-kode og innholdet via AI-slop-opprydding.
Herding av WordPress: hva rapporten anbefaler
Herdingen står i rapporten som tiltak i prioritert rekkefølge. Du kan gjennomføre dem selv, overlate dem til din utvikler eller bestille dem av meg.
wp-config.php. DISALLOW_FILE_EDIT slår av kodeeditoren i kontrollpanelet. FORCE_SSL_ADMIN tvinger HTTPS i administrasjonen. Filen bør eies av brukeren som deployer, ikke av webserveren, og ikke kunne skrives av webserveren. API-nøkler til Vipps, Stripe eller Klarna bør ligge i miljøvariabler utenfor webroten. Ligger de i en fil som en bakdør i uploads kan lese, får angriperen også tilgang til betalingskontoen.
Hemmeligheter. De åtte saltene (AUTH_KEY, SECURE_AUTH_KEY og resten) byttes via generatoren på wordpress.org, noe som logger ut alle økter. Hvert Application Password som ikke hører til en kjent integrasjon, trekkes tilbake.
Innlogging. Tofaktorinnlogging med TOTP, for eksempel med utvidelsen Two Factor eller Wordfence Login Security, og en dokumentert reservevei via WP-CLI når en telefon blir borte. Begrens antall forsøk mot /wp-login.php i brannmuren foran nettstedet, ikke bare i PHP.
Filsystem. PHP-kjøring slått av i /wp-content/uploads/ med en regel i .htaccess eller en tilsvarende nginx-blokk. Katalogvisning av. xmlrpc.php sperret hvis nettstedet ikke trenger det.
Deteksjon. En daglig sammenligning av kjerne- og utvidelsesfiler med offisielle sjekksummer (wp core verify-checksums, wp plugin verify-checksums --all), varsel om nye administratorkontoer og overvåking av innloggingsforsøk i access-loggen. Virksomheter som følger NSMs grunnprinsipper for IKT-sikkerhet kan bruke rapporten som en del av sin egen sårbarhetshåndtering.
Typiske funn etter et innbrudd
Den skjulte administratoren. Et sårbart skjema-tillegg lar angriperen opprette en bruker med rollen administrator og et uskyldig navn som «Support». Å gjenopprette forrige ukes sikkerhetskopi hjelper ikke hvis kontoen ble laget før den. Jeg sammenligner wp_users og wp_usermeta med det siste kjente rene øyeblikksbildet i stedet for å stole på brukerlisten i kontrollpanelet.
Bakdøren i uploads. En fil som /wp-content/uploads/2024/03/.cache.php tar imot base64-kode via POST og kjører den med eval(). En gjenoppretting som bare gjelder kjernen og utvidelsene, lar den leve videre. Revisjonen leter etter alle .php, .phtml og .phar i uploads og sjekker at PHP-kjøring er slått av der.
Nøkkelen i et offentlig repository. En .env-fil med SMTP-passord eller betalingsnøkler havner på GitHub, og e-posttjenesten blir brukt til spam. Nøklene må byttes, git-historikken renskes med git filter-repo, og en pre-commit-krok bør stoppe neste .env. Jeg ser etter .env, .env.backup og andre filer under webroten som inneholder DB_PASSWORD eller nøkler.
Nettstedet er hacket: hva du gjør den første timen
- Ikke slett noe. Ta en kopi av filer og database slik de er nå. De infiserte filene viser hvordan angriperen kom inn.
- Bytt passord fra en ren enhet: WordPress, webhotell, SFTP, database, betalings- og e-postnøkler. Logg ut alle økter.
- Sett nettstedet i vedlikeholdsmodus hvis det sprer skadelig kode, sender besøkende videre eller samler inn data fra skjemaer.
- Be webhotellet om
access.logogerror.logog spør hvor lenge de lagres. - Sjekk Google Search Console. En ukjent eier er et vanlig tegn på innbrudd. Fjern den når kopien er sikret.
- Noter tidspunktet du oppdaget bruddet. Fristen for melding løper fra da.
Må du melde fra til Datatilsynet?
Beslutningen er din som behandlingsansvarlig, eventuelt sammen med personvernombudet. Personvernforordningen gjelder som norsk lov gjennom personopplysningsloven. Etter artikkel 33 skal et brudd meldes til Datatilsynet uten ugrunnet opphold og om mulig senest 72 timer etter at du fikk kjennskap til det, med mindre bruddet sannsynligvis ikke medfører risiko for personers rettigheter og friheter. Alle brudd skal dokumenteres internt, også de som ikke meldes (artikkel 33 nr. 5). Er risikoen høy, skal de registrerte også varsles etter artikkel 34.
Er virksomheten din omfattet av digitalsikkerhetsloven, som gjelder fra 1. oktober 2025 og gjennomfører NIS-direktivet (EU) 2016/1148, har du egne plikter i tillegg. Om loven gjelder for deg, må du avklare selv.
Fra meg får du det juristen eller personvernombudet trenger for vurderingen: lå det personopplysninger i databasen, kunne angriperen nå dem, og fra hvilket tidspunkt.
Hvordan foregår oppryddingen?
Jeg jobber på en kopi. Først inngangen (logger, sjekksummer, sammenligning av utvidelses- og temafiler), så fjerning av skadelig kode og bakdører i filer og database, kontroll av administratorkontoer og cron-jobber, ny installasjon av kjernen og utvidelsene fra rene kilder og bytte av alle hemmeligheter. Til slutt en kontrollskanning og, hvis Google har flagget nettstedet, en forespørsel om ny vurdering. Hvor lang tid det tar, avhenger av hvor mye som er infisert og om det finnes logger, så anslaget kommer etter at jeg har sett nettstedet.
Hva inneholder rapporten fra sikkerhetsrevisjonen
- Funnliste sortert som kritisk, høy, middels og lav. Hvert funn har en beskrivelse av risikoen, bevis i form av logguttrekk, filsti eller skjermbilde, CVE-referanse der den finnes, og et tiltak skrevet slik at utvikleren din kan gjennomføre det.
- Rekkefølge for utbedring, slik at det som kan utnyttes i dag, kommer først.
- Det som ikke ble kontrollert, for eksempel fordi tilgang manglet. Da vet du hva rapporten ikke dekker.
Rapporten kommer som et dokument på e-post. Spørsmål til den tar vi skriftlig. Finner jeg noe kritisk underveis, som en aktiv bakdør, sier jeg fra med en gang i stedet for å vente på rapporten.
Hvilke tilganger trengs for en WordPress-revisjon
Revisjonen gjøres eksternt. Før jeg får tilgang, signerer vi en databehandleravtale etter GDPR artikkel 28.
- Midlertidig administratorkonto i WordPress med tofaktorinnlogging. Du oppretter den for revisjonen og sletter den etterpå.
- SFTP- eller SSH-tilgang til serveren. Uten den kan jeg ikke sjekke kjernefilene med WP-CLI, filrettighetene, loggene eller bakdører i
uploads, og den delen av rapporten blir tom. - Liste over integrasjoner og viktige utvidelser: navn, om den er aktiv, og én setning om hva den gjør. Da kan jeg prioritere kodegjennomgangen av dem som tar imot brukerinput.
Nyttig, men valgfritt: tilgang til Google Search Console, forrige revisjonsrapport og varslene fra Wordfence, Sucuri eller Patchstack hvis du bruker dem.
Er en gratis sikkerhetsutvidelse nok?
Wordfence, Sucuri og Patchstack er gode til å stoppe kjente angrep og varsle om kjente sårbarheter. De er svakere når skaden har skjedd: en automatisk skanner forstår ikke forretningslogikken og kan slette en fil som ser mistenkelig ut, men som butikken trenger. En manuell revisjon trengs særlig etter et bekreftet innbrudd, når du ser ukjente brukere eller sider du ikke har laget, og når nettbutikken behandler betalinger og persondata.
Kontakt
Send adressen til nettstedet og hva du er bekymret for via kontaktskjemaet. Du får oppfølgingsspørsmålene og et tilbud skriftlig. Etter utbedringen kan jeg ta over løpende WordPress-vedlikehold, slik at herdingen holder seg når utvidelser og konfigurasjon endrer seg.
Vil du se på nettstedet selv først, henter WordPress-nettstedsjekk den offentlige versjonen av én adresse og viser blant annet hoder og forespørslene som blokkerer første opptegning. Den krever ingen e-postadresse.
