SQL-injectie SQLi

Wat SQL-injectie is

U heeft een webwinkel. Een bezoeker typt iets vreemds in het zoekvak, drukt op Enter, en de pagina toont hem de naam, het telefoonnummer en de bestelgeschiedenis van al uw klanten. Niemand heeft een wachtwoord gestolen. Hij typte de juiste woorden op de verkeerde plek, en uw website deed de rest. Dat is SQL-injectie.

De meeste websites bewaren hun informatie in een database: een geordende opslag van tabellen, een beetje zoals een verzameling spreadsheets. Om die informatie te lezen of te wijzigen, spreekt de website een taal die SQL heet (Structured Query Language). Elk verzoek dat ze stuurt is een query, bijvoorbeeld "zoek de klant met dit e-mailadres".

SQL-injectie gebeurt wanneer een website wat een bezoeker typt rechtstreeks in een van die query's plakt. Typt de bezoeker SQL in plaats van gewone tekst, dan ziet de database het verschil niet en volgt ze de opdracht van de aanvaller alsof de website die zelf had geschreven. Vaak wordt de naam afgekort tot SQLi.

Hoe een SQL-injectieaanval werkt

Denk aan een bankmedewerker die elk briefje van een klant woord voor woord doorgeeft aan de mensen in de kluis. Een gewoon briefje zegt "laat mij mijn saldo zien". Een slim briefje zegt "laat mij mijn saldo zien, en maak ook alle kluisjes open". Als de medewerker het briefje nooit eerst leest, doen de mensen in de kluis wat er staat.

Op een website gaan de stappen meestal zo:

1. De aanvaller zoekt een plek die tekst naar de database stuurt: een inlogformulier, een zoekvak, een contactformulier of het webadres zelf, zoals een productpagina die eindigt op "?id=25".
2. Hij typt een klein stukje SQL in plaats van gewone tekst. Een bekend voorbeeld is ' OR '1'='1 typen in het wachtwoordveld van een inlogformulier.
3. De website plakt die tekst zonder controle aan haar eigen query. De query vraagt nu zoiets als "laat deze persoon binnen als het wachtwoord klopt, of als 1 gelijk is aan 1".
4. Omdat 1 altijd gelijk is aan 1, antwoordt de database ja, en de aanvaller is ingelogd zonder ook maar één wachtwoord te kennen.

Sommige aanvallen gaan stiller. Bij blinde SQL-injectie laat de pagina helemaal geen gegevens zien, dus stelt de aanvaller de database ja-of-nee-vragen en kijkt hij hoe de pagina reageert, of hoe lang ze nodig heeft om te laden. Met de hand is dat traag werk, en daarom laten aanvallers het doen door gratis automatische tools.

Wat een aanvaller ermee kan doen

Zodra de database zijn opdrachten volgt, hangt de schade af van wat het databaseaccount van de website mag. Vaak is dat veel meer dan de website nodig heeft. Een aanvaller kan dan misschien:

• privégegevens lezen, zoals namen, adressen, e-mails en bestelgeschiedenis van klanten, medische dossiers of opgeslagen wachtwoorden
• inloggen als een andere gebruiker, ook als beheerder
• gegevens wijzigen, zoals prijzen, saldi of de status van bestellingen
• hele tabellen wissen, of de complete database
• in sommige opstellingen de server zelf bereiken en daar schadelijke bestanden neerzetten

Waarom dit belangrijk is voor uw bedrijf

SQL-injectie is een van de oudste aanvallen op het web, en ze is er nog steeds. OWASP, een open gemeenschap die de bekende lijst OWASP Top 10 van risico's voor webapplicaties publiceert, houdt injectie al jaren op die lijst. De aanval is makkelijk te proberen, en veel websites hebben nog ergens een vergeten formulier dat haar doorlaat.

Voor een ondernemer is de echte schade zelden technisch. Het is een uitgelekte klantenlijst, een winkel die tegen de verkeerde prijs verkoopt, een boekingssysteem dat een week aan afspraken kwijtraakt, of een bericht dat u naar klanten moet sturen om te zeggen dat hun gegevens op straat lagen. In veel landen verplichten privacywetten zoals de AVG (GDPR) u bovendien om persoonsgegevens te beschermen en datalekken te melden.

Is elk formulier op uw website gebouwd met dit risico in gedachten? Websites die snel in elkaar zijn gezet met oude plugins, of die door de jaren heen door veel handen zijn aangepast, verbergen vaker een zwakke plek.

Hoe u een website beschermt tegen SQL-injectie

De belangrijkste oplossing is bekend, en ze werkt. Het grootste deel van de bescherming zit in hoe de website is gebouwd, dus dit zijn goede vragen voor uw ontwikkelaars of uw leverancier.

• Prepared statements. Ook wel geparametriseerde query's genoemd. De website stuurt de query en de tekst van de bezoeker apart, zodat de database die tekst altijd als gewone gegevens behandelt en nooit als opdracht. Dit is de belangrijkste verdediging. Moderne frameworks zoals Laravel doen dit standaard als ontwikkelaars hun ingebouwde databasetools gebruiken.
• Invoercontrole. Een veld voor een telefoonnummer hoort alleen cijfers te accepteren, en een datumveld alleen datums. Vreemde invoer vroeg weigeren sluit veel deuren.
• Minimale rechten. Het account waarmee de website de database benadert, mag alleen de rechten hebben die het nodig heeft. Een openbare zoekpagina heeft geen enkele reden om tabellen te wissen.
• Terughoudende foutmeldingen. Een gedetailleerde databasefout op het scherm geeft een aanvaller een plattegrond. Laat bezoekers een korte, eenvoudige melding zien en bewaar de details in privélogs.
• Updates. Houd het platform, de plugins en de bibliotheken bij, want oude versies hebben vaak bekende gaten.
• Een web application firewall. Dit is een filter voor de website die veel bekende aanvalspatronen tegenhoudt voordat ze uw code bereiken. Hij helpt, maar repareert geen onveilige code.
• Regelmatig testen. Een pentest (een veilige, geplande aanval door experts) en een kwetsbaarheidsscan vinden de zwakke plekken voordat een aanvaller dat doet.

Zo verhouden een paar dagelijkse gewoontes zich tot elkaar:

Veelgemaakte fouten

• Vertrouwen op controles in de browser. Controles die op het apparaat van de bezoeker zelf draaien, zijn makkelijk te omzeilen, dus de server moet alles nog een keer controleren.
• Denken dat een kleine website veilig is. Automatische tools zoeken enorme aantallen websites af, ongeacht hun grootte.
• Eén formulier repareren en de rest vergeten. Het zoekvak, de filters, het webadres en de API achter een mobiele app hebben allemaal dezelfde zorg nodig.
• Wachtwoorden als gewone tekst opslaan. Lekken er gegevens uit, dan zijn wachtwoorden die met sterke hashing zijn opgeslagen (omgezet in een onleesbare code die niet terug te lezen is) veel moeilijker te misbruiken.
• Alleen op een firewall vertrouwen. Een filter levert tijd op. De onveilige query erachter moet nog steeds worden hersteld.

Hoe wij kunnen helpen

Bij Linkysoft hoort het testen op SQL-injectie bij onze diensten voor cyberbeveiliging. We voeren veilige, gesimuleerde aanvallen uit op uw website, app en API, bekijken de code en geven u een begrijpelijke lijst van wat we vonden en hoe u het oplost. Na de reparaties testen we opnieuw. Dat werkt ook voor websites die door andere teams zijn gebouwd, en de gratis beveiligingscheck is een makkelijke eerste stap.

Plant u een nieuw systeem? Onze webapplicaties en beheersystemen zijn veilig vanaf het ontwerp, met versterking volgens de OWASP Top 10 en een pentest voor de lancering.