Periode 2, Thema 1 voor Security, Privacy en Ethiek

Doelgroep: MBO niveau 4 – eerstejaars studenten.

Wat is een SQL-injectie?

Stel je voor dat je een website hebt waar je kunt inloggen, zoals een webshop. Daar worden dingen zoals je naam, je e-mailadres en je wachtwoord opgeslagen in een grote digitale opslagplaats; een database. De website gebruikt speciale codes (SQL) om met die database te praten, zodat alles goed werkt.

Een SQL-injectie is eigenlijk een trucje dat hackers gebruiken om die database binnen te komen zonder toestemming. Ze voeren SQL-code in bij een inputveld op een webformulier in en die code zorgt ervoor dat de website dingen doet die de hacker wil in plaats van dat de normale functionaliteit wordt uitgevoerd.

Bijvoorbeeld: in plaats van je normale zoekopdracht (bijvoorbeeld “gratis t-shirts”) voert de hacker een stukje code in die de database vertelt om gegevens van andere klanten op te halen, zoals hun wachtwoorden of e-mailadressen.

Hoe werkt een SQL-injectie?

Een SQL-injectie werkt doordat de hacker via een zoekveld of formulier op de website een code invoert die de website eigenlijk niet zou moeten uitvoeren. De website stuurt dan een soort “valse” opdracht naar de database en als de website niet goed beveiligd is kan de hacker zo toegang krijgen tot geheime informatie.

Dit zorgt ervoor dat de website alles uit de database haalt zelfs informatie die helemaal niet bedoeld is voor de hacker zoals wachtwoorden of betaalgegevens. Eigenlijk voegt een hacker op een slimme manier SQL-code toe aan de bestaande SQL-code die door de pagina wordt uitgevoerd.

Soorten SQL-injecties

Er zijn verschillende manieren waarop hackers deze trucs kunnen uitvoeren. Ik zal ze proberen simpel uit te leggen:

In-band SQL-injectie (of klassieke SQLi): Dit is de meest voorkomende manier. De hacker voert zijn code in en de website toont meteen het resultaat. Stel je voor dat de hacker in de zoekbalk iets invult dat de website een fout laat maken en die fout toont veel gevoelige informatie over de database (zoals de naam van andere tabellen of gebruikers).

Blind SQL-injectie (Inferential SQLi): Bij deze aanval ziet de hacker niet meteen het resultaat. In plaats daarvan moet hij de reacties van de website goed in de gaten houden om erachter te komen wat er gebeurt. Dit is als een soort raadspel: de hacker moet de website vragen stellen en op basis van de reactie weet hij of hij iets goed heeft gedaan.

Out-of-band SQL-injectie: Dit is een minder vaak gebruikte techniek, maar ook gevaarlijk. De hacker gebruikt andere manieren, zoals het versturen van gegevens via internet (bijvoorbeeld via DNS of HTTP) om informatie te stelen zonder dat de website dit meteen merkt.

Waarom zou een hacker dit doen?

Een hacker kan allerlei gegevens stelen zoals:

• Gebruikersnamen
• Wachtwoorden
• E-mailadressen
• Betaalgegevens (zoals creditcardnummers)
• Zelfs privé-informatie die helemaal niet bedoeld is om openbaar te zijn en dus een inbreuk op de privacy is op degene waar die informatie over gaat.

Klein voorbeeld van een SQL-injectie:

Stel, je hebt een zoekveld op een webshop waar je producten kunt zoeken. Een hacker typt in plaats van “laptop” de volgende tekst:

‘ OR ‘1’=’1′ —

Wat de hacker hiermee doet is ervoor zorgen dat de ingebouwde SQL-query wordt onderbroken met een statement die altijd werkt en ‘true’ terug geeft, want 1=1 is altijd waar. De website geeft dan niet alleen de laptops, maar ook allerlei andere gegevens die niet voor de hacker bedoeld zijn.

• De ‘ sluit het vorige commando af
• OR zegt dat het vorige OF anders het volgende waar moet zijn
• 1=1 is altijd waar en zorgt ervoor dat we een conditie maken die altijd ‘true’ terug geeft en dus succesvol uitgevoerd wordt.
• De — zorgt ervoor dat alles erna wordt genegeerd en als een soort van comment in de SQL-code wordt gezien.

Hoe kun je voorkomen dat iemand jouw website hackt met een SQL-injectie?

Gelukkig zijn er een paar belangrijke dingen die je kunt doen om dit te voorkomen:

• Scheiden van gegevens: Zet gevoelige gegevens (zoals wachtwoorden en e-mailadressen) niet samen met andere gegevens in één database. Als je ze verspreidt over verschillende databases is het voor hackers moeilijker om alles te stelen.

• Prepared statements: Dit betekent dat je de website zo programmeert dat de zoekopdrachten van gebruikers veilig zijn zonder dat er gevaarlijke code ingevoerd kan worden. In plaats van elke keer een nieuwe SQL-query te maken op basis van gebruikersinvoer gebruik je van tevoren gedefinieerde SQL-sjablonen. Dit voorkomt dat hackers hun eigen code kunnen toevoegen.

Bijvoorbeeld:

In dit voorbeeld worden de gebruikersinvoer ($username en $password) veilig verwerkt via de bindParam() functie. Dit voorkomt dat SQL-code wordt ingevoerd:

prepare(“SELECT * FROM users WHERE username = :username AND password = :password”);
$stmt->bindParam(‘:username’, $username);
$stmt->bindParam(‘:password’, $password);
$stmt->execute();

• Invoercontrole: Controleer altijd wat mensen invoeren. Dit kan door een lijst te maken van wat wel en niet toegestaan is in een zoekveld of formulier. Als iemand iets probeert in te voeren wat niet op de lijst staat blokkeer je die invoer.

Bijvoorbeeld:

htmlentities():

$user_input = $_POST[‘user_input’];
echo htmlentities($user_input);

Dit heeft niet direct echt iets te maken met MySQL-invoer, maar ik raad toch aan om hier ook verstand van te hebben. Door de invoer eerst als argument in de htmlentities functie mee te geven voorkom je html-invoer. Zo heb ik bijvoorbeeld ooit zelf een chat-site gemaakt waar gebruikers met elkaar konden chatten. Hier hield ik rekening met MySQL-invoer, maar was ik HTML-invoer vergeten. Chatberichten konden zo de opmaak van de site veranderen.

mysql_real_escape_string():
De functie mysql_real_escape_string() wordt gebruikt om speciale tekens te ontsmetten in een string voordat deze wordt gebruikt in een SQL-query, en voorkomt zo dat een hacker kwaadaardige code kan invoeren die de query manipuleert.

Met mysql_real_escape_string() wordt de invoer als het ware schoongemaakt. Dit voer je uit in je PHP code:

$username = mysql_real_escape_string($_POST[‘username’]);
$password = mysql_real_escape_string($_POST[‘password’]);
$query = “SELECT * FROM users WHERE username = ‘$username’ AND password = ‘$password’”;

In dit geval wordt de invoer veilig omgezet naar gewone tekst (een string). MySQL code wordt dus als tekst opgeslagen in de database en niet als uitvoerbare code.

Let op:
mysql_real_escape_string() was alleen beschikbaar voor de MySQL extensie in PHP, die inmiddels als verouderd wordt beschouwd. De huidige aanbevolen methoden voor werken met databases in PHP zijn PDO (PHP Data Objects) en MySQLi, die beide prepared statements ondersteunen.

Prepared statements zijn nu de beste praktijk en bieden een veel robuustere beveiliging, omdat ze de SQL-query scheiden van de gebruikersinvoer, wat voorkomt dat deze in de query kan worden geïnjecteerd.

Toch gehackt? Wat doe je dan?

Back-ups, Herstel en Privacy: waarom is dit belangrijk?

Als je een website bouwt met een database wil je natuurlijk niet dat al je gegevens verloren gaan door een fout, een crash of een hack zoals de eerdergenoemde SQL-injectie. Daarom is het sowieso verstandig om back-ups te maken en een goed plan te hebben voor als er iets misgaat. In de les van mij heb je al geleerd hoe een SQL-injectie werkt en hoe je deze kunt voorkomen. Maar stel dat een hacker tóch weet binnen te komen… Wat doe je dan?

Waarom zijn back-ups zo belangrijk?

Een back-up is simpel gezegd een kopie van je database die je ergens voor de zekerheid wegzet op een andere plek. Als je website gehackt wordt of als je per ongeluk iets verwijdert kun je deze back-up gebruiken om alles weer terug te zetten. Zonder een back-up ben je alles kwijt en zou je helemaal opnieuw moeten beginnen.

Maar een back-up moet wel goed geregeld zijn. Dit hangt samen met twee belangrijke termen:

RTO (Recovery Time Objective) – Hoe snel moet je systeem weer online zijn na een probleem?

Je wilt niet dat het dagen duurt voordat alles weer werkt. Een korte RTO betekent dat je snel weer kunt herstellen.

RPO (Recovery Point Objective) – Hoeveel gegevensverlies is nog acceptabel?

Dit gaat over de tijd vanaf de laatste back-up tot nu. Stel dat je elke dag om 23:59 een back-up maakt, maar je website crasht om 22:00. Dan ben je bijna een dag aan data kwijt. Hoe vaak je een back-up maakt bepaalt hoe groot het verlies aan data is. Voor een simpele blogsite is een back-up per dag misschien genoeg, maar voor een live webshop met echte bestellingen wil je misschien elk uur een back-up maken.

Back-ups en Privacy: Wat mag je eigenlijk opslaan?

Naast beveiliging moet je als ontwikkelaar ook nadenken over privacy. Wanneer je een database hebt met persoonlijke gegevens, zoals namen, adressen en wachtwoorden ben je verantwoordelijk voor de bescherming hiervan.

Bijvoorbeeld:

Wat als een hacker via een SQL-injectie wachtwoorden steelt?
Wat als iemand je back-up in handen krijgt?
Om deze risico’s te verkleinen kun je veiligheidsmaatregelen nemen, zoals:

Versleuteling – Zorg ervoor dat wachtwoorden nooit in platte tekst worden opgeslagen, maar altijd versleuteld. Dit kun je bij de invoer naar de database al doen, zodat zelfs een admin die in de database kan kijken alleen een gehashed wachtwoord ziet staan.

Veilige opslag – Bewaar back-ups op een veilige plek en zorg ervoor dat ze niet zomaar te downloaden zijn via een browser.

Beperkte toegang – Niet iedereen in een team hoeft bij alle gegevens te kunnen. Gebruik rechtenbeheer om te bepalen wie wat mag zien en wijzigen.

De AVG (Algemene Verordening Gegevensbescherming).

Iedereen die gegevens verzamelt van andere mensen komt vroeg of laat in aanraking met de AVG. Het is als softwareontwikkelaar heel erg belangrijk te weten van de AVG en wat je verantwoordelijkheden hierin zijn.

De AVG in het kort:
Door de Algemene verordening gegevensbescherming (AVG) hebben organisaties die persoonsgegevens verzamelen en gebruiken meer verantwoordelijkheden gekregen. En de mensen van wie zij gegevens gebruiken hebben meer rechten gekregen. Houden organisaties zich niet aan de regels? Dan kunnen zij een boete krijgen. Als je later zelf softwareontwikkelaar wilt worden is het dus verstandig hier vanaf te weten.

De AVG is sinds 25 mei 2018 van toepassing in de hele Europese Unie (EU) en geldt voor iedereen die persoonsgegevens verwerkt.

• De AVG geldt niet alleen voor grote bedrijven, maar ook voor kleine ondernemers.
• De AVG geldt ook voor de overheid.
• De AVG geldt niet alleen voor organisaties, maar ook voor individuele personen die persoonsgegevens verwerken.

Bron: https://www.autoriteitpersoonsgegevens.nl/themas/basis-avg/avg-algemeen/de-avg-in-het-kort

Ethische vraag: Wat zou jij doen?

Als ontwikkelaar heb je dus niet alleen te maken met techniek, maar ook met de verantwoordelijkheid over de werking van je applicatie en de eventuele risico’s (en stappen om dit tegen te gaan) die hierbij horen. Want wat als je per ongeluk een kwetsbaarheid in je code laat zitten waardoor iemand een SQL-injectie kan uitvoeren en gegevens kan stelen?

Denk maar eens na over deze vragen:

Stel je voor dat je ontdekt dat de database van een bedrijf waar je werkt onveilig is opgeslagen. Meld je dit ook als het bedrijf het probleem misschien negeert? Wat als je een lek ontdekt in de website van je school? Hack je het systeem om het aan te tonen of meld je het op een andere manier?

Waarom zijn deze ethische keuzes belangrijk?

Als je als ontwikkelaar kwetsbaarheden in je code negeert, kunnen er serieuze gevolgen zijn: je kunt het vertrouwen van gebruikers verliezen, het bedrijf kan juridische problemen krijgen en/of er kan financiële schade optreden. Het is niet alleen belangrijk om code te schrijven die werkt, maar ook om goed na te denken over de veiligheid en privacy van gebruikers. Je keuzes kunnen echt impact hebben.

Relevant en actueel artikel

Bron: https://gigazine.net/gsc_news/en/20250318-postgresql-injection-vulnerability

​In december 2024 werd een systeem van het Amerikaanse ministerie van Financiën gehackt door een groep die vermoedelijk werd gesteund door de Chinese overheid. De aanvallers maakten gebruik van een kwetsbaarheid in PostgreSQL die meer dan negen jaar onopgemerkt was gebleven. Hierbij was het uiteindelijk mogelijk om een SQL-injectie uit te voeren.

Dit heeft de aanvallers uiteindelijk in staat gesteld om toegang te krijgen tot de database en willekeurige systeemcommando’s uit te voeren via de interactieve interface van PostgreSQL, genaamd psql.

Het probleem ontstond doordat de PHP functie pg_escape_string die bedoeld is om gebruikersinvoer te ‘ontsmetten’ niet goed genoeg omging met bepaalde multibyte Unicode-tekens zoals uitgelegd in het artikel. Hierdoor konden kwaadwillenden specifieke tekens invoeren die deze functie (met ontsnappingsroutine) omzeilden en zo schadelijke commando’s in SQL uitvoeren.

Reflectie
Dit voorbeeld laat ook maar weer zien hoe zelfs lang bestaande en veelgebruikte systemen kwetsbaar kunnen zijn zonder dat iemand het doorheeft. Het is best verbazingwekkend dat een fout zo lang onopgemerkt kon blijven en het laat voor mij het belang zien van kritisch blijven kijken naar beveiliging; zelfs bij tools die al tijden als betrouwbaar worden gezien. Deze kwetsbaarheid werd pas op 11 februari 2025 verholpen (heel erg recent dus nog).

In mijn eigen werk en onderwijspraktijk wil ik dit gebruiken als voorbeeld om studenten bewust te maken van het belang van input-validatie en het up-to-date houden van software.

Samenvatting

Een SQL-injectie is een truc die hackers gebruiken om via een website toegang te krijgen tot een database door bijvoorbeeld speciale code in te voeren in een zoekveld of formulier. Als de website niet goed beveiligd is kan de hacker gevoelige informatie stelen, zoals wachtwoorden, e-mailadressen of betaalgegevens.

Gelukkig kun je SQL-injecties voorkomen door goed te programmeren, te controleren wat gebruikers invoeren en door gegevens goed te scheiden. Zo blijft je website veilig!

Mijn visie: wees je altijd bewust dat je als softwareontwikkelaar naast het technisch laten werken van je applicatie ook de verantwoordelijkheid hebt om ervoor te zorgen dat de beveiliging in orde is, zodat privacygevoelige gegevens niet zomaar gestolen kunnen worden. Daarnaast is het altijd goed om in het achterhoofd te houden hoe je eventuele risico’s vermijdt en na te denken over de eventuele gevolgen als je dit niet zou doen, want de keuzes die je maakt kunnen invloed hebben op zowel de mensen die je software gebruiken als het bedrijf waarvoor je werkt. Verantwoordelijk omgaan met je werk is dus echt heel erg belangrijk!

Bronnen / Literatuur

Webpagina’s en artikelen (met raadpleegdatum)

NordVPN. (z.d.). Wat is een SQL-injectie? https://nordvpn.com/nl/blog/sql-injectie
Geraadpleegd op 17 maart 2025, om 09:00 uur.

W3Schools. (z.d.). PHP Forms. https://www.w3schools.com/php/php_forms.asp
Geraadpleegd op 17 maart 2025, om 09:15 uur.

W3Schools. (z.d.). PHP MySQL Select. https://www.w3schools.com/php/php_mysql_select.asp
Geraadpleegd op 17 maart 2025, om 09:15 uur.

W3Schools. (z.d.). PHP MySQL Select WHERE. https://www.w3schools.com/php/php_mysql_select_where.asp
Geraadpleegd op 17 maart 2025, om 09:15 uur.

W3Schools. (z.d.). How to create a login form. https://www.w3schools.com/howto/howto_css_login_form.asp
Geraadpleegd op 17 maart 2025, om 09:15 uur.

Chris Brown. (2022, 9 januari). SQL Injection Tutorial – Learn How to Prevent SQL Injection Vulnerability [Video]. YouTube. https://www.youtube.com/watch?v=wcaiKgQU6VE
Geraadpleegd op 17 maart 2025, om 09:26 uur.

Academind. (2019, 12 juli). What is SQL Injection? [Video]. YouTube. https://www.youtube.com/watch?v=2OPVViV-GQk
Geraadpleegd op 17 maart 2025, om 09:32 uur.

YouTube. (z.d.). In-band SQLi – Zoekresultaten. https://www.youtube.com/results?search_query=In-band+SQLi
Geraadpleegd op 17 maart 2025, om 10:27 uur.

W3Schools. (z.d.). SQL UNION Operator. https://www.w3schools.com/sql/sql_union.asp
Geraadpleegd op 17 maart 2025, om 10:33 uur.

InView. (z.d.). Wetboek van Strafrecht – Artikel 350: Beschadiging van goederen of dieren. https://www.inview.nl/openCitation/ida9baddda039c2b10b16e8dfb9d6005e2/wetboek-van-strafrecht-artikel-350
Geraadpleegd op 17 maart 2025.

InView. (z.d.). Wetboek van Strafrecht – Artikel 350a: Manipulatie van computergegevens. https://www.inview.nl/document/id7feb77da402548f6ab8a952b087f4bd1/wetboek-van-strafrecht-artikel-350a-opzettelijke-manipulatie-computergegevens-01-07-2015-tot
Geraadpleegd op 17 maart 2025.

Openbaar Ministerie. (z.d.). Wetsartikel computervredebreuk. https://www.om.nl/onderwerpen/cybercrime/hack_right/wetsartikel-computervredebreuk
Geraadpleegd op 17 maart 2025.

Autoriteit Persoonsgegevens. (z.d.). De AVG in het kort. https://www.autoriteitpersoonsgegevens.nl/themas/basis-avg/avg-algemeen/de-avg-in-het-kort
Geraadpleegd op 17 maart 2025.

Boek:

Dolphijn, J. (2022). Technische cryber security. BrinkmanICT.