Skip to main content

Testen op beveiligingslekken in SQL-injecties

Dit is BIZAR! Beveiligingslek bij Defensie: 'inbreken' bij de Anti Terreur Eenheid van Nederland (Juni- 2026)

Dit is BIZAR! Beveiligingslek bij Defensie: 'inbreken' bij de Anti Terreur Eenheid van Nederland (Juni- 2026)
Anonim

SQL-injectieaanvallen vormen enorme risico's voor webtoepassingen die afhankelijk zijn van een databasebackend voor het genereren van dynamische inhoud. Bij dit type aanvallen manipuleren hackers een webtoepassing in een poging om hun eigen SQL-opdrachten in te voegen in die die door de database worden uitgegeven. Zie bijvoorbeeld het artikel SQL Injection Attacks on Databases. In dit artikel bekijken we verschillende manieren waarop u uw webtoepassingen kunt testen om te bepalen of ze kwetsbaar zijn voor SQL-injectie-aanvallen.

Geautomatiseerde SQL-injectiescanning

Een mogelijkheid is het gebruik van een geautomatiseerde kwetsbaarheidscanner voor webapplicaties, zoals WebInspect van HP, AppScan van IBM of de Hagelstorm van Cenzic. Deze tools bieden allemaal eenvoudige, geautomatiseerde manieren om uw webtoepassingen te analyseren op mogelijke kwetsbaarheden in SQL-injecties. Ze zijn echter vrij duur en lopen tot $ 25.000 per stoel.

Handmatige SQL-injectietests

Wat is een slechte applicatie-ontwikkelaar te doen? U kunt enkele basistests uitvoeren om uw webtoepassingen voor SQL Injection-kwetsbaarheden te evalueren met behulp van niets meer dan een webbrowser. Ten eerste een waarschuwing: de tests die we beschrijven, zoeken alleen naar fundamentele SQL Injection-fouten. Ze zullen geen geavanceerde technieken detecteren en zijn enigszins vervelend om te gebruiken. Als je het kunt betalen, ga dan met een geautomatiseerde scanner. Als u dat prijskaartje echter niet aankan, is handmatig testen een geweldige eerste stap.De eenvoudigste manier om te evalueren of een toepassing kwetsbaar is, is door te experimenteren met onschadelijke injectieaanvallen die uw database niet daadwerkelijk schade toebrengen als ze slagen, maar u het bewijs zullen leveren dat u een probleem moet oplossen. Stel dat u een eenvoudige webtoepassing hebt die een persoon in een database opzoekt en als gevolg hiervan contactgegevens verstrekt. Die pagina gebruikt mogelijk de volgende URL-indeling:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

We kunnen aannemen dat deze pagina een database-lookup uitvoert, met behulp van een zoekopdracht die lijkt op het volgende:

SELECT telefoon

VAN map

WHERE lastname = 'chapple' en firstname = 'mike'

Laten we hier een beetje mee experimenteren. Met onze bovenstaande aanname kunnen we een eenvoudige wijziging aanbrengen in de URL die test op SQL-injectie-aanvallen:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1

Als de webtoepassing niet goed is beveiligd tegen SQL-injectie, koppelt deze eenvoudigweg deze nep-voornaam in de SQL-instructie die wordt uitgevoerd tegen de database, wat resulteert in:

SELECT telefoon

VAN map

WHERE lastname = 'chapple' en firstname = 'mike'

EN (selecteer aantal (*) uit nep)> 0

OF '1' = '1'

U zult merken dat de syntaxis hierboven een beetje anders is dan die in de originele URL. We hebben de vrijheid genomen om de URL-gecodeerde variabele te converteren voor hun ASCII-equivalenten om het gemakkelijker te maken het voorbeeld te volgen. % 3d is bijvoorbeeld de URL-codering voor het teken '='. We hebben ook enkele regeleinden toegevoegd voor vergelijkbare doeleinden.

Evaluatie van de resultaten

De test wordt uitgevoerd wanneer u de webpagina probeert te laden met de bovenstaande URL. Als de webtoepassing zich goed gedraagt, verwijdert deze de enkele aanhalingstekens uit de invoer voordat de query aan de database wordt doorgegeven. Dit zal eenvoudig resulteren in een rare lookup voor iemand met een voornaam die een hoop SQL bevat. Er wordt een foutmelding van de toepassing weergegeven die lijkt op de onderstaande:

Fout: Geen gebruiker gevonden met naam mike + AND + (selecteer + tel (*) + van + nep) +% 3e0 + OF + 1% 3d1

Chapple!

Aan de andere kant, als de toepassing kwetsbaar is voor SQL-injectie, zal deze de instructie direct doorgeven aan de database, wat resulteert in een van de twee mogelijkheden. Ten eerste, als uw server gedetailleerde foutmeldingen heeft ingeschakeld (wat u niet zou moeten doen), ziet u zoiets als dit:

Microsoft OLE DB Provider voor ODBC-stuurprogramma's fout '80040e37'

Microsoft ODBC SQL Server Driver SQL Server Ongeldige objectnaam 'nep'.

/directory.asp, regel 13

Aan de andere kant, als uw webserver geen gedetailleerde foutmeldingen weergeeft, krijgt u een algemenere fout, zoals:

Interne Server FoutDe server heeft een interne fout of onjuiste configuratie aangetroffen en kan uw verzoek niet voltooien.

Neem contact op met de serverbeheerder om te informeren over het tijdstip waarop de fout is opgetreden en over alles wat u mogelijk heeft gedaan dat de fout kan hebben veroorzaakt.

Meer informatie over deze fout is mogelijk beschikbaar in het serverfoutlogboek.

Als u een van de bovenstaande twee fouten ontvangt, is uw toepassing kwetsbaar voor een aanval met SQL-injecties. Enkele stappen die u kunt nemen om uw toepassingen te beschermen tegen SQL Injection-aanvallen zijn onder andere:

  • Implementeer parametercontrole op alle applicaties. Als u bijvoorbeeld iemand vraagt ​​om een ​​klantnummer in te voeren, moet u ervoor zorgen dat de invoer numeriek is voordat u de query uitvoert.
  • Beperk de machtigingen van het account dat SQL-query's uitvoert. De regel van het minste privilege is van toepassing. Als het account dat wordt gebruikt om de query uit te voeren geen toestemming heeft om het uit te voeren, zal het niet lukken.
  • Gebruik opgeslagen procedures (of vergelijkbare technieken) om te voorkomen dat gebruikers direct interactie hebben met SQL-code.