Onderwerp: 5 tools om je site te testen op SQLi-zwakheden

Bouwers en eigenaren van websites kunnen hun producten testen op de kwetsbaarheid van bijvoorbeeld een SQL-injectie. Daar zijn verschillende tools voor. We nemen er een paar onder de loep.

Websites kunnen onbedoeld kwetsbaar zijn voor aanvallen, waarbij de privacygegevens van klanten of burgers plotseling openbaar kunnen worden. Met SQL-injectie wordt kwaadaardige code ingebracht via de portal. De server voert elke binnen de syntax passende query uit, waardoor de server voor de gek wordt gehouden en gemanipuleerd.

Om dat te voorkomen moeten websitebouwers en -eigenaren geregeld hun websites controleren, zegt ook Rene Bladder van ict-adviesbureau Bladder op Management Weblog, naar aanleiding van het eerste lek dat Webwereld zaterdag publiceerde. Het controleren van de eigen website kan onder meer met de onderstaande tools.

1. LiLith

LiLith is een programmaatje geschreven in Perl door Michael Hendrickx. Hij wil ermee de beveiliging van webapplicaties verbeteren, zo schrijft hij op zijn site. "Dus alsjeblieft, misbruik het niet."

Volgens de maker is LiLith niet te vergelijken met zo geheten CGI-scanners. Lilith surft naar een website en gaat alle links na die het kan vinden. Op elke mogelijk invoerveld, zoals tekstboxjes, probeert het programma karakters te injecteren die een speciale betekenis hebben voor de onderliggende technologie, zoals sql.

Op zijn site geeft Hendrickx een uitgebreide handleiding, of meer een stappenplan voor het gebruik. Zo is het mogelijk een snelle "quick and dirty" scan te doen waarbij je niet echt veel te weten komt over de structuur van de site, behalve dat de site gevoelig is voor een sql-injectie. Een nadere scan met wat meer functies aangezet, vertelt dan ook meer over het wat waar en hoe van de kwetsbaarheden.

2. sqlmap
Sqlmap is een open source tool die bedoeld is voor testen van sites en hun achterliggende database. Het detecteert en exploiteert kwetsbaarheden en kan databaseservers volledig overnemen. De tool is enorm uitgebreid en de mogelijkheden om de reikwijdte van een kwetsbaarheid te onderzoeken zijn legio.

De tool biedt ondersteuning voor alle soorten SQL-databases, zoals MySQL, Oracle, PostgreSQL, MS SQL Server, Sybase en SAP MaxDB. Er is een uitgebreide zoekfunctie aanwezig om naar specifieke databasenamen te zoeken of specifieke tabellen of kolommen. Dat is handig als er wordt gezocht naar namen in combinatie met wachtwoorden. De tool is te vinden bij het bekende SourceForge.

3. Sqlninja
Een soortgelijke tool als sqlmap is sqlninja, eveneens te vinden bij SourceForge. De tool is alleen te gebruiken op Microsoft SQL Server. Het gebruik van Sqlninja kan leiden tot een volledige overname van de GUI op de database.

Het programma is geschreven in Perl, is open source en vrijgegeven onder de GPLv3. De gebruiker moet Linux, FreeBSD of Mac OS X als platform hebben, op Microsoft doet het programma het niet. Op de website van SourceForge is een uitgebreide handleiding te vinden, maar die komt ook mee bij het downloaden. Een waarschuwing van de maker: het opzetten en configureren van het programma is niet eenvoudig.

4. SQL Power Injector
SQL Power Injector is geschreven in .NET en met het programma kunnen kwetsbaarheden worden gevonden in MS SQL Server, Oracle, MySQL, Sybase en DB2. Maar de maker zegt dat de tool om kan gaan met elke DBMS.

De queries die het draait op de databases kunnen volledig worden geautomatiseerd. De resultaten worden getoond in een geïntegreerde browser. Er zit tevens een Firefox plugin bij. Voor beginners is er een handleiding met de eerste basisprincipes. Trucjes zijn te vinden in de Q&A. Volgens de maker is deze tool vooral handig als de onderzoeker gericht zoekt en geen grote datadump vraagt.

5. Havij
De laatste in deze korte opsomming van testtools voor sql-kwetsbaarheden is Havij. Een mooie walk-trough tutorial is te vinden op hungry-hackers.com. Daar staat tevens een video-tutorial. Volgens de makers onderscheidt Havij zich van andere tools door de methode die wordt gebruikt. Daarmee zou een succes in 95 procent van de gevallen gegarandeerd zijn. Door de geautomatiseerde settings is de tool ook voor amateurs makkelijk te gebruiken.

Bron: http://webwereld.nl/tips-en-tools/10...zwakheden.html

Havij is algemeen bekend volgens mij !en ook nog eens makkelijk om mee te werken

En vergeet niet.
"fouten verifieer je niet met een "; DROP DATABASE" commando. " Arnoud Engelfriet (Security.nl)

Het gevolg van een SQL injectie kan je beperken door bepaalde rechten die niet nodig zijn niet toe te staan (principle of least privilege).
Gebruik minimaal één gebruiker voor beheer (met een sterk wachtwoord) en een aparte gebruiker voor bepaalde acties (zonder DROP privs, want die heb je vrijwel nooit nodig, waaronder DROP DATABASE).

Wetende dat webwereld.nl een redelijk bron van informatie is voor de gem. beheerder ('echte' beheerders weten vaak wel beter), lijkt het me op zijn mist op zijn plaats om in dat artikel ook melding te maken van trojans in de besproken programmatuur. (bv. Havij)

Ik vraag me af hoeveel extra besmettingen dit artikel oplevert...

Oorspronkelijk geplaatst door systemdeveloper

('echte' beheerders weten vaak wel beter)

... en zou een "echte" beheerder dan misschien ook wat concreter kunnen zijn, zodat de gemiddelde beheerder zijn/haar sites kan testen zonder de boel meteen te besmetten. Alvast mijn dank.

Oorspronkelijk geplaatst door onager

... en zou een "echte" beheerder dan misschien ook wat concreter kunnen zijn, zodat de gemiddelde beheerder zijn/haar sites kan testen zonder de boel meteen te besmetten. Alvast mijn dank.

Wat ik bedoel is dat de beheerder, die al geleerd heeft dat ie niet op elk linkje moet klikken, de toolstjes van dit soort sites vast grondig scanned alvorens het uberhaupt te openen. Maar niet elke rookie doet dat als ie even zijn server wil gaan testen.
Webwereld mag daar imho wel even wat van vermelden. Het is een popie site tenslotte.

Je eigen sites testen moet je doen op een manier die je zelf begrijpt met een tool die je zelf begrijpt.
Elke tool van derden met als doel gaten in je beveiliging te testen, moet je met de meeste achterdocht benaderen uiteraard.
Hierbij zijn windows executables natuurlijk een groter risico dan plaintext 'scans' die je tenminste zelf nog kunt lezen.

Persoonlijk sta ik sceptisch tegenover dit soort tooltjes. Even los van of ze een trojan bevatten of niet, geven ze een vals gevoel van veiligheid voor beginnende programmeurs. Doordat zo'n tool geen exploit heeft gevonden met een bende geautomatiseerde brute force tests houdt zeker niet in dat een webapplicatie veilig is.

Stel bijvoorbeeld voor dat je ergens diep verstopt in een profielpagina de ruimte hebt om een straal van een x aantal km op te geven waarbinnen je standaard wilt zoeken, maar alleen wanneer je een premium profiel hebt en er op dat moment een zonsverduistering is. Bij wijze van spreken. Bij het opslaan wordt de INSERT netjes verzorgt en heb je hierbij geen SQL injection, maar vervolgens wordt bij een zoekpagina ergens totaal anders in de website deze straal gebruikt zonder dat deze netjes wordt ge-escaped. Je maakt mij niet wijs dat zo'n tool dat soort dingen ontdekt en/of de relatie tussen dit veld en de exception aan het andere eind kan leggen.

Op het moment dat je zo'n tool bekend moet maken met de structuur van een website, kun je die tijd beter investeren in het ontwikkelen/gebruiken van een degelijke DBAL en het schrijven van unit tests om dit soort dingen (en andere problemen) te ontdekken. Zorg dat je een andere competente developer de boel laat testen (nooit zelf testen) en je bereikt veel meer. Als je altijd programmeert met "never trust the user" in je achterhoofd en zorgt dat je gestrucureerd werkt heb je die tooltjes echt niet nodig. Laat dan een professionele audit doen.

Daarbij ook wat Rollerscapes al aangeeft: nooit meer rechten geven dan noodzakelijk. Overigens vind ik een "UPDATE users SET user_level = 'root'" pijnlijker dan een DROP ..., maar dat terzijde

Havij wordt inderdaad gezien door de virusscanner als een hacktool.

; DROP DATABASE en dergelijke werkt al lang niet meer (via PHP) aangezien er maar 1 query tegelijkertijd wordt uitgevoerd en dus alles na de ; niet wordt uigevoerd.

Oorspronkelijk geplaatst door Boyke

; DROP DATABASE en dergelijke werkt al lang niet meer (via PHP) aangezien er maar 1 query tegelijkertijd wordt uitgevoerd en dus alles na de ; niet wordt uigevoerd.

Met als uitzondering de MySQL driver voor PDO, die staat dat wel gewoon toe.

Oorspronkelijk geplaatst door Boyke

Havij wordt inderdaad gezien door de virusscanner als een hacktool.

; DROP DATABASE en dergelijke werkt al lang niet meer (via PHP) aangezien er maar 1 query tegelijkertijd wordt uitgevoerd en dus alles na de ; niet wordt uigevoerd.

Niet helemaal waar er zijn functies waarmee dit wel degelijk kan!
pg_query() accepteert standaard meerdere statements.

Vic was mij voor.

mysql_query() accepteert inderdaad maar één statement, PDO is iets van de laatste jaren, en de meeste gebruikers zullen denk ik wel beter op de hoogte zijn van veiligheid dan vroeger.

Vroeger was in PHP magic-quotes heel populair, gewoon aanzetten en geen problemen met quotes.
Maar daar zat hem ook gelijk het probleem, mensen werd vrijwel nooit verteld hoe het wel moest.

Overigens is één statement uitvoeren is geen garantie dat ze geen schade aan kunnen richten, een kennis heeft een keer een site plat gekregen door herhaaldelijk MYSQL_BENCHMARK() uit te voeren!

Interessant deze discussie.
Als aanvulling op m'n topic kwam ik deze tegen: http://phpsec.org/projects/ Ik heb er geen ervaring mee, misschien dat anderen er iets van weten?

Als je het heel veilig wilt doen moet je eigenlijk je mysql ACID code in mysql stored procedures onderbrengen.
SQL injectie is dan gewoon niet meer mogelijk. (althans het succesvol uitvoeren ervan).

Dat is duurder en lastiger, performed onder mysql tot 25% minder en is ongetwijfeld niet voor elke php scripter weggelegd, aangezien het een andere tak van sport is dan alleen wat php/sql kloppen.

Maar, als je het goed aanpakt kun je dan een systeem hebben waarbij niemand van je tabellen kan lezen of erheen schrijven, zelfs al heeft ie de login van een mysql user.
Daarnaast maakt het verder ook (technisch) geen fluit uit of je je data nog escaped voordat je het aan de SP doorgeeft, aangezien een SP de variabelen niet gebruikt om de SQL op te bouwen, maar ALLEEN als parameter. (een beetje zoals pdo prepare dus).
SP's combineren met database triggers is nog een stapje verder. Daarmee kun je je database niet alleen rocksolid dichtslaan, je kunt ook consistentie garanderen (van pre-checks om records te kunnen muteren tot het bijwerken van tellertjes of het automatisch loggen van acties).

Dat is voor mij de normaalste zaak van de wereld

Overigens is het pas ACID als je een storage engine gebruikt die Transcaties ondersteund.
MyISAM ondersteund geen tracties.

http://wikimedia.org/wikipedia/en/wiki/ACID

Oorspronkelijk geplaatst door Rollerscapes

Dat is voor mij de normaalste zaak van de wereld

Overigens is het pas ACID als je een storage engine gebruikt die Transcaties ondersteund.
MyISAM ondersteund geen tracties.

http://wikimedia.org/wikipedia/en/wiki/ACID

Hehe, sry, ik bedoelde nu even de Add, Change, Insert, Delete 'code' aan de php kant.
Niet de transactie gerelateerde def. omdat dit meer over beveiliging tegen sqlinjecties ging en niet specifiek over transacties.
Maar uiteraard moet ook je db een beetje meewerken (en vooral het bedrijf dat je betaald voor de ontwikkeling)

Goed dat het voor jou gesneden koek is... maar nu zoek eens op bv. POST of GET op het gem. webmaster forum... Moet je eens zien wat er dan naar boven komt aan code die nog niet aan de basics voldoet.

Ik doelde met name op mysql_query die je stiekem toch nog erg vaak tegenkomt.