Donnerstag, 7. Juni 2012


Topthema

Donnerstag, 14. August 2008 | Topthema

About Security #168: Schwachstellensuche: SQL Injection statt Zahlen

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/044661)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

SQL-Injection ist auch �ber numerische Parameter m�glich. Denn nur, weil ein Feld f�r z.B. eine Kundennummer vorgesehen ist, hei�t das noch lange nicht, dass ein Angreifer dort nicht einen SQL-Befehl eingeben kann. Und auch eine Beschr�nkung der L�nge des Eingabefelds auf z.B. f�nf Zeichen ist keine Garantie daf�r, dass ein Angreifer nicht einen l�ngeren Parameter an den Server sendet. Dazu kann er (wie in About Security #149 bei der Manipulation von Zustandsinformationen beschrieben) z.B. das Formular lokal speichern und �ndern, den Parameter in einem Proxy 'on the fly' manipulieren oder seine Daten unter Umgehung des Clients direkt an die Webanwendung senden.

Numerische Parameter werden manchmal als Strings, d.h. eingeschlossen in '-Zeichen, an die Datenbank �bergeben. Daher m�ssen auch die in About Security #167 f�r Strings beschriebenen Tests durchgef�hrt werden. Meistens werden sie aber direkt als numerische Werte an die Datenbank �bergeben und daher nicht in '-Zeichen eingeschlossen. Ergibt sich bei den Tests aus About Security #167 kein Hinweis auf eine Schwachstelle, sind weitere Tests notwendig.

Tests f�r numerische Parameter

Die folgende SQL-Abfrage k�nnte verwendet werden, um einen Nachrichtentext anhand einer numerischen ID auszuw�hlen:

SELECT Text FROM Nachrichten WHERE ID = $id

Als erster Test wird ein mathematischer Ausdruck �bergeben, der �quivalent zu einem g�ltigen numerischen Wert ist. Ist ein Originalwert z.B. 5, k�nnte z.B. 2+3 oder 6-1 als Wert f�r $id eingegeben werden:

SELECT Text FROM Nachrichten WHERE ID = 2+3

Liefert die Webanwendung f�r den Ausdruck dasselbe Ergebnis wie bei Eingabe des Originalwerts, kann sie f�r SQL-Injection anf�llig sein.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Dieser Test ist immer dann zuverl�ssig, wenn eine �nderung des betroffenen Parameters eine sichtbare Auswirkung auf die Ausgabe der Webanwendung hat. Ist der getestete Parameter wie im obigen Beispiel eine numerische ID, die den auszugebenden Text bestimmt, ist eine identische Ausgabe f�r 5 und 2+3 ein ziemlich sicheres Zeichen daf�r, dass SQL-Injection m�glich ist. Kann f�r den betroffenen Parameter aber ein beliebiger Wert eingegeben werden, ohne dass sich die Ausgabe �ndert, liefert der Test keine zuverl�ssige Aussage.

Ist der erste Test erfolgreich, kann als n�chstes ein Test mit einem komplizierteren SQL-Ausdruck durchgef�hrt werden. Gut geeignet ist daf�r der Befehl ASCII(), der den numerischen ASCII-Wert des �bergebenen Zeichens zur�ckliefert. Der ASCII-Wert von A ist 65, der folgende Ausdruck ist also in SQL �quivalent zu 5:

70-ASCII('A')

Dieser Test funktioniert nicht, wenn '-Zeichen von der Webanwendung ausgefiltert werden. In diesem Fall kann ausgenutzt werden, dass die Datenbank bei Bedarf numerische Daten automatisch in Strings umwandelt. Der ASCII-Wert des Zeichens 1 ist 49, der folgende Ausdruck ist also in der SQL-Abfrage �quivalent zu 5:

54-ASCII(1)

Ist einer der letzten beiden Tests erfolgreich, kann beliebiger SQL-Code eingeschleust werden, evtl. eingeschr�nkt durch Filterfunktionen der Webanwendung, die bestimmte Zeichen wie z.B. das '-Zeichen ausfiltern oder maskieren.

Die in About Security #167 und dieser Folge beschriebenen Tests reichen aus, um einen Gro�teil aller SQL-Injection-Schwachstellen zu finden. Machmal sind weiterf�hrende Test wie z.B. Wartezeiten (time delays) notwendig, um eine Schwachstelle nachzuweisen. Auf diese F�lle wird sp�ter noch eingegangen.

Sonderzeichen kodieren
About Security: Die komplette Serie

Einige Zeichen haben in HTTP-Requests eine besondere Bedeutung und k�nnen nicht direkt als Teil der Eingabe f�r Parameter verwendet werden. Sollen sie Bestandteil einer SQL-Injection sein, m�ssen sie URL-kodiert werden. Das betrifft die folgenden Zeichen:

  • & und = verbinden Parameternamen und -werte in URL und POST-Daten. Sie k�nnen als %26 und %3d kodiert werden.
  • Leerzeichen sind in Query-Strings verboten und beenden den gesamten String. Sie k�nnen wahlweise als + oder %20 kodiert werden.
  • Da + ein Leerzeichen kodiert, kann es nicht als eigentliches + verwendet werden. Soll das Zeichen + �bergeben werden, muss es als %2b kodiert werden. Das obige 2+3 muss also als 2%2b3 eingegeben werden.
  • Das ; dient als Trennzeichen f�r Cookie-Felder und kann als %3b kodiert werden.

Werden die Zeichen nicht korrekt kodiert, ist die sich ergebende SQL-Abfrage nicht g�ltig oder erf�llt zumindest nicht die geplante Funktion.

SQL-Injection in verschiedene Statements

F�r SQL-Injection-Beispiele wird meistens das SELECT-Statement verwendet, aber entsprechende Schwachstellen k�nnen auch in Verbindung mit anderen Statements existieren - und nat�rlich auch ausgenutzt werden. Mit was f�r einem Statement ein anf�lliger Parameter verwendet wird, kann ein Angreifer ohne Zugriff auf den Quelltext der Webanwendung nicht mit Sicherheit wissen, aber meist aus den jeweiligen Umst�nden (z.B. Anzeigen/Eintragen/�ndern von Daten) sehr gut raten.

Wie SQL-Injection in Verbindung mit verschiedenen Statements ausgenutzt werden kann, wird in der n�chsten Folge beschrieben.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

Kommentare

Folgende Links könnten Sie auch interessieren