SQL-Injection-Schwachstellen haben in manchen Fällen, unabhängig vom z.B. in About Security #166 beschriebenen Abfragen der gesamten Datenbank, eine viel direktere und unter Umständen auch schwerwiegendere Auswirkung.

Ungeschickte Authentifizierung

Verwendet die Webanwendung ein Formular für die Anmeldung, das Benutzernamen und Passwort abfragt, könnte folgende SQL-Abfrage verwendet werden, um die Gültigkeit von Benutzernamen und Passwort zu prüfen:

SELECT * FROM Benutzer WHERE Benutzername = '' AND Passwort = ''

Jede Zeile der Tabelle mit den Benutzerdaten wird daraufhin überprüft, ob darin Benutzername und Passwort mit den eingegebenen Werten übereinstimmen. Im Erfolgsfall werden die Benutzerdaten zurückgeliefert und von der Webanwendung eine authentifizierte Session erzeugt: Der Benutzer ist angemeldet.

Ein Angreifer kann diese SQL-Abfrage ausnutzen, um sich als ein beliebiger Benutzer anzumelden, wenn er einen existierenden Benutzernamen kennt. Kennt er z.B. den Benutzernamen alice, würde er als Benutzernamen
alice'--
und als Passwort z.B.
unwichtig
eingeben, und folgende SQL-Abfrage würde erzeugt:

SELECT * FROM Benutzer WHERE Benutzername = 'alice'--' AND Passwort = 'unwichtig'

Durch die -- wird alles danach als Kommentar betrachtet und ignoriert, die Abfrage entspricht also

SELECT * FROM Benutzer WHERE Benutzername = 'alice'

Die Prüfung des Passworts wurde damit ausgehebelt (besser gesagt: auskommentiert). Wenn der Benutzername alice existiert, ist der Angreifer danach als alice angemeldet. Das funktioniert natürlich auch mit dem Administrator der Webanwendung: Kennt der Angreifer dessen Benutzernamen, kann er sich als Administrator anmelden. Und da für Administratoren sehr häufig ein Benutzername wie z.B. admin verwendet wird, ist das dann nur noch ein Kinderspiel.

Aber auch wenn der Angreifer keinen Benutzernamen kennt, kann er die Authentifizierung umgehen. Mit dem Benutzernamen
' OR 1=1--
und dem Passwort
unwichtig
ergibt sich die SQL-Abfrage

SELECT * FROM Benutzer WHERE Benutzername = '' OR 1=1--' AND Passwort = 'unwichtig'

Die entspricht

SELECT * FROM Benutzer WHERE Benutzername = '' OR 1=1

und liefert die Daten aller Benutzer. Viele Webanwendungen reagieren auf diesen unerwarteten Fall damit, dass der erste zurückgelieferte Benutzer angemeldet wird. Und in den meisten Fällen ist der erste angelegte Benutzer einer mit Administrator-Rechten...

SQL-Injection-Schwachstellen finden

Kommen wir zur entscheidenden Frage: Wie findet man diese Schwachstellen? Zuerst einmal muss man alle Parameter ermitteln, die für eine SQL-Abfrage verwendet werden. Im einfachsten Fall reicht es, für einen Parameter einen unerwarteten Wert einzugeben, um eine SQL-Fehlermeldung zu erhalten. Davon ausgehend, kann dieser Parameter dann genauer untersucht werden. In schwierigen Fällen müssen mehrere Parameter mit passenden Werten gefüllt oder besondere Umstände berücksichtigt werden, um eine mögliche Schwachstelle zu finden. Manchmal stößt man auch auf Fehlermeldungen, die zwar nach einer möglichen SQL-Injection-Schwachstelle aussehen, sich aber tatsächlich nicht für einen Angriff ausnutzen lassen.

Eine Möglichkeit, die Verwendung eines Parameters in einer SQL-Abfrage zu prüfen, besteht in der Eingabe des SQL-Wildcard-Zeichens %. Wird das z.B. als Parameter einer Suchfunktion verwendet, gibt es oft eine sehr große Anzahl Fundstellen: Der Parameter wurde für eine Datenbankabfrage verwendet. Das bedeutet noch lange nicht, dass über diesen Parameter SQL-Injection möglich ist. Es ist nur ein Hinweis darauf, dass dieser Parameter näher untersucht werden muss.

Wie bei der Suche nach XSS-Schwachstellen gilt wieder, dass alle mehrstufigen Aktionen vollständig durchlaufen werden müssen. Oft werden die Daten erst im letzten Schritt an die Datenbank gesendet, sodass ein im ersten Schritt präparierter Parameter gar nicht bis zur Datenbank gelangt, wenn die Aktion nicht vollständig durchlaufen und korrekt abgeschlossen wurde. Der Ansatz "Testmuster eingeben, Ergebnis auswerten" schlägt dann wie im Fall von XSS-Schwachstellen fehl.

Strings prüfen

Vom Benutzer gelieferte Strings müssen in einer SQL-Abfrage in '-Zeichen eingeschlossen werden. Für einen Angriff muss also aus diesen '-Zeichen ausgebrochen werden. Als erster Test kann ein einzelnes '-Zeichen eingegeben werden. Ergibt das eine unerwartete Ausgabe? Erzeugt es eine Fehlermeldung? Fehlermeldungen liefern oft interessante Hinweise für das weitere Vorgehen und können in der Dokumentation des verwendeten Datenbanksystems nachgeschlagen werden.

Gibt es bei einem '-Zeichen eine Fehlermeldung, wird das gleiche mit zwei '-Zeichen ausprobiert. '' wird von der Datenbank als maskiertes '-Zeichen interpretiert, sodass es als Bestandteil des Strings und nicht als dessen Ende aufgefasst wird. Verschwindet die Fehlermeldung, ist sehr wahrscheinlich SQL-Injection möglich.

Als nächster Versuch wird über den String-Concatenator der Datenbank ein String gebildet, der äquivalent zu einer korrekten Eingabe ist. Für MySQL ist z.B.
' 'richtig
äquivalent zu
richtig
Ist die Ausgabe für beide Werte identisch, ist SQL-Injection möglich.

In der nächsten Folge geht die Suche nach SQL-Injection-Schwachstellen mit der Untersuchung numerischer Parameter weiter.

Carsten Eilers