SQL-injectie: hoe pentesters het vinden en hoe je het voorkomt

SQL-injectie is een van de oudste kwetsbaarheden in webapplicaties. De eerste publicaties dateren van eind jaren negentig, en toch staat injectie ook in de OWASP Top 10:2025 nog altijd hoog genoteerd. In onze webapplicatie-pentests komen we SQL-injectie nog met enige regelmaat tegen, vooral in maatwerkapplicaties, legacy-code en op plekken waar ontwikkelaars het raamwerk omzeilen met handgeschreven queries. In dit artikel leggen we uit wat SQL-injectie precies is, welke varianten wij in de praktijk tegenkomen, hoe een pentester ernaar zoekt en, het belangrijkste, hoe je het structureel voorkomt.

## Wat is SQL-injectie?

SQL-injectie ontstaat wanneer gebruikersinvoer onvoldoende gescheiden wordt van de databasequery waarin die invoer terechtkomt. Een applicatie die een zoekterm rechtstreeks in een SQL-string plakt, geeft de aanvaller de mogelijkheid om die string te manipuleren. In plaats van alleen data mee te geven, stuurt de aanvaller extra SQL-code mee die de database vervolgens uitvoert als onderdeel van de query. Het gevolg kan variëren van het uitlezen van gegevens waar de gebruiker geen recht op heeft, tot het aanpassen of verwijderen van data en in het ergste geval het overnemen van de onderliggende server.

De kern van het probleem is het door elkaar lopen van code en data. De database kan niet zien welk deel van de query door de ontwikkelaar is bedoeld en welk deel door een gebruiker is ingevoerd. Zolang die scheiding niet technisch is afgedwongen, blijft de deur op een kier staan.

## De varianten die wij in de praktijk tegenkomen

SQL-injectie is geen enkele techniek maar een familie. Grofweg onderscheiden we drie hoofdvormen.

Bij klassieke, in-band injectie ziet de aanvaller het resultaat direct terug in de applicatie. Dit is de meest zichtbare vorm: de aanvaller wijzigt de query en de uitkomst verschijnt op het scherm, bijvoorbeeld via een UNION-constructie die extra kolommen uit andere tabellen ophaalt.

Bij blind SQL-injectie krijgt de aanvaller de data niet rechtstreeks te zien, maar leidt die de informatie af uit het gedrag van de applicatie. Bij boolean-based blind injectie reageert de applicatie merkbaar anders op een ware dan op een onware voorwaarde, waardoor je bit voor bit gegevens kunt reconstrueren. Bij time-based blind injectie dwingt de aanvaller de database om te wachten, bijvoorbeeld met een sleep-functie, en meet die aan de reactietijd of een voorwaarde waar was. Blinde varianten zijn trager om te exploiteren maar minstens zo gevaarlijk.

Bij out-of-band injectie gebruikt de aanvaller een tweede kanaal, bijvoorbeeld een DNS- of HTTP-verzoek dat de database naar buiten stuurt, om data te exfiltreren. Deze variant is nuttig wanneer de applicatie zelf geen bruikbare terugkoppeling geeft.

Daarnaast zien we regelmatig second-order injectie: invoer die op het moment van opslaan onschuldig lijkt, maar later in een andere query wordt hergebruikt en dan alsnog kwaadaardig uitpakt. Juist deze vorm wordt door geautomatiseerde scanners vaak gemist, omdat de kwetsbaarheid pas in een tweede handeling tot uiting komt.

## Hoe een pentester ernaar zoekt

Een geautomatiseerde vulnerability scan vindt een deel van de eenvoudige gevallen, maar de interessante bevindingen komen bijna altijd uit handmatig testen. Onze aanpak begint met het in kaart brengen van alle invoerpunten: niet alleen de voor de hand liggende zoekvelden en formulieren, maar ook URL-parameters, HTTP-headers, cookies en verborgen velden. Overal waar invoer uiteindelijk in een query terecht kan komen, is een potentieel injectiepunt.

Vervolgens testen we die punten gericht. We sturen invoer die de syntaxis van een query zou breken en letten op afwijkingen: een databasefout, een gewijzigde respons, een verschil in reactietijd of een onverwachte redirect. Een enkele aanhalingsteken die een 500-fout oplevert, is een klassiek eerste signaal. Vanaf dat punt verfijnen we: bevestigen dat we de query daadwerkelijk beïnvloeden, bepalen welk databasetype eronder zit, en inschatten hoe ver de kwetsbaarheid reikt.

Tools zoals sqlmap zetten we in om het bevestigen en uitbaten te versnellen, maar altijd onder handmatige regie en binnen de afgesproken scope. De waarde van een pentest zit niet in het draaien van een tool, maar in het beoordelen van de context: is dit invoerpunt bereikbaar zonder authenticatie, welke data staat op het spel, en wat is de werkelijke impact voor deze organisatie? Die vertaling van technische bevinding naar bedrijfsrisico is waar een geautomatiseerde scan stopt en de auditor begint.

## Waarom geparametriseerde queries de oplossing zijn

Er bestaan allerlei tussenoplossingen tegen SQL-injectie, maar er is er maar één die het probleem bij de wortel aanpakt: geparametriseerde queries, ook wel prepared statements genoemd. Bij deze aanpak stuur je de query en de gebruikersinvoer als twee gescheiden dingen naar de database. De structuur van de query staat vast, en de invoer wordt uitsluitend als data behandeld, nooit als uitvoerbare code. Daarmee verdwijnt de vermenging van code en data die de kwetsbaarheid mogelijk maakt.

Dit is fundamenteel iets anders dan het escapen of filteren van invoer. Escaping probeert gevaarlijke tekens onschadelijk te maken, maar is foutgevoelig: één vergeten geval, één afwijkende tekenset of één plek waar de ontwikkelaar de regel omzeilt, en het gat is er weer. Geparametriseerde queries verplaatsen de verantwoordelijkheid naar de databasedriver, die de scheiding structureel afdwingt. Vrijwel elk modern framework en elke ORM ondersteunt dit standaard; het risico ontstaat juist waar ontwikkelaars die abstractie omzeilen met handmatig samengestelde queries.

Een terechte nuance: parametrisatie werkt voor de waarden in een query, maar niet voor structurele onderdelen zoals tabel- of kolomnamen. Wie die dynamisch wil maken, moet werken met een strikte allowlist van toegestane waarden in plaats van gebruikersinvoer rechtstreeks in de querystructuur te verwerken.

## Verdediging in lagen

Geparametriseerde queries zijn de basis, maar een robuuste verdediging bestaat uit meerdere lagen. Invoervalidatie op basis van verwacht formaat, type en lengte vangt een deel van de rommel al vroeg af en is goede hygiëne, ook al is het geen vervanging voor parametrisatie. Het principe van minimale rechten beperkt de schade: geeft het applicatieaccount alleen de databaserechten die het echt nodig heeft, dan kan een geslaagde injectie minder ver reiken. Zorgvuldige foutafhandeling voorkomt dat databasefouten met tabelnamen en querystructuur naar de gebruiker lekken, wat een aanvaller waardevolle informatie zou geven. En een Web Application Firewall kan bekende aanvalspatronen tegenhouden, al is dat een aanvullende drempel en nooit de structurele oplossing; een WAF is te omzeilen en mag nooit de reden zijn om de code niet te herstellen.

## Van bevinding naar herstel

Vindt een pentest een SQL-injectie, dan is het herstel doorgaans helder: vervang de kwetsbare query door een geparametriseerde variant en controleer of dezelfde constructie elders in de code voorkomt. Die tweede stap wordt vaak vergeten. SQL-injectie is zelden een geïsoleerd geval; als een ontwikkelaar op één plek queries handmatig samenstelt, doet die dat waarschijnlijk vaker. Wij adviseren daarom altijd om na een bevinding de codebase te doorzoeken op hetzelfde patroon en het herstel breed door te voeren.

Na het herstel hoort een hertest. Een bevinding is pas gesloten als aantoonbaar is dat het injectiepunt niet langer exploiteerbaar is en dat de oplossing geen nieuwe problemen introduceert. Die verificatiestap maakt het verschil tussen een afgevinkt rapport en daadwerkelijk verlaagd risico.

Wil je zekerheid dat jouw webapplicatie bestand is tegen SQL-injectie en andere injectiekwetsbaarheden? Secure Audit voert webapplicatie-pentests uit waarbij we handmatig en gericht testen, de impact vertalen naar jouw context en concreet hersteladvies geven, inclusief hertest. Neem contact op voor een vrijblijvend gesprek.