Menu

Tutorial SQL-injectie testen (voorbeeld en preventie van SQL-injectieaanvallen)

  • Hoofd
  • Webtesten
  • Tutorial SQL-injectie testen (voorbeeld en preventie van SQL-injectieaanvallen)

sql injection testing tutorial example

Probeer Ons Instrument Voor Het Oplossen Van Problemen

het openen van .7z-bestanden op mac

SQL-injectievoorbeelden en manieren om SQL-injectieaanvallen op webtoepassingen te voorkomen

Bij het testen van een website of een systeem is het doel van de tester om ervoor te zorgen dat het geteste product zo goed mogelijk wordt beschermd.

Hiervoor wordt meestal een beveiligingstest uitgevoerd. Om dit soort tests uit te voeren, moeten we in eerste instantie overwegen welke aanvallen het meest waarschijnlijk zullen plaatsvinden. SQL Injection is een van die aanvallen.

SQL Injection Attach-voorbeeld en preventie

SQL-injectie wordt beschouwd als een van de meest voorkomende aanvallen, omdat het ernstige en schadelijke gevolgen kan hebben voor uw systeem en gevoelige gegevens.

Wat je leert:

Wat is SQL-injectie?

Sommige gebruikersinvoer kan worden gebruikt bij het inlijsten SQL-verklaringen die vervolgens worden uitgevoerd door de applicatie op de database. Het is mogelijk dat een applicatie de invoer van de gebruiker NIET correct verwerkt.

Als dit de zaak is, een kwaadwillende gebruiker kan onverwachte invoer aan de toepassing leveren die vervolgens wordt gebruikt om SQL-instructies in de database te framen en uit te voeren. Dit wordt SQL-injectie genoemd. De gevolgen van een dergelijke actie kunnen alarmerend zijn.

Zoals de naam al aangeeft, is het doel van de SQL Injection-aanval om de kwaadaardige SQL-code te injecteren.

Elk veld van een website is als een poort naar de database. In het aanmeldingsformulier voert de gebruiker de inloggegevens in, in het zoekveld voert de gebruiker een zoektekst in, in het gegevensopslagformulier voert de gebruiker gegevens in die moeten worden opgeslagen. Al deze aangegeven gegevens gaan naar de database.

In plaats van correcte gegevens, als er kwaadaardige code wordt ingevoerd, zijn er mogelijkheden voor ernstige schade aan de database en het hele systeem.

SQL-injectie wordt uitgevoerd met de programmeertaal SQL. SQL (Structured Query Language) wordt gebruikt voor het beheer van de gegevens in de database. Daarom wordt deze programmeertaalcode tijdens deze aanval gebruikt als een kwaadaardige injectie.

Dit is een van de meest populaire aanvallen, aangezien databases worden gebruikt voor bijna alle technologieën.

Veel applicaties gebruiken een soort database. Een te testen applicatie heeft mogelijk een gebruikersinterface die gebruikersinvoer accepteert die wordt gebruikt om de volgende taken uit te voeren:

# 1) Toon de relevante opgeslagen gegevens aan de gebruiker, bijv. de applicatie controleert de inloggegevens van de gebruiker met behulp van de inloggegevens die door de gebruiker zijn ingevoerd en stelt alleen de relevante functionaliteit en gegevens aan de gebruiker bloot

#twee) Sla de door de gebruiker ingevoerde gegevens op in de database, bijv. zodra de gebruiker een formulier invult en verzendt, gaat de applicatie verder met het opslaan van de gegevens in de database; deze gegevens worden dan zowel in dezelfde sessie als in volgende sessies ter beschikking gesteld van de gebruiker

Risico's van SQL-injectie

Tegenwoordig wordt voor bijna alle systemen en websites een database gebruikt, omdat gegevens ergens opgeslagen moeten worden.

Aangezien gevoelige gegevens in de database worden opgeslagen, zijn er meer risico's verbonden aan de beveiliging van het systeem. Als de gegevens van een persoonlijke website of blog zouden worden gestolen, zal er niet veel schade zijn in vergelijking met de gegevens die uit het banksysteem zouden worden gestolen.

Het belangrijkste doel van deze aanval is om de database van het systeem te hacken, daarom kunnen de gevolgen van deze aanval echt schadelijk zijn.

De volgende dingen kunnen het gevolg zijn van SQL-injectie

  • Hacken van andermans account.
  • Het stelen en kopiëren van gevoelige gegevens van websites of systemen.
  • De gevoelige gegevens van het systeem wijzigen.
  • De gevoelige gegevens van het systeem verwijderen.
  • De gebruiker kan inloggen op de applicatie als een andere gebruiker, zelfs als beheerder.
  • De gebruiker kan privé-informatie van andere gebruikers bekijken, b.v. details van de profielen van andere gebruikers, transactiegegevens, enz.
  • De gebruiker kan de configuratie-informatie van de applicatie en de gegevens van de andere gebruikers wijzigen.
  • De gebruiker kan de structuur van de database wijzigen; verwijder zelfs tabellen in de toepassingsdatabase.
  • De gebruiker zou de controle over de databaseserver kunnen overnemen en er naar believen opdrachten op kunnen uitvoeren.

De bovengenoemde risico's kunnen echt als ernstig worden beschouwd, aangezien het herstellen van een database of de gegevens ervan veel kan kosten. Het kan uw bedrijf een reputatie en geld kosten om de verloren gegevens en het systeem te herstellen. Daarom wordt het ten zeerste aanbevolen om uw systeem tegen dit soort aanvallen te beschermen en beveiligingstests te beschouwen als een goede investering in de reputatie van uw product en bedrijf.

Als tester zou ik willen opmerken dat testen tegen mogelijke aanvallen een goede gewoonte is, zelfs als Beveiligingstests was niet gepland. Op deze manier kunt u het product beschermen en testen tegen onverwachte gevallen en kwaadwillende gebruikers.

De essentie van deze aanval

Zoals eerder vermeld, is de essentie van deze aanval het hacken van de database met een kwaadaardig doel.

Om deze beveiligingstest uit te voeren, moet u in eerste instantie de kwetsbare systeemonderdelen vinden en vervolgens kwaadaardige SQL-code naar de database sturen. Als deze aanval mogelijk is voor een systeem, wordt de juiste kwaadaardige SQL-code verzonden en kunnen er schadelijke acties in de database worden uitgevoerd.

Elk veld van een website is als een poort naar de database. Alle gegevens of invoer die we gewoonlijk in een veld van het systeem of de website invoeren, gaan naar de databasequery. Daarom, in plaats van correcte gegevens, als we kwaadaardige code zouden typen, kan deze worden uitgevoerd in de databasequery en schadelijke gevolgen hebben.

Aanbevolen tool

# 1) Kiuwan

kiuwan banner

Vind en herstel kwetsbaarheden zoals SQL-injectie in uw code gemakkelijk in elke fase van de SDLC. Kiuwan voldoet aan de strengste beveiligingsnormen, waaronder OWASP, CWE, SANS 25, HIPPA en meer.

Integreer Kiuwan in uw IDE voor directe feedback tijdens de ontwikkeling. Kiuwan ondersteunt alle belangrijke programmeertalen en kan worden geïntegreerd met toonaangevende DevOps-tools.

​ Scan uw code gratis

Om deze aanval uit te voeren, moeten we de handeling en het doel van een geschikte databasequery wijzigen. Een van de mogelijke methoden om het uit te voeren, is door de vraag altijd waar te maken en daarna uw schadelijke code in te voegen. Het wijzigen van de databasequery naar altijd waar kan worden uitgevoerd met eenvoudige code zoals ‘of 1 = 1; -.

Essentie van SQL-injectie

Testers moeten in gedachten houden dat bij het controleren of het wijzigen van de query naar altijd waar kan worden uitgevoerd of niet, verschillende aanhalingstekens moeten worden geprobeerd - enkele en dubbele. Daarom, als we code zoals ‘of 1 = 1; - hebben geprobeerd, moeten we ook de code proberen met dubbele aanhalingstekens“ of 1 = 1; -.

Essentie van SQL-injectie

Bijvoorbeeld​ Laten we eens kijken dat we een zoekopdracht hebben, namelijk zoeken naar het ingevoerde woord in de databasetabel:

selecteer * uit notities nt waarbij nt.subject = ‘search_word‘;

Daarom, in plaats van het zoekwoord, als we een SQL Injection-query ‘of 1 = 1; - invoeren, wordt de query altijd waar.

selecteer * uit noten nt waarbij nt.subject = ‘‘ of 1 = 1; -

In dit geval wordt de parameter 'onderwerp' afgesloten met het aanhalingsteken en hebben we code of 1 = 1, waardoor een zoekopdracht altijd waar is. Met het teken '-' geven we commentaar op de rest van de querycode, die niet zal worden uitgevoerd. Het is een van de meest populaire en gemakkelijkste manieren om de query te beheren.

Er kunnen maar weinig andere codes worden gebruikt om de vraag altijd waar te maken, zoals:

  • ‘Of‘ abc ‘=‘ abc ‘; -
  • ‘Of‘ ‘=‘ ‘; -

Het belangrijkste hier is dat we na het kommateken elke kwaadaardige code kunnen invoeren die we graag zouden willen laten uitvoeren.

Bijvoorbeeld​ het kan ‘of 1 = 1 zijn; tafel notities laten vallen;​

Laat tafelnotities vallen

Als deze injectie mogelijk is, kan elke andere kwaadaardige code worden geschreven. In dit geval hangt het alleen af ​​van de kennis en intentie van de kwaadwillende gebruiker. Hoe SQL-injectie te controleren?

Het controleren op deze kwetsbaarheid is heel eenvoudig uit te voeren. Soms is het voldoende om ‘of’ in te typen in de geteste velden. Als het een onverwacht of buitengewoon bericht retourneert, kunnen we er zeker van zijn dat SQL-injectie mogelijk is voor dat veld.

Bijvoorbeeld ​ Als u een foutmelding krijgt als ‘Internal Server Error’ als zoekresultaat, dan kunnen we er zeker van zijn dat deze aanval mogelijk is in dat deel van het systeem.

Andere resultaten die een mogelijke aanval kunnen aangeven, zijn onder meer:

  • Lege pagina geladen.
  • Geen fout- of succesberichten - functionaliteit en pagina reageren niet op de invoer.
  • Succesbericht voor schadelijke code.

Laten we eens kijken hoe dit in de praktijk werkt.

Bijvoorbeeld, Laten we testen of een geschikt inlogvenster kwetsbaar is voor SQL-injectie. Voor dit doel typen we in het e-mailadres of wachtwoordveld gewoon teken zoals hieronder weergegeven.

E-mailadres

Als dergelijke invoer een resultaat oplevert zoals de foutmelding ‘Internal Server Error’ of een ander vermeld ongepast resultaat, dan kunnen we er bijna zeker van zijn dat deze aanval mogelijk is voor dat veld.

Interne Server Fout

Een heel lastig SQL-injectiecode kan ook worden geprobeerd. Ik zou willen vermelden dat ik in mijn carrière geen enkel geval ben tegengekomen waarin er een ‘Internal Server Error’ -melding was als gevolg van het teken, maar soms reageerden de velden niet voor meer gecompliceerde SQL-code.

Daarom is het controleren op SQL-injectie met een enkel aanhalingsteken ‘een vrij betrouwbare manier om te controleren of deze aanval mogelijk is of niet.

Als het enkele aanhalingsteken geen ongepast resultaat oplevert, kunnen we proberen dubbele aanhalingstekens in te voeren en de resultaten te controleren.

Alleenstaande citaat

Ook kan SQL-code voor het wijzigen van de query in always true worden beschouwd als een manier om te controleren of deze aanval mogelijk is of niet. Het sluit de parameter en verandert de zoekopdracht in ‘true’. Daarom kan dergelijke invoer, als het niet wordt gevalideerd, ook elk onverwacht resultaat retourneren en hetzelfde informeren dat deze aanval in dit geval mogelijk is.

Essentie van SQL-injectie

Het controleren op mogelijke SQL-aanvallen kan ook worden uitgevoerd via de link van de website. Stel dat we de link van een website hebben als http://www.testing.com/books=1 ​In dit geval is ‘boeken’ een parameter en ‘1’ is de waarde ervan. Als we in de verstrekte link ‘teken zouden schrijven in plaats van 1, dan zouden we controleren op mogelijke injectie.

Link daarom http://www.testing.com/books= wordt als een test of de SQL-aanval mogelijk is voor de website http://www.testing.com of niet.

Link testen

In dit geval, indien link http://www.testing.com/books= geeft een foutmelding zoals ‘Internal Server Error’ of een lege pagina of een ander onverwacht foutbericht terug, dan kunnen we er ook zeker van zijn dat SQL-injectie mogelijk is voor die website. Later kunnen we proberen om meer lastige SQL-code te verzenden via de link van de website.

Om te controleren of deze aanval mogelijk is via de link van de website of niet, kan ook code zoals ‘of 1 = 1; - worden verzonden.

Links testen

Als ervaren softwaretester wil ik eraan herinneren dat niet alleen de onverwachte foutmelding kan worden beschouwd als een SQL Injection-kwetsbaarheid. Veel testers controleren alleen op mogelijke aanvallen in overeenstemming met foutmeldingen.

Houd er echter rekening mee dat geen validatiefoutbericht of succesbericht voor kwaadaardige code ook een teken kan zijn dat deze aanval mogelijk is.

Beveiligingstests van webapplicaties tegen SQL-injectie

Beveiligingstesten van webapplicaties uitgelegd met eenvoudige voorbeelden:

Aangezien de gevolgen van het toestaan ​​van deze kwetsbaarheidstechniek ernstig kunnen zijn, volgt hieruit dat deze aanval moet worden getest tijdens het testen van de beveiliging van een toepassing. Laten we nu met een overzicht van deze techniek een paar praktische voorbeelden van SQL-injectie begrijpen.

Belangrijk: deze SQL-injectietest mag alleen in de testomgeving worden getest.

Als de applicatie een inlogpagina heeft, is het mogelijk dat de applicatie dynamische SQL gebruikt zoals onderstaand statement. Deze instructie retourneert naar verwachting ten minste één rij met de gebruikersgegevens uit de tabel Gebruikers als resultaatset wanneer er een rij is met de gebruikersnaam en het wachtwoord die in de SQL-instructie zijn ingevoerd.

SELECTEER * UIT gebruikers WAAR User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword ​

Als de tester John zou invoeren als strUserName (in het tekstvak voor gebruikersnaam) en Smith als strPassword (in het tekstvak voor wachtwoord), zou de bovenstaande SQL-instructie worden:

​

Als de tester John'– zou invoeren als strUserName en no strPassword, zou de SQL-instructie worden:

​

Merk op dat het deel van de SQL-instructie na John wordt omgezet in een opmerking. Als er een gebruiker was met de gebruikersnaam John in de tabel Gebruikers, zou de applicatie de tester kunnen laten inloggen als de gebruiker John. De tester kon nu de privégegevens van de gebruiker John bekijken.

Wat moet ik doen als de tester de naam van een bestaande gebruiker van de applicatie niet kent? In dat geval kan de tester gewone gebruikersnamen proberen, zoals admin, administrator en sysadmin. Als geen van deze gebruikers in de database voorkomt, kan de tester John ’of‘ x ’=’ x invoeren als strUserName en Smith ’of‘ x ’=’ x als strPassword. Dit zou ervoor zorgen dat de SQL-instructie er als volgt uitziet.

​

Aangezien de voorwaarde ‘x’ = ’x’ altijd waar is, zou de resultatenset bestaan ​​uit alle rijen in de tabel Gebruikers. De applicatie kan de tester toestaan ​​om in te loggen als de eerste gebruiker in de tabel Gebruikers.

Belangrijk: De tester moet de databasebeheerder of de ontwikkelaar vragen om de betreffende tabel te kopiëren voordat hij de volgende aanvallen probeert.

Als de tester John ’zou invoeren; DROP table users_details; ’- als strUserName en alles als strPassword, zou de SQL-instructie worden zoals hieronder.

​

Deze verklaring kan ervoor zorgen dat de tabel 'gebruikers_details' permanent uit de database wordt verwijderd.

Hoewel de bovenstaande voorbeelden betrekking hebben op het gebruik van de SQL-injectietechniek alleen de inlogpagina, moet de tester deze techniek testen op alle pagina's van de applicatie die gebruikersinvoer in tekstformaat accepteren, bijv. zoekpagina's, feedbackpagina's, etc.

SQL-injectie is mogelijk mogelijk in toepassingen die SSL gebruiken. Zelfs een firewall kan de toepassing mogelijk niet tegen deze techniek beschermen.

Ik heb geprobeerd deze aanvalstechniek in een eenvoudige vorm uit te leggen. Ik zou willen herhalen dat deze aanval alleen in een testomgeving moet worden getest en niet in de ontwikkelomgeving, productieomgeving of een andere omgeving.

verschil tussen unit- en integratietesten

In plaats van handmatig te testen of de applicatie kwetsbaar is voor SQL-aanvallen of niet, zou men een Web Kwetsbaarheidsscanner dat controleert op deze kwetsbaarheid.

Gerelateerd lezen: Beveiligingstesten van de webapplicatie ​Controleer dit voor meer informatie over verschillende webkwetsbaarheden.

Kwetsbare delen van deze aanval

Voordat het testproces begint, moet elke oprechte tester min of meer weten welke onderdelen het kwetsbaarst zijn voor mogelijke deze aanval.

Het is ook een goede gewoonte om te plannen welk gebied van het systeem precies moet worden getest en in welke volgorde. In mijn testcarrière heb ik geleerd dat het geen goed idee is om velden willekeurig te testen op SQL-aanvallen, omdat sommige velden kunnen worden gemist.

Aangezien deze aanval wordt uitgevoerd in de database, zijn alle onderdelen van het gegevensinvoersysteem, invoervelden en websitekoppelingen kwetsbaar.

Kwetsbare onderdelen zijn onder meer:

  • Login velden
  • Zoekvelden
  • Commentaar velden
  • Alle andere gegevensinvoer- en opslagvelden
  • Links naar websites

Het is belangrijk om op te merken dat het bij het testen tegen deze aanval niet voldoende is om slechts één of enkele velden te controleren. Het komt vrij vaak voor dat het ene veld beschermd is tegen SQL-injectie, maar het andere niet. Daarom is het belangrijk om niet te vergeten alle velden van de website te testen.

Automatisering van SQL-injectietests

Aangezien sommige geteste systemen of websites behoorlijk ingewikkeld kunnen zijn en gevoelige gegevens bevatten, kan handmatig testen erg moeilijk zijn en kost het ook veel tijd. Daarom kan het soms erg nuttig zijn om met speciale tools tegen deze aanval te testen.

Een van die SQL-injectietools is SOAP-gebruikersinterface ​Als we geautomatiseerde regressietests hebben op API-niveau, kunnen we met deze tool ook de controle tegen deze aanval omschakelen. In de SOAP UI-tool zijn er al codesjablonen voorbereid om tegen deze aanval te controleren. Die sjablonen kunnen ook worden aangevuld met uw eigen geschreven code.

Het is een redelijk betrouwbare tool.

Een test zou echter al op API-niveau moeten worden geautomatiseerd, wat niet zo eenvoudig is. Een andere mogelijke manier om automatisch te testen, is door verschillende browserplug-ins te gebruiken.

Opgemerkt moet worden dat zelfs als geautomatiseerde tools u tijd besparen, ze niet altijd als erg betrouwbaar worden beschouwd. Als we een banksysteem of een website met zeer gevoelige gegevens testen, wordt het ten zeerste aanbevolen om deze handmatig te testen. Waar u de exacte resultaten kunt zien en analyseren. Ook in dit geval kunnen we er zeker van zijn dat er niets is overgeslagen.

Vergelijking met andere aanvallen

SQL Injection kan worden beschouwd als een van de meest ernstige aanvallen, omdat het de database beïnvloedt en ernstige schade kan toebrengen aan uw gegevens en het hele systeem.

Het kan zeker meer ernstige gevolgen hebben dan een Javascript-injectie of HTML-injectie, aangezien beide aan de clientzijde worden uitgevoerd. Ter vergelijking: met deze aanval heeft u toegang tot de hele database.

Er moet worden vermeld dat u, om tegen deze aanval te testen, vrij goede kennis moet hebben van SQL-programmeertaal en in het algemeen moet weten hoe databasequery's werken. Ook tijdens het uitvoeren van deze injectie-aanval moet u voorzichtiger en oplettend zijn, aangezien elke onnauwkeurigheid kan worden overgelaten als SQL-kwetsbaarheden.

Gevolgtrekking

Ik hoop dat je een duidelijk idee had gekregen van wat een SQL-injectie is en hoe we deze aanvallen moeten voorkomen.

Het wordt echter ten zeerste aanbevolen om elke keer dat een systeem of website met een database wordt getest, tegen dit type aanval te testen. Elke linkse database of kwetsbaarheden in het systeem kunnen de reputatie van een bedrijf en veel middelen kosten om het hele systeem te herstellen.

Omdat testen tegen deze injectie helpt om het meeste te vinden belangrijke beveiligingsproblemen , is het ook aan te raden om te investeren in uw kennis en testtools.

Als beveiligingstests zijn gepland, moet het testen tegen SQL-injectie worden gepland als een van de eerste testonderdelen.

Bent u een typische SQL-injectie tegengekomen? Deel gerust uw ervaringen in de commentaren hieronder.

Aanbevolen literatuur

^