Beste programmeurs, dit kan écht niet meer

Hoe SQL-injection aanvallen eindelijk tot het verleden gaan behoren

Door: Mark Kazemier & Yanniek van Dooren

De Russische militaire inlichtingendienst haalde tijdens de Amerikaanse verkiezingen in 2016 data van duizenden kiezers uit het computernetwerk van de Illinois State Board of Elections. Dat stond in het Mueller-rapport dat in april openbaar werd.

Deze hackers gebruikten een techniek genaamd “SQL-injection”, dat 20 jaar geleden voor het eerst werd gebruikt. Een eeuwigheid geleden in de IT-wereld. Ondertussen staat het internet bol van tools, trainingen en tutorials om applicaties tegen deze vorm van hacking te beschermen. En toch staat SQL-injection nog steeds op nummer 1 in de lijst van grootste securityrisico’s van het Open Web Application Security Project (OWASP). Zelfs grote organisaties zijn niet voldoende beschermd: de laatste maanden kwamen onder andere Oracle, Lenovo en Georgia Tech University in het nieuws omdat hun computernetwerken blootgesteld waren, met alle gevolgen van dien.

Hoe is dat mogelijk? Wij spraken Mark Kazemier, Procam-alumnus en Information Security Risk Analyst bij ABN AMRO, om hier antwoord op te krijgen. Maar eerst: wat is SQL-injection precies?

SQL en SQL-injection
SQL is een standaard programmeertaal die wordt gebruikt om met een database te communiceren. Door middel van commando’s lees je data af, voeg je data toe, verander je data of verwijder je het uit de database. Als administrator van een website kun je hiermee bijvoorbeeld informatie opvragen over het klikgedrag van je gebruikers, de e-mailadressen van klanten ophalen of prospects verwijderen die niet meer relevant zijn. Ook als websitegebruiker communiceer je constant met een database: bijvoorbeeld wanneer je een account aanmaakt, inlogt, een formulier invult en zelfs wanneer je pagina’s aanklikt. Deze acties worden automatisch vertaald in SQL-commando’s waar de database op reageert. Alles goed en wel, zolang de commando’s gebruikt worden zoals ze bedoeld waren. En daar gaat het vaak mis.

Stel je voor dat iemand de database niet voedt met echte data, maar met kleine stukjes code. Een voorbeeld: een website vraagt om je naam, maar in plaats daarvan voer je een stukje code in dat de database de opdracht geeft om alle data te verwijderen. Als de website niet beveiligd is tegen dit soort injecties kan iedereen zonder autorisatie van buitenaf opdrachten geven. Dat is natuurlijk niet de bedoeling.

Mark: “Zoals bijna alle security-issues is SQL-injection terug te brengen op gebruikersinvoer. De programmeur gaat er vanuit dat de gebruiker te vertrouwen is en alleen verwachte waarden invult, en ondertussen manipuleren hackers de invoer zo dat het programma toch iets anders doet.”

“Het belangrijkste is dat veiligheid van applicaties topprioriteit krijgt.”

“Dit mag niet meer voorkomen”
SQL-injection is eenvoudig op te lossen en mag volgens Mark daarom eigenlijk niet meer voorkomen. Programmeurs kunnen zelfs kiezen uit verschillende opties, die uitgebreid beschreven staan in de SQL injection prevention cheat sheet van het OWASP. “Zelf raad ik meestal het gebruik van prepared statements aan. Dat houdt in dat je eerst een query naar je database stuurt waarin je aangeeft waar je gebruikersinvoer verwacht. Nadat de database de query heeft geaccepteerd, geef je pas aan welke gebruikersinvoer er in de query gezet moet worden. Zo voorkom je dat de database gebruikersinvoer kan interpreteren als code.”

Waarom is SQL-injection dan toch nog zo vaak succesvol? Volgens Mark spelen verschillende factoren hier een rol. “Opleidingen besteden te weinig aandacht aan security, en daarnaast bevatten de lesmaterialen in boeken en artikelen op het Internet vaak voorbeelden die onveilig zijn. Bovendien hebben veel programmeurs zichzelf het programmeren aangeleerd, waardoor ze fundamentele kennis op het gebied van bijvoorbeeld security gemist kunnen hebben.”

Tips van een risk expert
Natuurlijk hebben opleidingsinstituten de verantwoordelijkheid om hun studenten van de juiste kennis en ervaring te voorzien voordat ze afstuderen. Maar ook bedrijven moeten hun rol serieus nemen, zeker nu steeds meer IT’ers geen formele studieachtergrond in IT hebben. Mark geeft vier tips aan bedrijven:

Stuur al je programmeurs op een security-cursus. Het OWASP biedt bijvoorbeeld goede cursussen aan bij hun conferenties.
Neem een security-expert aan die als een soort security hero functioneert binnen het bedrijf.
Voer regelmatig penetratietesten uit, waarin je een hacker vraagt te proberen je code of applicatie te hacken.
Voor grotere bedrijven: gebruik tools als Checkmarx en Fortify om je code automatisch te scannen op kwetsbaarheden.

Het belangrijkste is dat veiligheid van applicaties topprioriteit krijgt, en dat dit blijkt uit het beleid van bedrijven. “Security is wat mij betreft een onderdeel van kwaliteit. Een programma moet snel en begrijpelijk zijn, maar óók veilig.”

“Niet veel bedrijven hebben een samoerai om de security te handhaven, stuur daarom al je programmeurs op een security-cursus.”

Mark Kazemier in Japan

Gaat jouw hart net als dat van Mark sneller kloppen van vraagstukken over security? Dan wil je onze TechTalk over Cybersecurity op 12 juni op het hoofdkantoor van ABN AMRO in Amsterdam niet missen. Schrijf je meteen in, dan zien we je daar!

Beste programmeurs, dit kan écht niet meer

Hoe SQL-injection aanvallen eindelijk tot het verleden gaan behoren

Door: Mark Kazemier & Yanniek van Dooren

Lees ook

Een goede optie voor na je PhD: het Science & Business Fellowship bij Janssen Vaccines

Positief versus negatief; een observatie in de trein

Verhuizing: nog een laatste groet

Formjacking 101

De onverwachte voordelen van het werkende leven

Welk type afstudeerder ben jij?