of hoe gebruikersgegevens te beschermen tegen SQL-injectie

fun facts:
SQL Injection bestaat al sinds websites gegevens in databases opslaan.
het Open Web Application Security Project beoordeelde injectieaanvallen als een van de top 10 bedreigingen waarmee webapplicaties in 2017 worden geconfronteerd.,
SQL injection is nog steeds verantwoordelijk voor veel grote datalekken. In 2016, De Illinois en Arizona State Board of Elections kiezersregistratie databases werden geschonden. Hoewel er geen informatie werd gestolen in Arizona, in Illinois aanvallers hadden toegang tot kiezer gegevens met inbegrip van naam, adres, geboortedatum, geslacht en gedeeltelijke sofinummers, voor ongeveer 80.000 mensen.⁴
dat is angstaanjagend, Wat Is het?
SQL-injectie is een type aanval dat zich richt op de database van een toepassing door het invoegen van onbedoelde code in invoervelden van gebruikers., Door gebruik te maken van SQL — syntaxis kan de aanvaller invoervelden gebruiken om informatie uit die databases vast te leggen-inclusief zaken als wachtwoorden en creditcardnummers. Iemand kan zelfs de controle over uw database of verwijder alle informatie die het bevat.
Hoe werkt het?
SQL-injectie werkt door informatie te gebruiken die in een veld is ingevoegd om de overeenkomstige SQL-instructie te manipuleren om een onbedoelde actie uit te voeren.,
Hier is een basisvoorbeeld:
SELECT * FROM customers WHERE name = " + user_name + ";
in dit voorbeeld laten we zeggen dat de variabele user_name direct wordt aangemaakt vanuit de input van de gebruiker op een website. Die string wordt ingevoegd in het bovenstaande SQL statement en alle velden met betrekking tot die gebruikersnaam worden geretourneerd. Geen probleem.
maar wat gebeurt er als iemand Steve” of 1=1; – typt als zijn gebruikersnaam? dan zou de gegenereerde SQL dit zijn:
SELECT * FROM customers WHERE name = "Steve" OR 1=1;--";
aangezien 1=1 altijd waar is, zou dit alle gegevens in de tabel retourneren. Niet Goed!,
Let’s take one more look at that comic.

The son’s name is Robert’); DROP TABLE students; — What would that do exactly?,
wel, we kunnen aannemen dat als kleine Bobby tabellen werden toegevoegd aan de school database van leerlingen, het SQL statement er ongeveer uit zou zien:
INSERT INTO students (name) VALUES ('<Student Name>');
… en als we Bobby invoegen…
INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');
omdat Bobby ‘ s naam De) bevat; het waarde argument wordt gesloten in het midden van zijn naam en de tekst die volgt op DROP TABLE studenten is een nieuwe SQL-verklaring die de hele tabel verwijdert. Tot slot de-aan het einde commentaren uit de resterende SQL, in wezen negeren van de rest van de originele code en ervoor te zorgen dat er geen fout optreedt.,

dus, wat je zegt is dat mijn gegevens nooit meer veilig zullen zijn?
Nee! Er zijn eigenlijk een heleboel stappen die je kunt nemen om jezelf te beschermen tegen dit soort aanvallen. Laten we eens kijken naar enkele:
- Reinig gegevens. De eerste stap is het controleren van wat de gebruiker mag invoeren. De beste manier om dit te doen is om de soorten invoer toegestaan voor een bepaald veld te beperken., Bijvoorbeeld in een veld met telefoonnummer kunt u alleen numerieke invoer toestaan, of in een e-mailveld kunt u alleen tekens toestaan die in een geldig e-mailadres kunnen worden gevonden. Uiteraard zullen sommige velden tekens nodig hebben die kunnen worden gebruikt in een aanval, dus deze methode is niet onverslaanbaar.
- Foutrapportage configureren. Vaak is de standaard Foutrapportage op Database Management Systemen heeft Ontwikkelaar debugging informatie in het. Dit kan nuttige informatie teruggeven aan de aanvaller, zoals tabelnamen of kolomnamen., Zorg ervoor dat u dit soort informatie niet aan externe gebruikers toont, omdat het het leven van een potentiële aanvaller veel gemakkelijker kan maken.
- gebruik gebonden Parameters. Met gebonden parameters kunt u gebruikersgegevens opslaan in een variabele en deze vervolgens invoegen in een SQL-statement dat is gemaakt met placeholders. Omdat het SQL statement en de variabele afzonderlijk naar de server worden verzonden, zijn gebonden parameters goed in het beschermen tegen injectie. Neem die kleine Bobby T., Een voorbeeld van bound parameters in een update methode in Ruby zou er als volgt uitzien:
def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end

Het is gek om te denken dat iets zo eenvoudig en goed begrepen nog steeds verantwoordelijk is voor zoveel big data-inbreuken., Zelfs in high profile gevallen zoals de kiezer registratie hacks hierboven vermeld en de recente Equifax inbreuk (die niet te wijten was aan SQL injectie, maar om een soortgelijke kwetsbaarheid die het bedrijf niet aan te pakken), de wortel van de kwetsbaarheid komt neer op menselijke fouten en gebrek aan aandacht voor detail. De tijd nemen om goed na te denken over het probleem kan ons aanzienlijk helpen gebruikersgegevens te beschermen tegen veelvoorkomende inbreuken, met name SQL-injecties.
Geef een reactie