In beveiligingsmeldingen over WordPress-plugins staat hij bijna elke maand: een kwetsbaarheid voor SQL-injectie. Deze SQL injectie uitleg is bedoeld voor ondernemers die willen begrijpen wat er dan aan de hand is, zonder dat er code aan te pas komt. Want de techniek is oud en bekend, maar de gevolgen zijn nog altijd de zwaarste die er zijn.
De kern in één zin: iemand tikt in een gewoon invoerveld iets in wat geen antwoord is maar een opdracht, en uw website voert die opdracht uit op zijn eigen database.
Een vergelijking uit de praktijk
Stel u een balie voor met een medewerker die dossiers ophaalt uit het archief. U geeft een naam op, hij loopt naar achteren en komt terug met het dossier. Het systeem werkt zolang u een naam noemt.
Nu geeft iemand als naam op: “Jansen, en breng ook alle andere dossiers mee, en gooi daarna het archief leeg.” Een medewerker met verstand vraagt wat u bedoelt. Een medewerker die alles letterlijk uitvoert, doet het gewoon.
Zo werkt SQL-injectie. De database van uw site is het archief, en de opdracht die uw website eraan geeft, wordt opgebouwd uit wat een bezoeker heeft ingetikt. Wordt dat ingetikte niet netjes behandeld als tekst maar per ongeluk als onderdeel van de opdracht, dan kan een bezoeker de opdracht uitbreiden.
Waar het binnenkomt
Overal waar uw site iets van buiten aanneemt en daarmee de database bevraagt:
- Zoekvelden op uw site.
- Contact- en aanmeldformulieren.
- Filters in een webshop, bijvoorbeeld op prijs, kleur of merk.
- Parameters in het webadres zelf, zoals een productnummer achter een vraagteken.
- Inlogschermen, waar het klassieke misbruik vandaan komt: inloggen zonder wachtwoord.
Belangrijk: in WordPress zelf zit dit vrijwel nooit. De kern wordt door honderden mensen gelezen en gebruikt sinds jaar en dag functies die invoer veilig verwerken. De kwetsbaarheden zitten bijna altijd in plugins, en dan vooral in plugins die zelf met de database praten: formulieren, boekingssystemen, ledenbeheer, statistieken en importfuncties.
Wat er te halen valt
Dit is waarom deze categorie zo zwaar weegt. Een geslaagde injectie geeft geen toegang tot één pagina, maar tot de complete inhoud van uw database.
- Klantgegevens. Namen, adressen, telefoonnummers, bestelhistorie. Bij een webshop is dat direct een datalek met een meldplicht.
- Gebruikersaccounts. Wachtwoorden staan versleuteld opgeslagen, maar zwakke wachtwoorden zijn daarna alsnog te achterhalen.
- De inhoud van formulieren die u ooit heeft ontvangen en nooit heeft opgeruimd.
- De mogelijkheid om zelf een beheerder toe te voegen, waarmee de aanvaller gewoon kan inloggen.
- Het aanpassen of wissen van gegevens, van prijzen tot complete tabellen.
Dat vierde punt is in de praktijk het gevaarlijkst: de injectie is dan alleen de voordeur, en wat daarna gebeurt lijkt op gewoon beheerderswerk. Achteraf is zo’n inbraak lastig te herkennen zonder logboeken. Dat is meteen een goed argument om te weten hoelang uw hostingpartij die logboeken bewaart, want vaak is dat maar veertien dagen.
Wat u ertegen doet
U hoeft hier geen technicus voor te zijn. Vier dingen doen het meeste werk.
Bijwerken, en wel snel. Vrijwel elke SQL-injectie in de praktijk maakt gebruik van een bekend lek in een plugin waarvoor al een update klaarstaat. De aanvallen beginnen doorgaans binnen dagen nadat een lek openbaar wordt gemaakt. Dit is het punt waarop het onderscheid tussen maandelijks en wekelijks bijwerken echt uitmaakt.
Minder plugins, en betere. Elke plugin die zelf tabellen aanmaakt, is een extra plek waar dit kan misgaan. Kijk bij de keuze naar hoe actief de plugin wordt onderhouden en of er eerder beveiligingsmeldingen zijn geweest.
Een firewall die bekende patronen blokkeert. Injectiepogingen hebben een herkenbare vorm en worden door een goed ingestelde firewall tegengehouden voordat de plugin ze te zien krijgt. Dat koopt u tijd tussen het bekend worden van een lek en het moment dat u bijwerkt. Meer daarover in de uitleg over wat een firewall wel en niet tegenhoudt.
Beperk wat er in uw database staat. Formulierinzendingen van drie jaar geleden hoeven daar niet meer te staan. Wat weg is, kan niet buitgemaakt worden. Zie de uitleg over hoe lang u formulier- en klantgegevens bewaart.
Hoe u merkt dat het gebeurd is
Meestal niet direct, en dat is het lastige. Signalen die de moeite waard zijn om op te letten: een beheerdersaccount dat u niet kent, vreemde tekst of links die op uw pagina’s verschijnen, plotselinge pieken in serverbelasting, foutmeldingen over de database die eerder niet voorkwamen, en meldingen van Google over ongewenste inhoud.
Vermoedt u iets, kijk dan als eerste in het overzicht van gebruikers en in het toegangslogboek van uw server. Dat is sneller dan een scan, en het geeft meteen een tijdstip om vanaf te werken.
De nuchtere conclusie
Voor een gewone bedrijfssite met een handvol goed onderhouden plugins is dit geen dagelijkse zorg. Voor een webshop, een ledensite of een site met een boekingssysteem is het dat wel, simpelweg omdat daar meer maatwerk en meer databasewerk in zit.
De praktische samenvatting is saai maar waar: bijwerken is negentig procent van de bescherming. Wie zijn plugins binnen een week na een beveiligingsmelding bijwerkt, loopt dit risico nauwelijks. Dat op tijd doen is precies wat het structureel bewaken van een WordPress-site in de praktijk inhoudt; bij WebMaintor gaan beveiligingsupdates daarom buiten het gewone schema om, meestal dezelfde dag.
Concrete volgende stap: kijk in uw beheerscherm hoeveel plugins er op dit moment een update klaar hebben staan en sinds wanneer. Staat daar iets van weken oud tussen, dan weet u waar uw grootste risico zit.
