SQL Injections… die Grundlage alles Bösen denken viele…

Nein, dass stimmt so nicht!

Dieses Problem war schon immer vorhanden und liegt oftmals im blanken Unwissen der Programmierer und noch häufiger in der Unbrauchbarkeit einer Programmiersprache begründet.

Unbrauchbarkeit?

Ja! Programmiersprachen mit Typsicherheit haben hier Unmengen an Vorteilen. Viele SQL-Injections gehen nur, wenn man aus dem SQL String ausbrechen kann.

Sprachen wie PHP und Perl sind hier aufgrund ihres Aufbaus schon per Definition ein Sicherheitsrisiko.

Zwar hat man bei PHP mit PDO und den Prepared Statements und Stored Procedures einen großen Schritt in Richtung höherer Sicherheit gemacht, aber dies stellt in meinen Augen auch nur eine Hilfslösung da.

Es gibt immer noch genügend SQL Injections, welche Besonderheiten des jeweiligen Datenbankservers ausnutzen und nicht zwingend auf das Ausbrechen aus dem SQL String angewiesen sind.

Ich will hier aus verschiedenen Gründen keine Beispiele bringen, aber es gibt sie.

Denkt einfach an Dinge wie automatische Zeichenumwandlung, nicht dokumentierte Befehle und Funktionen aus Datenbankfremden Treiberschichten, welche von dieser angesprochen werden können.

All data are evil !

Grundsätzlich kann man nur empfehlen bei wichtigen Dingen auf Typsichere Sprachen wie JAVA oder .NET auszuweichen.

PHP und Co. mögen ja für Hobbyprogrammierer langen, aber bei kommerziellen Projekten oder Projekten mit Fremddaten (z.B. Browsergames) kann man jedem nur empfehlen den sicheren Weg zu gehen.

Im Moment sind schon genügend Daten von uns allen unterwegs und außer Kontrolle. Man muß nicht noch selbst dazu beitragen diese Datenmenge zu vergrößern.

Mehr über das Thema SQL Injections kann man unter den folgenden Links nachlesen:

• Advancded SQL Injection
• (more) Advanced SQL Injection
• OWASP – SQL Injection

Auch wer mögliche Fehlermeldungen unterdrückt und eine Standardisierte Fehlerseite anzeigt, ist nicht sicher gegen SQL Injections. Man macht es dem Angreifer nur schwerer, aber nicht unmöglich.

Es gibt genügend Möglichkeiten um anhand des Verhaltens der verschiedenen Anzeigeseiten den groben internen Aufbau und sogar die Datentypen der einzelnen Spalten ermitteln zu können.

Glaube nicht, weil du es nicht kannst, dass andere es auch nicht können!

Es gibt genügend Scriptkiddis, welche sich solcher Tools bedienen:

Blind SQL Injection Brute Forcer

Und wem das nicht langt…

Top 15 free sql injection scanners

Ok… Scanner… aber wo ein Wille ist, da ist auch ein Weg daraus mehr zu machen.

Klar ist das Tool primär auf Datenübergabe per URL ausgelegt, aber ein halbwegs fähiger Programmierer hat das in wenigen Minuten von URL/GET auf POST geändert und an das Zielsystem angepaßt.

Ach und weil man es nicht oft genug sagen kann:

All data are evil !

Webauditing ist eine ziemliche aufwändige Tätigkeit.

Um so mehr freut man sich über Hilfsmittel, welche standardisierbare Handgriffe übernehmen können.

WA3F ist so eines. Man bekommt es hier:

W3AF

W3AF selbst ist eine Art Metasploit für Webbasierende Anwendungen und prüft Dinge wie SQL Injections, XSS und einige andere Dinge ab.

Hier ein kleines Beispielvideo direkt vom Hersteller:

OS commanding detection and exploit (pyGTK user interface) – Video

Sieht fein aus und dummerweise funktioniert es auch so einfach

Logischerweise sollte man schon wissen was welches Modul macht und sowas auch schon selbst gemacht haben.

Sich blind auf Tools zu verlassen kann ziemlich schnell ins Augen gehen. Es wäre nicht der erste Server, der Datenverlust hat oder offline geht, weil jemand ohne Ahnung rumgefummelt hat.