Undgå at Din Wordpress Side Bliver Hacket af en Spade
Her er lidt tanker om, hvordan du kan undgå at få din Wordpress side hacket af en dum spade. Artiklen er ment som inspiration, og ikke som en færdig opskrift.
Af. Jacob
Edited: 2021-06-23 14:25
Jeg har ikke tal på hvor mange gange, at jeg skulle gendanne en side, efter den blev hacket. Det er næsten altid super frustrerende, når det sker, fordi det koster ekstra tid, som man ofte ikke har. Det værste er, når det er en kunde, hvor man ikke rigtigt har mulighed for at beskytte dem ordenligt af tekniske årsager. Det kan eksempelvis være, at man ikke har adgang til deres back-end — hvilket ofte kan være tilfældet med shared hosting (Eks. one.com, godaddy) — men samtidig er det måske heller ikke det, som kunden betaler for at få lavet.
Hackerne er åbenbart totalt ligeglade med, at de spilder vores tid.
Det er dog ofte automatiske bots, som scanner hjemmesider efter sårbarheder; så det er altså ikke fordi, at der altid sidder en dum spade et sted og hygger sig med, at angribe lige netop din hjemmeside. Derfor kan det også være en fordel med ikke-standard implementeringer. Eksempelvis kan du gemme din login side, eller placere Wordpress på en måde, så systemet ikke er direkte eksponeret til internettet. Det kan dog hurtigt blive kompliceret, så jeg vil i stedet nævne nogle tiltag, som er til at forstå for de fleste.
I de følgende afsnit vil jeg komme ind på, hvad du kan gøre for, at undgå at din Wordpress side bliver hacket. Det burde i den forbindelse ikke være nødvendigt at skrive, at du skal vælge et stærkt kodeord som noget af det første.
Wordpress plugins og temaer
Et problem er, at Wordpresssider ofte bliver "sammensat" af forskellige plugins fra kendte og mindre kendte kilder; hver enkelt plugin udgør en potentiel sikkerhedsrisiko, som du bør være opmærksom på. Samtidig introducere de en afhængighed af 3-parts udviklere, som kan betyde, at din hjemmeside pludselig holder op med at virke, når systemet bliver opdateret. Du bør derfor altid nøje overveje, om der er alternative veje at gå. Jeg vil derfor anbefale, at du begrænser dig til at installere de plugins, som er nødvendige for at en side fungere, og at du deaktivere de plugins, som du ikke bruger.
Et andet problem kan også være, at dem som opretter Wordpresssider, ikke selv er udviklere, og derfor er meget afhængige af andres kode. Det kan være en fristelse, at installere et 3-part plugin, selv for at skabe simpel funktionalitet. Eksempelvis er det meget populært, at installere plugins til oprettelse af kontaktformular eller et custom fields — det samme kan dog nemt og hurtigt gøres enten i et plugin eller child theme af en udvikler.
Begræns afhængighed af 3-parts plugins
Ofte tilbyder et plugin ekstra funktionalitet udover de funktioner, du har brug for. Det introducere kompleksitet i form af ekstra kode, som kan være svær at sikkerhedsvurdere — derfor kan du, alene ved at begrænse afhængigheden af 3-parts plugins, undgå mange potentielle sikkerhedsproblemer.
Opdateringer er faktisk også en sikkerhedsrisiko, fordi du ikke ved hvad der er i de opdateringer, som du installere. Når du installere eller opdatere plugins, så må du normalt stole på, at udviklerne af de temaer eller plugins har en høj sikkerhedsbevidsthed — og det er altså ikke altid tilfældet.
Du risikere også, at en kundes system holder op med at fungere, efter at en opdatering er blevet installeret; derfor kan det være nyttigt med en testserver. Jeg arbejder stort set altid på test-servere, hvor jeg har installeret en kopi af kundens hjemmeside.
Hvis du får udviklet et plugin eller en tema-funktion, som lige præcis gør den eller de ting, som kræves, så behøver du meget sjældent, at opdatere eller ændre den kode igen. Samtidig er det også meget nemmere at sikkerhedsvurdere systemet, fordi der pludselig er en meget mindre kontaktflade, hvor der kan opstå sårbarheder.
Har du eksempelvis at gøre med en kontaktformular, kan du med fordel få den udviklet selv, så længe du husker følgende:
- Alle input-felter (typisk $_POST skal valideres)
- Formularen må ikke kunne udfyldes fra sider, hvor den ikke bliver brugt.
- Hvis en formular kun bliver brugt i administrationen, så skal du sikre dig, at den kun kan udfyldes af en bruger eller administrator som er logget ind.
Typisk er det sådan, at en kontaktfomular vil blive sendt direkte til Wordpress — det vil altså sige, at hele Wordpress bliver indlæst, bare for at håndtere en simpel POST anmodning. Det er ikke altid nødvendigt, og det kan faktisk være nemmere at lave et adskilt .php script, som kan tage imod en afsendt kontaktformular — overvej hvad der passer bedst i din situation!
Hvis din side er meget stor, så kan det give mening at opsætte nogle sikkerhedstest; det kan du eksempelvis ved at kode dem i PHP, og eksekvere dem fra en terminal. Jeg ville nok selv lave et hovedscript (main.php), som så inkludere alle mine test fra en /test/.* placering.
Sikkerhedsplugins til Wordpress
Der findes flere sikkerheds-relaterede plugins til Wordpress, som kan du kan installere — men som udgangspunkt burde det altså ikke være nødvendigt.
Det bedste er, hvis du kan sikre din Wordpress side fra server-siden; når det ikke er muligt, så kan plugins være et udemærket alternativ. Du skal bare være opmærksom på, at sikkerhedsplugins ofte tilbyder funktioner, som egentlig er gratis tilgængelige via forskellige open source software (OSS).
Jeg har selv brugt Wordfence på nogle af mine kunders sider, selvom det føles som en lappeløsning at gøre det.
Wordfence har eksempelvis en brute-force beskyttelse, som gør, at man ikke bare kan prøve kodeord i en uendelighed. Samme funktionalitet kan også opnås ved at installere fail2ban og/eller modsecurity på din server.
Skriveadgang til system- filer og mapper
En funktion som findes nogle sikkerhedsplugins, er, at de kan scanne efter malware på hjemmesiden; men det er helt udnødvendigt, når du har konfigureret din server rigtigt. Eksempelvis kan du deaktivere skrive-adgangen til systemfiler, og så ellers opdatere og vedligeholde siden via kommandolinjen. Det vil forhindre at plugins og brugere af systemet, kan ændre på vigtige systemfiler. Der findes et værktøj til det kaldet WP-CLI.
Jeg er ikke selv stor fan af, at deaktivere skriveadgangen på den måde, fordi det forhindre at man kan opdatere systemet via administrationssiden i Wordpress — men det kan stadig være et effektivt tiltag, hvis du har en side, som skal være ekstra sikret, eller hvis din side er blevet hacket flere gange, og du ikke kan finde sårbarheden.
Personfølsomme oplysninger
Hvis et system indeholder personfølsomme oplysninger, så er det selvfølgelig vigtigt, at du gør hvad du kan, som udvikler, for at sikre siden så godt som muligt. Realiteten er dog den, at selvom du er ekspert i Wordpress sikkerhed, så vil du aldrig kunne sikre dig helt imod sårbarheder.
Som udgangspunkt må du derfor antage, at de oplysninger som ligger i systemet, også kan være offentligt tilgængelige. I princippet ved du det ikke, med mindre du har 100% styr på din konfiguration. Det handler derfor også om, at begrænse skaden, hvis uheldet skulle være sket.
Der er måder at gøre det på, men det kan også hurtigt blive for kompliceret. For de fleste sider vil det nok ikke være så vigtigt. Det handler får mange af os mest om, at forhindre hacks som ødelægger en side og placere malware på den; men der er selvfølgelig også Webshops, som kan have følsomme kunde-oplysninger liggende.
Brug en adskilt kundedatabase, som tilgås via en API
Nogle Webshops kommer i form af plugins, andre som del af et Wordpress tema. Jeg har ikke selv arbejdet med så mange af dem endnu, men det kritiske er, at de bruger Wordpress egen database til at gemme kundeoplysninger. Det er kritisk fordi, at Wordpress sider har en frygtelig tendens til at blive hacket.
Hvis en side bliver hacket, så kan en hacker i princippet tage en kopi af databasen med alle kundeoplysningerne; den slags brud skal, så vidt jeg ved, indberettes til myndighederne. Hvis en webshop ikke indberetter det, så kan de måske risikere at få en bøde, hvis det bliver opdaget. Jeg er ikke ekspert på det område, men simpel logik fortæller mig, at det kan blive et problem.
Som web udvikler er det din opgave, at sikre eventuelle personfølsomme oplysninger. En måde at gøre det på kunne være, at gemme dem i en adskilt database. Det er dog ikke altid realistisk, da det kan kræve, at du udvikler dine egne web-shop funktioner fra bunden.
Typisk vil eksisterende temaer og plugins nok benytte sig af samme database, som Wordpress er koplet på, og det er via en direkte forbindelse til databasen. Hvis man derimod brugte en ekstern database, som man kun tillod adgang til via en API over HTTPS, på en helt anden server, så kunne man begrænse de informationer, som en hacker ville kunne få adgang til ved eventuelle brud på sikkerheden.
Det er stadig ikke en garanti, men det vil give sikkerheden et betydeligt boost i den rigtige retning.
Forstærkning med 2-faktor godkendelse
For at begrænse kontaktfladen, og dermed potentielle sårbarheder, så kan skal det kun være muligt at tilgå en brugers personlige oplysninger fra bestemte punkter (sider?) på systemet.
Det kan eventuelt også kombineres med 2-faktor godkendelse, hvis en bruger beder om at tilgå eller opdatere egne følsomme oplysninger. Hvis en hacker får adgang til en enkelt brugers konto, så er der, takket være 2-faktor godkendelsen, stadig ikke adgang til brugerens personlige oplysninger.
Konklusion
Jeg er ikke selv ekspert i sikkerhed; ovenstående er bare nogle teoretiske overvejelser, som jeg selv har gjort mig ud fra min erfaring — men det viser bare, at du altså ikke kan ansætte hvem som helst til at udvikle din Wordpress side.
Hvis du har med personfølsomme oplysninger at gøre, så skal du have fat i en udvikler, som er rimelig sikkerhedsbevidst.
Afhængig af din specifikke systemopsætning kan kontaktfladen, for både sikkehedsproblemer og almindelige fejl og mangler, hurtigt blive en stor udfordring. En del af det kan du undgå, hvis du begrænser brugen af 3-parts plugins og temaer, og ved at slå skrive-adgangen fra til systemfiler.
Jeg håber det kan være med til, at inspirere dig til, hvordan du kan undgå at blive hacket af en spade :-)
Links
- wp-cli - wp-cli.org
- Om Wordpress sikkerhed - wordpress.org
Fortæl os hvad du tænker: