HAN krijgt 175.000 euro boete voor SQL-injectie en onversleutelde wachtwoorden

De Hogeschool van Arnhem en Nijmegen heeft een AVG-boete van 175.000 euro gekregen omdat zij de persoonsgegevens van studenten onvoldoende beveiligde. Een hacker wist in 2021 via een SQL-injectie in een webformulier gegevens te stelen. De Autoriteit Persoonsgegevens concludeerde daarop dat de HAN haar beveiliging niet genoeg op orde had.

De Nederlandse privacytoezichthouder begon het onderzoek in 2021, nadat de onderwijsinstelling getroffen werd door een datalek. Bij dat datalek stal een aanvaller onder andere naw-gegevens, maar in sommige gevallen ook wachtwoorden, cv's, legitimatiebewijzen en bsn's. De hacker probeerde de HAN af te persen, maar de school ging daar niet in mee en betaalde het losgeld niet. De hacker eiste destijds omgerekend zo'n 165.000 euro in bitcoin.

Hoewel de HAN niet betaalde, komt het datalek de school nu alsnog duur te staan. De AP begon een onderzoek nadat de HAN het datalek had gemeld. Dat onderzoek ging, benadrukt de AP, niet over de hack zelf, maar over de algemene beveiliging van persoonsgegevens. Bedrijven en instanties moeten onder de AVG gepaste maatregelen nemen om data goed te beveiligen. Dat heeft de HAN niet gedaan, concludeert de AP.

Opvallend is dat de hacker op wel erg eenvoudige wijze de systemen binnendrong. Dat gebeurde met een SQL-injectie in een webformulier, waarbij de aanvaller bij 'een databaseserver kon komen die meerdere databases omvat'. De HAN was zich ervan bewust dat dat mogelijk was, maar nam onvoldoende maatregelen om zich daartegen te beschermen. "De HAN heeft vervolgens desgevraagd aan de AP verklaard dat haar programmeurs zich bewust waren van het risico van SQL-injectie en dat daarover een zogenoemd bestpracticesbeleid bestond", zegt de AP, maar de HAN had geen risicoanalyse opgesteld en kon niet bewijzen dat dat bestpracticesbeleid werd nageleefd.

Bovendien maakte de HAN meer fouten in het databasebeleid. Het loggen en monitoren van toegang was onvoldoende, zegt de AP. Zo logde de server alleen query’s die te lang waren of heel veel records in één keer opvroegen. Daardoor merkte de HAN de aanval niet op. "De AP heeft kunnen vaststellen dat er twee keer eerder sprake was van een SQL‑injectie, terwijl de HAN dat zelf niet heeft opgemerkt", schrijft de AP.

Verder had de HAN een beleid om toegang te beperken voor specifieke accounts, maar dat werd niet goed toegepast. Uiteindelijk bleek een gebruiker alle rechten op de database te hebben. Ook had de HAN wel een verwijderingsbeleid voor oude data, maar ook dat werd niet goed nageleefd.

De HAN sloeg wachtwoorden ook onversleuteld op in de database. Dat gebeurde in 4381 gevallen. Ook werden 5194 wachtwoorden opgeslagen met een MD5- of SHA1-hash. Deze algoritmes zijn al geruime tijd niet meer veilig. Het ging om oude data waarvan de HAN zich niet realiseerde dat die nog in de database aanwezig waren.

Door die slechte beveiligingspraktijken overtreedt de HAN artikel 32 van de AVG op meerdere punten, zegt de AP. Artikel 32 heeft betrekking op adequate beveiliging van gegevens. De HAN erkent dat overigens. De AP prijst de onderwijsinstelling voor de manier waarop zij omging met de onderzoeksresultaten. "Tijdens en na het onderzoek heeft de HAN ten aanzien van de hierboven geconstateerde tekortkomingen, aan de AP toegelicht welke herstelacties zij heeft uitgevoerd om de geconstateerde tekortkomingen te verhelpen en de overtreding aldus te beëindigen."

Dat meedenken heeft er ook toe geleid dat de boete relatief mild is. De basisboete voor zo'n overtreding zou 310.000 euro zijn en kan oplopen tot 500.000 euro, maar de AP verlaagt dat bedrag naar 175.000 euro. "Concluderend stelt de AP vast dat de HAN zich actief heeft ingezet om de gevolgen voor betrokkenen in kaart te brengen, de kwalificaties daarvan ruim op te vatten en de gevolgen waar mogelijk weg te nemen. Deze omstandigheden leiden tot matiging van de basisboete."

Reacties (110)

[delpit]

Dus om de beveiliging te verbeteren halen we geld weg bij de instelling die dat moet realiseren. Hmmm

het lijkt mij beter wanneer we in dit soort gevallen juist verplichten extra te investeren op de probleemgebieden. Vaak is het namelijk het gevecht van IT tegenover “business”, waarbij security, LCM en dergelijke regelmatig ondersneeuwen ten opzichte van functionaliteit.

[avelrd]

En daarom had security de business moeten inlichten over de potentiële kosten van dit risico niet te mitigeren. En daarmee maak je het voor de business een goedkopere optie om het dus wel te mitigeren. (Kans op) Boetes helpen security juist met de business overtuigingen.

[Yzord]

Heb ze in 2015 al gewaarschuwd dat de boel niet op orde was en ik was zelf onderdeel van serverbeheer op de HAN. Maar omdat ict bestaat uit vele eilandjes en deze vooral bestaan uit dino’s die eerder hun neus ophalen voor mensen met “complot ideeen” dan dat ze hun eigen fouten willen of kunnen rechtzetten was voor mij een van de redenen om maar te vertrekken.

Want de onderste laag van server veiligheid bestaat uit vele scriptjes die ooit iemand heeft geschreven om de boel aan elkaar te verbinden en deze had meer aanzien bij ict dan de snotblaag die de einde van ons tijdperk met een bel en reclamebord tijdens vergaderingen liep te verkondigen.

Kan nu wel “nananana” roepen, maar het doet mij nog steeds verdriet dat de gegevens van vele studenten en medewerkers maar weer eens open en bloot in te zien zijn. En dit is niet snel en makkelijk opgelost of ze moeten de hele boel vanaf het begin weer opnieuw opbouwen en dat gaat wel wat meer kosten. Hopelijk zijn de ogen nu wel geopend daar, maar ik vrees het ergste.

[Reactie gewijzigd door Yzord op 18 december 2025 01:52]

[Dekar]

Als een instelling door zeer grove nalatigheid persoonsgegevens lekt, dan is een boete echt wel gepast.

Neem in HBO-ICT stagiair in dienst van je eigen school en het is in een dag opgelost.

[Mathijs Kok]

Neem in HBO-ICT stagiair in dienst van je eigen school en het is in een dag opgelost.

Tuurlijk, want die kan een massief IT systeem in een dag van alle beveiligingsproblemen af helpen. Kan je me even zijn contact gegevens sturen want die persoon wil ik graag in dienst nemen.

[Dekar]

Ik heb het niet over alle kwetsbaarheden, maar wel over de paar punten die echt niet door de beugel kunnen. Ik neem aan dat de HAN snel een risicoanalyse zal doen na deze boete.

Waar ik het over heb is enkel het stukje code dat de user input moet lezen. Dat moet strikt als input data worden gelezen. Dat kan in alle gangbare frameworks enorm gemakkelijk aangepast worden.

En dat geldt ook voor de wachtwoorden. Dat is tegenwoordig zo simpel te hashen. Bv met Argon2. Dat die niet encrypted worden opgeslagen is echt van de vorige eeuw.

[watercoolertje]

Dus om de beveiliging te verbeteren halen we geld weg bij de instelling die dat moet realiseren. Hmmm

We zouden ze eigenlijk geld moeten geven zodat ze het op kunnen lossen toch?

Maar serieus, als je iets doet wat niet mag (nalatigheid in dit geval), moet daar gewoon een straf/boete tegenover staan, waarom zouden ze het anders in de toekomst willen voorkomen als er geen gevolgen zijn?

[Reactie gewijzigd door watercoolertje op 17 december 2025 12:21]

[Polydeukes]

Exact, het leidt juist tot een perverse prikkel. Als je je zaakjes niet op orde hebt, krijg je extra geld

[Argantonis]

Er zijn helaas gewoon straffen nodig, anders maakt het bedrijven weinig uit. Het doel van een bedrijf is winst maken, en als wie dan ook in het bedrijf de ernst van een lek niet het geld waard vindt (wat hier dus het geval was) dan wordt er niks verbeterd. Een investering vereisen is veel te vaag en moeilijk afdwingbaar. Wie gaat reviewen dat die ontwikkelaars dan idd x bedrag aan uurloon hebben besteed aan security-verbeteringen en of ze dat niet sowieso al hadden gedaan?

Het moet voor een bedrijf gewoon pijn doen. Het doel is namelijk preventie, niet dat de overheid bij duizenden bedrijven maar moet gaan toezien dat het achteraf verbeterd wordt.

[Kevinp]

Maar geen boete is ook geen optie.

Ik zou liever ook een strafrechtelijke zaak zien. Hieruit moet blijken of er vanuit bestuurlijk niveau nalatig is gehandeld.

Als jaren lang dit al aangegeven is en er wordt gezegd doen we niet moet je serieus overwegen om deze bestuurders te straffen.

[armageddon_2k1]

Nou, ik heb nu bij meerdere grote klanten gezeten en ik heb al vaak genoeg gezien dat het niet uitmaakt hoeveel geld er tegenaan gesmeten wordt voor de partijen die de boel regelen kwa beveiliging en user management, want het komt er elke keer op neer dat er gewoon een lading incompetente engineers zitten.

Er zijn een hoop hartstikke slimme engineers die alles echt goed proberen te doen en beperkt worden door 'management', maar er zijn ook een hoop FSP's waar gewoon echt incompetente nietskunners zitten. Dan maakt de hoevelheid investeringen echt niet uit.

[dwarfangel]

Wat ik hierin lees: als de HAN het datalek niet had gemeld, hadden ze geen boete gekregen?

[TijsZonderH]

Die kans is best groot en ook wel de kritiek van sommige experts. De AP treedt notoir weinig op tegen datalekken die niet gemeld worden, dus de kans dat je straf ontloopt door een datalek te verzwijgen is significant (zeker als je kijkt naar de onderbezetting van de AP).

[et36s]

Ipv van een boete, waar gaat dat geld naartoe? Kunnen ze voor dat geld verplicht worden een extern bedrijf in te schakelen om de issues op te lossen

[Koen88]

De issues zijn opgelost, daarom is de boete veel lager.

[demianmonteverd]

Beter gaan de makers op cursus.

[Sicos]

Altijd geparametriseerde input gebruiken op je SQL code en nooit je SQL statement aan elkaar string concatenaten... dat zou elke ontwikkelaar onderhand wel moeten weten.

[Tielenaar]

Echter komen er ook weer steeds nieuwe ontwikkelaars bij die dit wellicht nog niet weten. Het is niet per definitie het eerste dat je leert en soms wordt er gewoon zonder supervisie een enorme junior op een projectje gezet.

[Croga]

Geen enkel probleem. Goede CI/CD lost dat op met een test on commit.

En ja, ik weet dat dat bij de meeste bedrijven ook gewoon helemaal niet leeft... Goede engineering practices zijn niet sexy dus laat men die vaak achterwege. Het zou maar eens geld kosten zeg.

[MSalters]

Hoe test je op SQL injectie in CI/CD? Klinkt alsof je er niet voldoende van af weet. Dan krijg je precies dit soort ongelukken. "Onze CI/CD test zegt dat er geen probleem is dus dan is er geen probleem".

De gebruikelijke methode is inspectie, niet testen

[jackyallstar]

Pattern recognition per taal is volledig mogelijk. CI/CD Pipeline Tools zoals SonarCube kunnen dit soort code ontwerpen prima herkennen en tegenin adviseren. Afhankelijk van de SQL Client die je gebruikt zou je al simpele vlaggen kunnen zetten op specifieke commands die je niet wilt toestaan, zoals SqlClient.ExecuteRaw();

[MSalters]

Sonarcube is een tool voor automatische code inspectie. Dat is dus precies waar ik naar verwees als alternatief voor testen.

Handmatige code reviews zijn de andere vorm van inspectie.

[codeneos]

Sonarcube is een tool voor automatische code inspectie. Dat is dus precies waar ik naar verwees als alternatief voor testen.

Het is zeker geen alternatief voor een zoiets als een PEN test. En het is ook geen alternatief voor unit testing. Sonarqube is een UI boven op, vaak bestaande, een static code analyzers en heeft zelf ook ingebouwde analyzers. Het helpt om bugs te voorkomen en kan ook helpen security issues te voorkomen. En het doet dat door code te controleren op het toepassen van best practices. Maar het is geen alternatief voor testen.

Technische gezien maakt de SQ Analyzer die lokaal op de build agent uitgevoerd word (of op je systeem) een AST/CST van de code. Vervolgens heeft SQ een set aan regels per taal, die je kan fine-tunen, en rule violations worden gerapporteerd. De SQ server is vooral een control server die rapporten van de Analyzer visualiseert en waarin je regels beheerd.

[supersnathan94]

Dat is dus precies waar ik naar verwees als alternatief voor testen.

SonarQube (ja met een Q) is geen alternatief voor testen. Het heeft zelfs testen nodig voor het berekenen van code quality.

Static code analysis is gewoon een onderdeel van je CI/CD workflow. Niet alleen vanwege dit soort dingen, maar ook test coverage en tech debt.

[jackyallstar]

Het ging mij meer om de mogelijkheid dat je dit soort code zeker wel redelijkerwijs kan tegenhouden met automatisering en dat ik nogal arrogant vond om iemands kennis daarover te betwisten gezien er niks geks gezegd werd.


Kijk alles kan kapot als je echt wilt en principieel tussen alle preventie heen gaat zitten werken, maar als je zo ver gaat zoals bijvoorbeeld je eigen http client schrijven om je string af te kunnen vuren verwacht ik eigenlijk dat je een beetje weet wat je aan het doen bent. Automatisering is geen silver bullet maar het is zeker wel verstandig en toevoegen aan een collectie van hulpmiddelen die je kunnen helpen patterns en oplossingen te voorkomen die je wilt vermijden, en als een pipeline step ons peer reviews kan besparen op de code door preventief de build tegen te houden ben ik blijer dan dat ik door zoek naar de ultieme ene silver bullet tegen dit soort code, of automatisering uitsluit omdat het "maar" x% van de cases tegen kan houden.

[latka]

Een tool als sonarcube op een bestaande codebase zetten is altijd feest: mag je ineens duizenden meldingen na gaan lopen of het false positives zijn of niet. Het invoeren van dit soort tools op bestaande codebases is altijd iets complexer dan gewoon even installeren en gaan. En dan nog is het geen garantie dat al dit soort zaken gevonden worden.

[codeneos]

Dat ben ik niet met je eens. Als je sonarqube juist opzet krijg je alleen melding over de changes in de PR en niet over de hele code base. Simpel gezegd doet sonar een scan met en zonder de changes uit de PR, de nieuwe observaties is wat de dev terug krijgt en moet oplossen in de PR.

Over het algemeen zorgt dit er voor dat je kwaliteit van je code, over time, beter wordt. En bij de eerste setup los je alleen de security- en critical-issues op.

Verder is mijn ervaring dat het aantal false positives bij SQ meevalt.

[latka]

Als je het alleen op PRs doet dan zal het meevallen inderdaad. Mis je alleen alles wat in de core al rot is. Heb al jaren geen Sonar (de oude naam) gebruikt. Wellicht is het beter geworden.

[codeneos]

Mis je alleen alles wat in de core al rot is.

Waar, maar je draait in iedergeval de spreekwoordelijke kraan dicht en kan beginnen met dweilen.

En je hebt bovendien een mooi lijstje met hotspots waar de kwaliteit van de code het minste is die je kan gaan verbeteren. Zeker in de periodes dat er wat development capacity over is kan je dat gericht (er) inzetten.

Natuurlijk is het slechts een tool, en hoe bruikbaar zoiets is hangt er helemaal vanaf hoe het gebruikt wordt binnen een organisatie.

[jackyallstar]

Haha, of ook leuk, iemand buiten het team besluit dat het algemene SQ profiel binnen het bedrijf scherper moet zonder iemand te informeren, krijg je ineens warnings op eerder valide code.

[Croga]

Die ad-hominem is echt niet nodig hoor.

En nee, "Test zegt geen probleem dus is het goed" bestaat niet voor dit soort dingen. Wel "Test zegt probleem dus gaat niet naar productie". Dat elimineert al 95% van de menselijke inspectie. Het zou heel erg jammer zijn als je een inspectie moet doen op code waarvan deterministisch te bepalen is dat het kwetsbaarheden bevat.

SQL injectie is relatief eenvoudig op te testen. Het zoeken van een patroon waar user input direct resulteert in een query is niet heel erg ingewikkeld. Daar is echt geen menselijk brein voor nodig, dat is gewoon deterministisch af te vangen. Er zijn zelfs standaard tools, zoals SonarCube, beschikbaar die dit kunnen doen maar met een beetje moeite bouw je ook gewoon een eigen query op je source code daarvoor.

[Reactie gewijzigd door Croga op 17 december 2025 10:13]

[SPee]

En die test komt er automagisch?
Nee, het is nog altijd de ontwikkelaar die die test moet maken. En als die het concept "SQL injectie" niet kent, dan zal hij daarvoor ook geen test maken om dat af te dekken.

[Croga]

Je hoeft het concept SQL injectie helemaal niet te kennen om een standaard CI/CD test pipeline te maken met een standaard tool die standaard op allerlei standaard vulnerabilities test....

Dus ja, die test komt er automatisch zolang je je aan standaard engineering practices houdt. Net zo goed als dat er standaard een knopje in de gemiddelde CI/CD test suite zit om op library vulnerabilities te testen, om maar eens wat te noemen.

DevOps engineering is geen rocket science. Fouten die vaak genoeg gemaakt zijn, zijn ondertussen onderdeel van standaard test suites. En zeker zoiets als SQL injectie is zo basaal dat iedere test suite dat er wel in heeft zitten. Zie, bijvoorbeeld, https://docs.sonarsource.com/sonarqube-server/user-guide/rules/security-related-rules

[Reactie gewijzigd door Croga op 17 december 2025 12:52]

[jackyallstar]

Je laat het klinken alsof wij de eerste en enigen zijn die SQL-injection moet gaan tegenhouden:p Er zijn al tal developers jaren met deze vraag bezig geweest en hebben echt wel goede dingen neergezet. Geloof dat SonarCube zo'n beetje standaard vanuit de doos begint te piepen over SQL-injection en andere security en data-lek risico's.

[StephanVierkant]

Dat is inderdaad geen werk voor een test (als in: integration test, unit test), maar static analysis helpt je hier natuurlijk wel bij. En dat kan wel degelijk onderdeel zijn van je 'test' suite (Github Actions o.i.d.).

Elke taal heeft zo z'n eigen tools daarvoor. PHP heeft bijvoorbeeld PHPStan, Psalm, phan, etc. En ook je IDE helpt je erbij door waarschuwingen te geven als je domme dingen doet, en SQL injection toestaan is daar eentje van.

[codeneos]

Mijn ervaring is dat developers die de IDE extensies zelf weten te vinden niet degene zijn die de slechte code schrijven (of vergeten user input te escapen). Vaak zijn het de devs die IDEs maar lastig vinden en alleen extensies installeren als de hun senior ze daartoe instructies geeft.

[Argantonis]

Alleen als je dan ook fatsoenlijke tests hebt, of met hele simpele gevallen wat externe tools in je ci/cd pipeline laadt die het vinden. Ci/cd zelf zegt hier iig weinig over.

[Croga]

CI/CD is ook niet persé de juiste term. Het gaat meer om integration automation pipelines. Die worden vaak onder de noemer CI/CD gelegd maar voor dat laatste is nog wel wat meer nodig dan alleen dat....

En ja, dat vergt fatsoenlijk werk. Zoals eigenlijk alle software engineering eigenlijk fatsoenlijk werk vereist.

[readefries]

Nou dat vind ik echt geen valide excuus meer. Yolo driven development wat we in de jaren 90 normaal vonden is toch echt wel vervangen door SDLC, waarbij de review een belangrijke stap is en deze door een ervaring ontwikkelaar of via GitHub Advanced security b.v. er gewoon uit gevist worden.

[sky-]

Ja, maar dat is zijn punt ook niet. En besef dat er ook organisaties en omgevingen zijn die zaken niet op orde hebben op het gebied van SDLC, vanwege diverse redenen (zoals onkunde, of kosten).

[supersnathan94]

Van een organisatie die programmeurs opleid verwacht ik wel dat ze dit soort dingen ook af en toe eens langs de docerende populatie heen halen om te valideren of het met de onderwezen best practices valt te rijmen.

Op de hoogte zijn van het risico van SQL injection en er dan niks mee doen is echt een harde faal.

Ik heb geen enkele organisatie gezien waarbij dat risico acceptabel is. Simpelweg vanwege het feit dat het de meest simpel oplosbare hack is die er te vinden is en het ook de meest simpel uitvoerbare hack is om te doen.

[DeltaJuliett]

Of vibe coding. AI is getraind op het data van het internet en daar staat een hoop foutieve en outdated informatie op.

[Olaf van der Spek]

dat zou elke ontwikkelaar onderhand wel moeten weten.

Probleem is dat je dat eigenlijk niet zou hoeven te weten.. maar dat de interface zo zou moeten zijn dat het simpeler is om het goed te doen dan om het fout te doen.
Waarom werkt query("select * from users where name = ?", "Sicos") nog steeds niet in PHP?

https://www.php.net/manua...t.prepared-statements.php

[Reactie gewijzigd door Olaf van der Spek op 17 december 2025 10:02]

[codeneos]

Dan gebruik je toch een framework? Of je schrijft zelf een mini abstractie laagje waarmee je direct logging en ander zaken in mee neemt.

Je kan de gebruikte taal niet de schuld geven van een SQL injectie aanval. En zo moeilijke is het nou ook weer niet om het goed te doen ook zonder gebruik te maken van een bind syntax.

[Olaf van der Spek]

Dan gebruik je toch een framework?

Blijkbaar niet..

Je kan de gebruikte taal niet de schuld geven van een SQL injectie aanval.

Waarom niet?
De taal / API is de beste plek om dit op te lossen.

En zo moeilijke is het nou ook weer niet om het goed te doen ook zonder gebruik te maken van een bind syntax.

Blijkbaar wel.. het gaat al zo'n 20 jaar fout en het blijft fout gaan.

[air2]

Je zou het zeggen. Daarnaast is ook niet alles is parameteriseerbaar. Dus daar moet je dan soms omheen werken, wat de kans introduceert op injectie fouten, als je dat niet goed doet.

Maar knullig is het zeker.

[jaspro]

Niet alles is parameteriseerbaar, maar in die gevallen moet je usser input omzetten naar iets wat geen user input meer is, dat is dan wel weer veilig om in je SQL string te gebruiken

[Olaf van der Spek]

Niet alles is parameteriseerbaar,

Zoals?

maar in die gevallen moet je usser input omzetten naar iets wat geen user input meer is, dat is dan wel weer veilig om in je SQL string te gebruiken

Nope, daar gaat het dus fout. Zelfs als je een query dynamisch opbouwt, zou je parameters moeten kunnen gebruiken. Als dat niet kan is de client API niet goed genoeg.

[latka]

Select bla where id in (?,?,?,...) is een standaard ding waar je tegenaan loopt: variabel aantal argumenten dus.

[Olaf van der Spek]

Iets als dit zou qua interface moeten werken:
$q = "Select bla where id in (";
$q += make_query("?,", "a");
$q += make_query("?,", "b");
$q += make_query("?)", "c");
query($q)

[Reactie gewijzigd door Olaf van der Spek op 17 december 2025 10:24]

[jaspro]

Dat is prima te doen in C# / SQL. Je kan In(@parameter1,@parameter2,@parameter3) doen.
Als het variabel moet zijn kan dit met een for loop, en dynamisch je parameters plus waardes op bouwt.

[supersnathan94]

Daar heeft iedere ORM toch gewoon een oplossing voor? Dit is een zovaak voorkomend ding dat is echt geen reden om niet te parameteriseren. Je parameter is dan echter een collectie. Of je ORM expand het naar het juiste aantal placeholders. Postgres ondersteund ook native wat collectie zaken dus dan hoef je het niet eens verder op te lossen.

Bij duizend+ parameters wordt het een ander dingetje, maar dat is vanwege performance al niet zo slim. Dus daar moet je gewoon een andere oplossing voor gebruiken in je model.

[latka]

Met een ORM wel. Native SQL moet je dus gaan truken en je leesbare query omzetten in een for-loop oid.

[supersnathan94]

Waarom zou je native SQL willen doen? Ik heb eerlijk waar nog nooit een goede reden gevonden om dat te doen. De klanten die ik zie die het doen hebben zichzelf er enorm mee in een hoek geduwd en er alleen maar een grotere puinhoop mee gemaakt. Gebruik een ORM en call it a day. maakt je leven echt zo veel makkelijker.

Een edge case daargelaten sure (er is altijd wel ergens een edge case te vinden), maar dan moet je ook zelf maar even de moeite nemen om het dan ook goed te schrijven, want het zelf doen en dan alle security best practises niet doen is gewoon geen optie.

Zelfs in Java met JPA/hibernate kun je dit gewoon safe doen:

SELECT e FROM Entity e WHERE e.id IN :ids

query.setParameter("ids", idsCollection);

Prima alle controle over je queries, maar wel gewoon een veilig standaard. Ook met plain PHP en PDO zijn er veilige opties. Stackoverflow staat er vol mee.

Ik ben het wel met @Olaf van der Spek eens dat er echt weinig voorbeelden te noemen zijn die concreet maken dat dit echt een ding is.

Je kunt niet een edge case, die je zelf hebt veroorzaakt in je ontwerp, misbruiken om onveilige code op te leveren.

Er is vaak een reden dat bepaalde dingen niet al als standaard geïmplementeerd zijn in dit soort oude systemen. Als je jij (en daar bedoel ik dan iedere dev mee) het nodig hebt, is de kans vrij groot dat je je ontwerp niet helemaal op orde hebt. Er is een security of performance reden (of beide) waarom het niet acceptabel is.

Je haalt jezelf echt zo veel meer werk op de hals dan alleen die query bij te moeten houden dat het gewoon echt niet waard is.

[latka]

Ik heb een aantal codebases in beheer die de dinosaurussen nog ontmoet hebben... Voor nieuwbouw: gebruik jpa en ga door met je leven (totdat je bulk verwerking moet doen, dan is het een onding). Dus het wisselt heel erg in de praktijk.

[supersnathan94]

(totdat je bulk verwerking moet doen, dan is het een onding)

JPA is sowieso een onding, maar er zijn zat alternatieven.

Ik heb een aantal codebases in beheer die de dinosaurussen nog ontmoet hebben...

Oke, maar als dat het argument is. Het wordt toch tijd om eens naar vernieuwbouw te kijken hoor. Ik snap dat er niet altijd een "businesscase" voor te maken is, maar vaak ben je gewoon met Proof of concepts uit het jaar kruik aan het doordraaien en zijn er echt wel mogelijkheden om de operationele kosten te verminderen. OPEX wordt bij legacy projecten vaak onderbelicht en dat is ook gewoon en businesscase, want besparing op de vaste lasten die echt nog wel significant kan zijn.


anyways. Ander issue. Zelfs zonder ORM zijn er manieren om dit gewoon veilig te doen.je voorbeeld hier is er 1 van, maar als je die een beetje structureerd en daar een eigen standaard van maakt dan is dat prima onderhoudbaar te houden. In PHP met PDO moet dat immers ook.

[demianmonteverd]

Zou je kunnen oplossen met een array opbouwen met argumenten. Dan de query maken door lengte te nemen van de array, daarop de ?-componenten te expanderen en daarna kun je die binden over de array. Soms kun je zelfs splat operators toepassen (taal afhankelijk). En bij gecompileerde talen moet je misschien nog iets doen met casten, maar soms zit in de API ook een algemene bind method die je kunt gebruiken die meerdere soorten primitives kan ontvangen/verwerken in de bind.

[latka]

Ja, het is ook niet onmogelijk. Maar als ik code lees als:

result = prepare("select * from bla where id in (?1,?2,?3);").bind(1,a).bind(2,b).bind(3,c).execute();

versus:
sql = "select * from bla where id in (";
foreach p in params
sql = sql + sep + "?";
sep=",";
done
stmt = prepare(sql + ")");
foreach p in params
stmt.bind(count++, p);
done
result = stmt.execute();

Dan weet ik wel wat het wint qua onderhoudbaarheid/leesbaarheid (en dan de corner cases van een lege parameter lijst of meer IN clauses dan je DB driver ondersteunt nog niet eens meegenomen).

[demianmonteverd]

Je kunt er een functie van maken, en je hoeft niet twee loopjes te doen, kunt twee variablen nemen in een loop. Overigens heb je helemaal gelijk over het aantal parameters dat je zo kunt ingeven, er zijn altijd limieten, maar die raak je ook wel met string concat's.

[jackyallstar]

Tegenwoordig hebben we Linq en ORM's. Als je handmatig SQL loopt te schrijven en in leesbare strings weg zet zit je eigenlijk actief en moedwillig onderhoudspunten toe te voegen aan je applicatie. Die leuke string in jouw code gaat niet designtime roepen dat id niet meer bestaat omdat iemand vind dat het allemaal PK of FK moet heten zodat je beter weet wat het is oid. Dat worden hele mooie runtime errors dan!

Zelfs voor een high performant CQRS Request pipeline zou ik eerst codefirst gaan middeks Linq en een ORM, dan code first stored procedures overwegen en die dan naar domeinmodellen mappen, en als laatste nog steeds af raden strings in de code te gaan zitten proppen en vragen waarom je usecase de prioriteit van performance zo ver over veiligheid en maintainability heen heeft staan dat je alle no-no's bereidt bent toe te laten. 9 van de 10 keer is dat namelijk ongegrond, en nee we werken niet allemaal bij de drukstbezochte zoekmachine van de wereld, die trouwens ook ongetwijfeld aan horizontal scaling doet om de werklast te verdelen.

[Reactie gewijzigd door jackyallstar op 17 december 2025 23:04]

[air2]

Ja daar zijn we het ook wel over eens. Maar ik denk dat mensen op die plekken nog wel eens een foutje willen maken.

[demianmonteverd]

Daar zijn code reviews een mogelijk oplossing voor. Sommige geautomatiseerde oplossingen kunnen dergelijke fouten zelfs al vinden.

[Gamehack]

Dat heb ik zelf ook geleerd als ontwikkelaar. Op de HAN nota bene...

[supersnathan94]

Same XD. Practise what you preach teach, is nog nooit zo relevant geweest.

[bobkosse]

Misschien zijn de 'programmeurs' hier studenten die dit als opdracht gebouwd hebben. Deze zijn nog niet op de hoogte van all uitdagingen die er in de echte wereld zijn als het gaat om web-based-software. Dan had deze applicatie natuurlijk nooit live mogen gaan, daar is de HAN dan weer zelf verantwoordelijk voor.

Als het trouwens niet om studenten ging, blijft het verhaal dat deze app nooit live had gemogen natuurljk gewoon overeind.

[thomas.tnc]

ik denk dat met de populairiteit van vibe coden dit steeds meer een issue gaat worden. Als ik code door copilot laat genereren en er door heen scroll zie ik nog regelmatig dat er mogelijke SQL injectie vulnerabilities geschreven worden.

[demianmonteverd]

Je kunt de LLM vragen zijn eigen code te laten reviewen ook.

[thomas.tnc]

Ja dat kan, maar betekent ook niet altijd dat hij dat ziet. Tot je expliciet SQL injectie benoemt en dan zegt hij ‘oh je hebt gelijk’

[demianmonteverd]

Ze doen het vaak best aardig. Maar er gaat niets boven elkaar controleren, fuzzen, testen, etc..

[cricque]

Mijn studentjes weten dit ... eerst geef ik hun les SQL en dan gebruiken we python met sqlite en laat ik alles zonder ORM doen om dan met een ORM te werken. Zo leren ze dat het veel gemakkelijker kan en gaan ze nooit meer zelf prutsen !. Enja een ORM is niet voor alles de oplossing, maar dan hamer ik er al op dat ze parameters moeten gebruiken. Dit doe ik al bij hun zelf SQL schrijven en executen.

Maar er zijn genoeg mensen die "voor het gemak" dit soms wel eens overslagen en dan is er spijtig genoeg nog altijd een deel dat niet beter weet. Maar als ik hogeschool deed (jaren 98-2003) ... dan is dat dus nooit ter sprake gekomen, kan het mij toch niet herinneren in elk geval. Dus ik snap best als jij de enige bent die dit moet doen (en je bent 45-65 ergens) en je hebt dit nooit ergens gezien, dat je dan die fout maakt. Waarschijnlijk leef je dan wel onder een rots ofzo en lees je nooit veel, maar het zou kunnen. Dan zijn er ook mensen die "tutorials" volgen en waar dit gewoon standaard zo in staat, omdat het "gemakkelijker" is et voila

[demianmonteverd]

Je kunt ze ook nog een praktijk les geven en ze het zelf laten exploiteren. Dan leren ze zelf speuren naar fouten (hopelijk).

[watercoolertje]

en nooit je SQL statement aan elkaar string concatenaten...

Dat kan prima, alleen niet met user-input zonder te sanitizen...

[Olaf van der Spek]

Sanitizen is IMO al een code-smell..

[porn*]

Inderdaad behoorlijk schokkend dat dit anno 2025 nog een ding is.

[pegagus]

Het voorval had plaats in 2021

[orvintax]

Toen was dat ook al schandalig

[SilentLucidity]

Jawel, maar het is hier wel weer een gevalletje "Ik lees de titel en de reacties"

[porn*]

Klopt my bad had het gescand en dacht: omg nog steeds. Of het nou 25, 20, of 15 was geweest, allemaal even schandalig dat mensen dat nog steeds niet met parameterized queries werken.

[Skywalker27]

Topje van de ijsberg 99% software bakkers word er geknoeid Geld, haast, gemak zucht.

[MartijnHavinga]

.NET programmeur hier,
gebruik al jaren Linq2SQL/Entity framework/etc.
De enige plaats waar er in de software SQL statements uitgevoerd worden die de ontwikkelaar (deels) zelf heeft geschreven is bij wijzigingen in de database zelf (nieuw veld, nieuwe tabel, etc.).
Ik geloof niet dat .NET het enige framework is dat hier (standaard) libraries voor heeft.

[vinkjb]

Het was de stagair die nog niets wist en er geen controle was.

[svennd]

Een domme gok : dit is oude legacy code waar niemand nog tijd en geld kan/mag insteken.

[SuperDre]

Tja, er is zo zoveel dat een programmeur hedendaags zou moeten weten, maar als jij dat niet weet kun je er ook niets aan doen. Ik zie dagelijks zaken misgaan bij (nieuwe) developers waarbij ik dan denk, "hoezo weet je dat niet", maargoed, ook ik heb niet expertise van alles, dus als ik bv webdevelopment moet gaan doen, dan zal ik ook relatief simpele beveiligingsfouten maken, want zelfs na meer dan 30 jaar developer zijn heb ik nog steeds nooit echt webdevelopment gedaan.

[Sicos]

Als developer kan je gewoon niet alles weten

[avlt]

Wat is het nu van deze boete?

De HAN heeft volledig meegewerkt aan het onderzoek en niets proberen te verduisteren, ze leiden reputatieschade: wie wil er nog IT studeren op een instelling die zijn beveiliging niet op orde heeft?

En verder, als die boete betaald moet worden, gaat dat ten koste van het onderwijsbudget of van het ICT-budget. Volgens mij zou het effectiever zijn om het bedrag gedwongen te investeren in betere ICT-beveiliging.

[iAR]

wie wil er nog IT studeren op een instelling die zijn beveiliging niet op orde heeft?

De kwaliteit van IT-onderwijs en de afdelingen die de ondersteuning regelen hebben doorgaans niets met elkaar te maken. Onhandig, ja. Maar uiteindelijk onzinnige opmerking.

Overigens is het allemaal al opgelost.

[demianmonteverd]

In de reacties op het artikel schrijven ex-studenten dat ze expliciet hebben geleerd hiervoor te waken.

[lvdgraaff]

offtopic:
Did you really call your son Robert’); DROP TABLE students —?

https://xkcd.com/327/

[ocarina]

Jeesh. En dat in een tijd dat little Bobby Tables een fullfledged white hat hacker is en z'n moeder in een bejaardentehuis zit...

Voor wie niet in de IT zit en er mogelijk nog niet bekend mee was: https://xkcd.com/327/

[bigtree]

Zo zie je maar. Als je systemen hebt die persoonsgegevens verwerken kun je die maar beter laten auditen. Anders wordt het ongevraagd voor je gedaan.

[ZeroXT]

Zo logde de server alleen query’s die te lang waren of heel veel records in één keer opvroegen

Ik denk dat hier bedoeld wordt dat de executies van qeury's te lang waren. Niet de daadwerkelijk query als string.

' OR 1=1--

zeer korte query, maar desastreus.

[Sicos]

Je kan ook alle tabellen, inner en outer joinen op alles en nog wat... ook zeer leuk voor je SQL server

[demianmonteverd]

Classic!

[JerryJerryJerry]

De HAN, waar ooit op een C: schijf unencrypted admin en wachtwoord stonden... (notabene waar informatica gehuisvest is ) Duurde welgeteld 5 minuten voordat SysOp de ruimte binnenstormde om te kijken wie er ingelogd was...

.... uiteraard had ondertekende allang van computer gewisseld

Leuk detail, ik deed Bouwkunde... wachtwoord was houtluis