SQL-injectie: hoe het werkt en hoe je het voorkomt

SQL-injectie (of kortweg SQLi) is een van de oudste trucs uit het hackerhandboek, maar nog steeds ontzettend gangbaar en gevaarlijk. Kort gezegd komt het neer op het misleiden van een database om dingen prijs te geven die het niet zou mogen.

In dit artikel leg ik uit wat SQL-injectie precies is, de verschillende manieren waarop aanvallers het gebruiken, een paar praktijkvoorbeelden die serieuze schade veroorzaakten en, misschien wel het belangrijkst, hoe je het kunt voorkomen. Of je nu developer bent of gewoon nieuwsgierig naar hoe dingen op internet stukgaan, je loopt weg met een solide begrip van SQLi (zonder halverwege in slaap te vallen, beloofd).

Wat is SQL-injectie? 

SQL-injectie is een type aanval dat plaatsvindt wanneer iemand een manier vindt om te knoeien met de SQL-queries die je app naar de database stuurt. Normaal gesproken zijn die queries bedoeld om dingen te doen zoals het profiel van een gebruiker ophalen of een productvermelding bijwerken. Maar met SQLi kan een aanvaller kwaadaardige stukjes SQL-code in je invoervelden injecteren (zoals zoekbalken of inlogformulieren), en ineens doet de database precies wat zij willen.

Waarom werkt dit? 

Omdat ergens in de keten de applicatie gebruikersinvoer net iets te veel vertrouwt en het behandelt als onschuldige tekst in plaats van potentiële uitvoerbare code. Het is alsof je iemand een formulier laat invullen en vervolgens plakt wat ze schreven direct in een opdrachtconsole.

Waarom is het slecht?

SQL-injectie is gevaarlijk omdat het kan worden gebruikt om privégegevens te bekijken of te stelen (zoals gebruikersnamen, wachtwoorden of creditcardgegevens), inlogschermen te omzeilen, gegevens te verwijderen of te wijzigen en in het slechtste geval zelfs volledige controle te krijgen over de databaseserver.

Dus ja, SQLi is slecht, en het is niet eens een recent beveiligingsprobleem, maar je zou versteld staan hoeveel apps er nog steeds niet goed tegen beschermd zijn.

Typen SQL-injectie

Afhankelijk van hoe de aanvaller met je applicatie interageert en wat voor feedback ze krijgen, komt SQLi in een paar verschillende smaken. Er zijn 3 hoofdtypen die je kunt tegenkomen:

In-band SQLi

Dit is het meest rechttoe rechtaan type. De aanvaller stuurt een kwaadaardige SQL-query en krijgt de resultaten meteen terug via de applicatie. Het is snel en vaak erg effectief.

• Error-based SQLi: Deze techniek is afhankelijk van behulpzame foutmeldingen van de database. Die fouten kunnen enorm veel nuttige info onthullen, zoals tabelnamen of de structuur van queries, waardoor het voor de aanvaller makkelijker wordt om hun volgende stap te plannen.

• Union-based SQLi: Hierbij gebruikt de aanvaller de UNION-operator om hun eigen query te combineren met die van je app. Het is een slimme manier om extra data uit de database te trekken en die stiekem in de response te laten meelopen.

Inferential SQLi (ook wel Blind SQLi)

Deze is sluwer. In plaats van de resultaten van hun query direct te zien, kijkt de aanvaller naar het gedrag van de applicatie om te achterhalen wat er onder de motorkap gebeurt.

• Boolean-based (content-based) SQLi: De aanvaller past de query aan met voorwaarden die waar of onwaar zijn (zoals 1=1 of 1=2) en observeert hoe de pagina verandert. Laadt hij normaal? Geeft hij een fout? Doet hij raar?
• Time-based SQLi: Deze techniek voegt tijdsvertragingen toe aan de query (bijv. WAITFOR DELAY '00:00:05') en gebruikt de responstijd om af te leiden of een voorwaarde waar is.

Out-of-band SQLi (oftewel wanneer het fancy wordt)

Deze komt minder vaak voor, maar is het kennen waard. Out-of-band SQLi is niet afhankelijk van directe responses van de app. In plaats daarvan gebruikt de aanvaller alternatieve kanalen zoals DNS- of HTTP-verzoeken om data te exfiltreren. Het wordt meestal gebruikt wanneer directe feedback niet mogelijk is, maar de databaseserver wel internettoegang heeft (en in 90% van de gevallen zou dat waarschijnlijk niet zo moeten zijn).

Veelgebruikte SQL-injectietechnieken

Oké, we hebben 3 typen SQL-injectie leren kennen. Maar hoe flikken aanvallers dit in de praktijk?

OR 1=1-aanval

Dit is een klassieker. Stel je een inlogformulier voor waar je je gebruikersnaam en wachtwoord moet invullen. Een aanvaller kan zoiets invoeren als:

' OR 1=1 --

De SQL-query komt er dan ongeveer zo uit te zien:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

Omdat 1=1 altijd waar is, retourneert de database alle gebruikers, en verandert -- de rest van de query in een commentaar. Als er geen limiet is ingesteld, kan de aanvaller mogelijk inloggen zonder zelfs maar een geldige gebruikersnaam te kennen.

Bron: vmware

Commentaarinjectie

Zoals net hierboven te zien was, worden de tekens -- of /* */ gebruikt om delen van een SQL-statement uit te commentariëren. Aanvallers gebruiken dit om extra clausules te verwijderen die hun geïnjecteerde payload kunnen breken. Als ze bijvoorbeeld de volledige structuur van de oorspronkelijke query niet kennen, kunnen ze die gewoon afkappen en weer syntactisch geldig maken.

Batch-SQL-statements

Sommige databases staan toe dat meerdere SQL-statements in één verzoek worden uitgevoerd, gescheiden door een puntkomma. Deze functie kan door hackers worden misbruikt om van alles te doen, zoals data wijzigen of zelfs tabellen droppen als de applicatie dit niet beperkt.

'; DROP TABLE users; --

UNION-based aanvallen

Door een UNION SELECT-statement te injecteren kunnen aanvallers hun kwaadaardige query combineren met de legitieme en resultaten ophalen uit andere tabellen, zoals gevoelige gebruikersdata, wachtwoorden of creditcardinfo. Het is in feite een bestaande query gebruiken om bonusdata te krijgen.

Blind SQL-injectie

We noemden dit al eerder. Zelfs wanneer de app geen fouten toont of queryresultaten teruggeeft, kunnen aanvallers nog steeds beetje bij beetje data extraheren door het gedrag te observeren. Het is trager en saaier, maar het werkt. Dit wordt vaak geautomatiseerd met tools die honderden queries en time-based responses kunnen proberen.

Stored SQL-injectie

De kwaadaardige SQL wordt opgeslagen in de database, bijvoorbeeld in een gebruikersprofiel of commentaar, en later uitgevoerd wanneer iemand die data bekijkt.

SQL-injectie in de echte wereld

SQL-injectie klinkt misschien als iets voor niche-hackers, maar het heeft door de jaren heen echte schade aangericht. En met schade bedoel ik miljoenen blootgestelde gebruikersrecords, enorme boetes en krantenkoppen waar marketingafdelingen niet blij van werden.

Guess.com (2002)

Dit is een vroeg voorbeeld dat mensen deed opletten. Een security-onderzoeker misbruikte een SQL-injectiefout en kreeg toegang tot meer dan 200.000 klantrecords, inclusief creditcardgegevens. Het goede nieuws is dat het werd gevonden en gemeld door een ethische hacker. 

Heartland Payment Systems (2009)

Dit was een enorme inbreuk bij een betalingsverwerker waarbij 130+ miljoen creditcardnummers werden gestolen. De aanvallers gebruikten SQL-injectie om een ingang te vinden en schaalden vanaf daar op. Dit wordt vaak genoemd als een van de grootste datalekken ooit.

Yahoo! Voices (2012)

Aanvallers misbruikten een UNION-based SQL-injectiefout en legden 450.000 gebruikersnamen en wachtwoorden in platte tekst bloot. Ja, je leest het goed: gewoon ruwe inloggegevens die daar in platte tekst stonden. Dat lek was extra pijnlijk omdat Yahoo! een groot techbedrijf was, en het opslaan van ongecodeerde wachtwoorden is een serieus “niet doen”, zelfs naar maatstaven van 2012.

TalkTalk (2015)

TalkTalk is een prominente Britse telecomprovider die ten prooi viel aan een vrij basale SQL-injectieaanval. Ongeveer 157.000 klantrecords werden gecompromitteerd, en het bedrijf kreeg een boete van £400.000. Een van de aanvallers was pas 17 jaar oud.

Gab (2021)

Hacktivisten gebruikten SQL-injectie om 70 GB aan data te exfiltreren, waaronder privéberichten en gehashte wachtwoorden. Het lek was politiek beladen en de nasleep leidde tot nog meer aandacht voor de algehele beveiliging van Gab.

Hoe voorkom je SQL-injectie

Oké, nu we onszelf een beetje hebben laten schrikken met al die echte datalekken, laten we het over oplossingen hebben. Het goede nieuws is dat SQL-injectie voorkomen geen rocket science is. Meestal draait het om gebruikersinvoer niet vertrouwen en je aan best practices houden. Dit kun je doen:

Gebruik geparametriseerde queries

Dit is regel nummer één. Bouw nooit SQL-queries door strings aan elkaar te plakken. Gebruik in plaats daarvan placeholders en geef gebruikersinvoer door als parameters. De meeste frameworks en libraries maken dit supermakkelijk.

Bijvoorbeeld in Node.js met pg (PostgreSQL):

client.query('SELECT * FROM users WHERE id = $1', [userId]);

Dit vertelt de database in feite: “Hier is de querystructuur, en hier is wat data; haal die alsjeblieft niet door elkaar.”

Gebruik stored procedures op een slimme manier

Stored procedures kunnen helpen, maar alleen als ze ook dynamische SQL vermijden. Het idee is dat de SQL-logica in de database leeft en je app gewoon die veilige, vooraf gedefinieerde stukjes logica aanroept.

Als je wilt leren hoe je functies en stored procedures maakt, bijwerkt en uitvoert, bekijk dan onze cursus Writing Functions and Stored Procedures in SQL Server.

Valideer en saneer invoer

Als je app een getal verwacht, zorg dan dat het een getal is. Accepteer niet blind alles wat een gebruiker je toestuurt. Gebruik typechecks, lengtelimieten en allowlists (bijv. alleen bekende goede waarden toestaan) waar mogelijk.

Het escapen van tekens (zoals aanhalingstekens) kan ook helpen, maar het is geen vervanging voor geparametriseerde queries.

Gebruik een Web Application Firewall (WAF)

Een WAF kan fungeren als eerste verdedigingslinie, vooral tegen bekende aanvals­patronen. Het kan helpen om kwaadaardig verkeer te blokkeren voordat het je app bereikt. Niet waterdicht maar nuttig; het is een beetje als een spamfilter voor je SQL.

Pas het least privilege-principe toe

Je webapp zou niet met adminrechten op de database moeten inloggen. Beperk wat elke gebruiker of service kan doen. Als je app bijvoorbeeld alleen data hoeft te lezen, geef dan geen permissie om tabellen te verwijderen. Hoe minder macht, hoe minder schade een injectie kan aanrichten.

SQL-injectietesten en -detectie

Zelfs als je denkt dat je code veilig is, is het de moeite waard om te testen zoals een aanvaller dat zou doen. SQL-injectie glipt makkelijk tussendoor, vooral in grote codebases of legacy-systemen. Er zijn tools en technieken die detectie veel eenvoudiger maken en bovendien best leuk zijn om mee te spelen.

Handmatig testen

Soms is de snelste manier om een lek te vinden: er gewoon aan peuteren. Probeer ' OR 1=1 -- of '; DROP TABLE users; -- in te voeren in formulieren, URL’s of andere invoervelden en kijk hoe de app reageert. Krijg je vage fouten, onverwachte data of mysterieuze succesmeldingen, dan heb je mogelijk iets dubieus gevonden.

Pro tip: Test altijd in een dev- of stagingomgeving. 

Geautomatiseerde scanners

Er zijn genoeg tools die het peuteren voor je doen. Een paar goede:

• sqlmap: Een open-source beest dat detectie en exploitatie automatiseert (in ethische testcontexten).
• Burp Suite: Geweldig voor webappbeveiliging in het algemeen, met extensies voor SQLi-detectie.
• OWASP ZAP: Gratis en beginnersvriendelijk, gemaakt om allerlei webkwetsbaarheden te vinden.

Deze tools simuleren aanvallen, markeren potentiële injectiepunten en kunnen soms fixes suggereren.

Loganalyse

Nog een slimmigheidje: monitor je databaselogs. Herhaald mislukte queries, vreemde syntaxispatronen of een golf aan verzoeken met ', --, of UNION SELECT zijn allemaal rode vlaggen.

Conclusie

SQL-injectie gaat voorlopig niet weg en is zo’n dreiging die nooit veroudert. Het is simpel, krachtig en als je niet oplet kan het serieuze schade veroorzaken. Het punt is: SQLi is totaal te voorkomen. Door geparametriseerde queries te gebruiken, invoer te valideren, het least privilege-principe toe te passen en regelmatig te testen, kun je je applicaties en gebruikers beschermen tegen de verwoestende impact van een SQL-injectieaanval. 

Onthoud: niemand verwacht perfectie, maar met een beetje proactieve inzet hou je je database veilig en kun je dat van je beveiligingschecklist afvinken. En als je serieus met SQL bezig bent en je skills wilt laten zien aan potentiële werkgevers, bekijk dan onze SQL Associate Certification! Die laat zien dat je in staat bent om met SQL de juiste data uit een database te halen en te gebruiken om veelvoorkomende datavragen te beantwoorden.