SQL-injectie: hoe een simpel invoerveld een hele database kan blootleggen
Stel je voor: je vult op een website je gebruikersnaam in om in te loggen. Achter de schermen stuurt de site die naam door naar een database met een kant-en-klare vraag, bijvoorbeeld "zoek de gebruiker met deze naam op". Normaal gesproken werkt dat prima. Maar wat als je, in plaats van een gewone naam, een stukje tekst invult dat de database zelf als commando interpreteert in plaats van als gegeven? Dan kan de database ineens dingen doen die de programmeur nooit had bedoeld, zoals het prijsgeven van wachtwoorden van alle gebruikers, of het aanpassen en verwijderen van gegevens. Dit verschijnsel heet SQL-injectie, een van de oudste en hardnekkigste beveiligingsproblemen in software.
Een handige analogie: denk aan een balie waar een medewerker jouw naam op een formulier schrijft en dat formulier doorgeeft aan de administratie. Normaal schrijf je gewoon "Jan Jansen". Maar stel dat je in plaats daarvan schrijft: "Jan Jansen, en geef mij ook alle dossiers van andere klanten". Als de administratie dat zinnetje letterlijk als extra instructie leest in plaats van als naam, ontstaat er een probleem. SQL-injectie werkt in de kern precies zo: kwaadwillende tekst wordt door een onvoorzichtig geprogrammeerde website per ongeluk behandeld als commando in plaats van als data.
Wat is het precies?
SQL (Structured Query Language) is de standaardtaal waarmee programma's met relationele databases communiceren, denk aan systemen als MySQL, PostgreSQL, Oracle of Microsoft SQL Server. Vrijwel elke website die gebruikersgegevens, bestellingen of content opslaat, gebruikt op de achtergrond zo'n database, en dus ook SQL-opdrachten ("queries") om gegevens op te vragen of te wijzigen.
Het probleem ontstaat wanneer een programmeur een query in elkaar zet door tekst die de gebruiker zelf heeft ingevoerd, direct te "plakken" in de opdracht, zonder die tekst eerst te controleren of af te schermen. Vult iemand in een zoekveld gewoon een productnaam in, dan werkt dat goed. Maar vult iemand in plaats daarvan tekens in die in SQL een speciale betekenis hebben (zoals een aanhalingsteken of het woord OR), dan kan de betekenis van de hele query veranderen. Een bekend, puur illustratief voorbeeld dat in vrijwel elk leerboek en op de website van OWASP (een gezaghebbende beveiligingsorganisatie) terugkomt, is het invullen van iets als een aanhalingsteken gevolgd door een altijd-ware conditie in een inlogveld. Als de onderliggende query niet goed is beveiligd, kan de voorwaarde "controleer of wachtwoord klopt" daardoor worden omzeild.
De oplossing die de softwarewereld inmiddels breed heeft omarmd, heet parameterized queries of prepared statements. Daarbij wordt de structuur van de SQL-opdracht van tevoren vastgelegd, en wordt gebruikersinvoer altijd apart als "gegeven" meegegeven in plaats van als tekst die in de opdracht wordt geplakt. De database weet dan gegarandeerd welk deel commando is en welk deel data, ongeacht wat de gebruiker intypt. Vrijwel alle moderne programmeertalen en databaseverbindingen ondersteunen dit standaard.
Wat wil men ermee bereiken?
Het vakgebied rond SQL-injectie bestaat niet om aanvallen mogelijk te maken, maar om ze te voorkomen, op te sporen en de schade ervan te begrijpen. Beveiligingsonderzoekers en zogeheten pentesters (mensen die met toestemming systemen testen op zwakke plekken) zoeken actief naar dit soort kwetsbaarheden in websites en applicaties, zodat bedrijven ze kunnen repareren voordat kwaadwillenden ze vinden.
Daarnaast richt secure coding, het vakgebied van veilig programmeren, zich op het aanleren van technieken en gewoontes waarmee ontwikkelaars dit soort fouten van meet af aan vermijden. Organisaties als OWASP stellen richtlijnen, checklists en trainingsmateriaal op met als doel het aantal kwetsbare applicaties structureel te verlagen. Het uiteindelijke doel is dus vertrouwen: gebruikers moeten erop kunnen rekenen dat hun gegevens, van banksaldi tot medische dossiers, niet zomaar via een invoerveld buitgemaakt kunnen worden.
Voorbeelden uit de praktijk
SQL-injectie heeft in de afgelopen twintig jaar bij verschillende grote databeveiligingsincidenten een rol gespeeld:
- Heartland Payment Systems (2008) — Een Amerikaanse betalingsverwerker werd slachtoffer van een van de grootste datalekken uit die tijd, waarbij tientallen miljoenen creditcardgegevens werden buitgemaakt. Onderzoek wees uit dat de aanvallers via SQL-injectie toegang tot interne systemen hadden verkregen.
- Sony Pictures (2011) — De hackersgroep LulzSec claimde gegevens van honderdduizenden gebruikers te hebben gestolen via een SQL-injectiekwetsbaarheid in de website van Sony Pictures.
- TalkTalk (2015) — Bij deze Britse telecomaanbieder werden persoonsgegevens van ruim 150.000 klanten gestolen. Het Britse toezicht concludeerde dat een verouderde, kwetsbare databasecomponent met een bekend, niet-gepatcht SQL-injectielek de oorzaak was.
- 7-Eleven en andere Amerikaanse retailers (2007-2008) — Een groep rond Albert Gonzalez gebruikte SQL-injectie als een van de technieken om binnen te dringen in betaalsystemen van meerdere Amerikaanse ketens, wat uiteindelijk leidde tot een van de grootste creditcardfraudezaken tot dan toe.
Deze zaken laten zien dat SQL-injectie geen theoretisch probleem is, maar decennialang tot concrete, grootschalige schade heeft geleid, vaak juist bij organisaties die grote hoeveelheden gevoelige gegevens beheerden.
Hoe ver is de techniek?
De kennis om SQL-injectie te voorkomen bestaat al sinds eind jaren negentig, en toch duikt het probleem nog steeds op. Het staat al jaren onder de bekendste kwetsbaarheden in de "OWASP Top 10", een periodiek bijgewerkte lijst van de meest voorkomende webapplicatiekwetsbaarheden, al is de precieze positie de laatste edities iets gezakt doordat andere risicocategorieën zijn toegevoegd of herschikt.
De belangrijkste vooruitgang zit niet zozeer in nieuwe aanvalstechnieken, maar in betere verdediging. Moderne ontwikkelraamwerken (frameworks) en zogeheten ORM's (Object-Relational Mappers, hulpmiddelen die programmeurs toestaan met objecten te werken in plaats van rechtstreeks SQL te schrijven) gebruiken tegenwoordig standaard parameterized queries, waardoor de kwetsbaarheid bij nieuw geschreven code veel minder vaak per ongeluk ontstaat. Geautomatiseerde scanners en zogeheten Web Application Firewalls (WAF's), die verdachte patronen in inkomend verkeer herkennen en blokkeren, vormen een extra vangnet.
Toch blijft het probleem hardnekkig, vooral in verouderde ("legacy") code die soms al tientallen jaren meedraait, in maatwerksoftware van kleinere bedrijven zonder specialistische beveiligingskennis, en bij ontwikkelaars die de basisprincipes niet kennen of onder tijdsdruk bochten afsnijden. Beveiligingsonderzoekers zijn het erover eens dat SQL-injectie technisch gezien een grotendeels "opgelost" probleem is, maar dat de praktijk van softwareontwikkeling wereldwijd nog altijd achterloopt op die kennis.
Wie werken eraan?
OWASP (Open Worldwide Application Security Project) is de meest aangehaalde non-profitorganisatie op dit gebied; zij publiceren richtlijnen, cheatsheets en de eerdergenoemde Top 10 die wereldwijd als referentie dienen. MITRE beheert de Common Weakness Enumeration (CWE), een gestandaardiseerde catalogus van softwarekwetsbaarheden waarin SQL-injectie is opgenomen als CWE-89, en onderhoudt samen met partners ook de CVE-database van concrete gemelde kwetsbaarheden. Het Amerikaanse NIST (National Institute of Standards and Technology) geeft aanvullende richtlijnen voor veilige softwareontwikkeling.
Daarnaast investeren grote technologiebedrijven zoals Google, Microsoft en Meta in bug bounty-programma's, waarbij externe onderzoekers een beloning krijgen voor het verantwoord melden van kwetsbaarheden zoals SQL-injectie. Universiteiten en academische onderzoeksgroepen bestuderen geautomatiseerde detectiemethoden, bijvoorbeeld met behulp van statische codeanalyse en, meer recent, machine learning. Op nationaal niveau houden instanties zoals het Nederlandse NCSC (Nationaal Cyber Security Centrum) organisaties op de hoogte van actuele dreigingen en beveiligingsadviezen, ook met betrekking tot dit soort kwetsbaarheden.