Plugins vormen grootste aanvalrisico

Plugins binnen WordPress ‘maken de website’. Met talloze gebruiksmogelijkheden kan de ‘kale’ basis van WordPress worden voorzien van veel gevraagde  functionaliteiten. Het gebruik van plugins vraagt echter een gedegen voorbereiding.

Een recent onderzoek onder 1000 webmasters resulteerde vooral in de zorg rondom het herkennen van aanvallen. Ruim 61% van de ondervraagden wist niet op welke wijze hun website was aangevallen, nadat ze (al dan niet via hun opdrachtgever) waren gewezen op een één of andere vorm van vreemd gedrag van een door hen (technisch) beheerde website.

Een krappe 40% wist wel te achterhalen waar de aanvullen van afkomstig waren. Een overgrote meerderheid constateerde dat vooral plugins diverse oorzaken bevatten, die ervoor zorgden dat een website ‘kuren’ vertoonde. Met zo een 50.000 beschikbare plugins is de kans op lekjes enorm groot. Op de WordPress website zelf is de wijze waarop plugins worden weergegeven en onderhouden redelijk standaard. Er is derhalve ook redelijk goed na te gaan in welk stadium een plugin zich bevindt.

Kwaliteit van een programmeur voor een eindgebruiker niet te beoordelen

• bekijk goed naar de laatste datum waarin een update is gemaakt (WordPress waarschuwt voor plugins die langer dan 2 jaar niet zijn onderhouden)
• ‘draait’ de plugin op de laatste versie van WordPress
• lees de beoordelingen van gebruikers
• wordt tijdig en afdoende gereageerd op vragen in het forum

Bij commerciële aanbieders is die structuur wat lastiger te doorgronden. Doe op zijn minst onderzoek naar de programmeur en/of het bedrijf, welke tegen betaling plugins aanbiedt. Controleer of er een forum bestaat of een pagina/groep binnen social media kanalen, waar vragen gesteld worden. Ga na in hoeverre de ontwikkelaar zelf antwoord geeft op de vragen en of de plugin ook hier regelmatig geupdate wordt.

Onderhoud je je website zelf, realiseer je dan dat het minimaliseren van het aantal plugins altijd het beste uitgangspunt is

De WPScan Vulnerability Database houdt een lijst met kwetsbaarheden bij van zowel plugins, thema’s en de WordPress kern zelf. De meeste bekende kwetsbaarheden zijn o.a.:

• Authenticated Cross-Site Scripting (XSS)
• SQL Injection
• Open Redirect
• Cross-Site Request Forgery (CSRF)

Zonder zelf PHP programmeur te zijn, is het wel zinvol (zeker bij eigen onderhoud) een e-mail abonnement te nemen op bovenstaande dienst. Op die manier word je snel geïnformeerd over kwetsbaarheden. Het is dan – hoe vervelend dat functioneel gezien dan ook kan zijn – wel verstandig de plugin tijdelijk te deactiveren, totdat een nieuwe versie beschikbaar is. Reageert de ontwikkelaar niet, dan is het verstandig de plugin in zijn geheel te verwijderen en op zoek te gaan naar een alternatief.

Veel van onze opdrachtgevers besteden dergelijk onderhoud aan ons uit, wij hebben onze ‘scanners’ 24/7 online en zijn derhalve snel in staat eventuele gevolgen van aanvallen zoveel mogelijk te minimaliseren

Andere redenen

In bovenstaand schema zie je vervolgens dat zogenaamde ‘brute force’ aanvallen op de tweede plaats staan. Op vrijwel elke website zal (uiteindelijk) een poging worden gedaan om via ‘/wp-admin’ binnen te komen. Dat gebeurt vrijwel altijd geautomatiseerd. Een zwakke combinatie van gebruikersnaam/wachtwoord zet de deur al half open. Ook hiervoor zijn weer talloze plugins beschikbaar om ongeoorloofd inloggen zo moeilijk mogelijk te maken.

Overall beveiliging

Een website volledig ‘dichttimmeren’ is vrijwel onmogelijk. Ook niet wanneer een zogenaamde ‘overall beveiligings plugin’ wordt geïnstalleerd. Wordfence en Sucuri zijn de twee meest bekende voorbeelden, waarbinnen de gratis versies al heel wat werk doen om aanvallen te voorkomen en in ieder geval ook te detecteren. Toch vragen ook deze plugins de nodige technische kennis om ze op juiste wijze te configureren. Naast genoemde plugins zijn er natuurlijk ook op serverniveau de nodige maatregelen te nemen. Bij de meeste goedkopere abonnementen (rond de ca. 10 euro per maand) is sprake van zogenaamde shared hosting, dat wil zeggen meerdere websites draaiend op één server, worden de serverinstellingen door de provider geregeld en zijn dus niet per site te regelen. Dat kan wel bij een VPS (Virtual Private Server) en ook daar kunnen applicaties worden geïnstalleerd om de server te beveiligen, zoals bijvoorbeeld Dr. Web.