entwickler.com

SQL-Injection ist in Verbindung mit vielen Statements möglich, wenn auch für Beispiele meistens das SELECT-Statement verwendet wird. Wie ein Angreifer SQL-Injection in verschiedene Statements ausnutzen kann, erfahren Sie ab dieser Folge.

In 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 erraten: Bei der Auswahl von Daten wird es sich im Allgemeinen um ein SELECT-Statement handeln, beim Eintragen von Daten um ein INSERT-Statement, beim Ändern von Daten um ein UPDATE-Statement und beim Löschen von Daten um ein DELETE-Statement.

Der Klassiker: SELECT

SELECT-Statements dienen zur Abfrage von Daten aus der Datenbank, meist nach dem Muster

SELECT spalte FROM tabelle WHERE irgendwas

Der vom Angreifer manipulierbare Parameter wird meist in der WHERE-Klausel verwendet. Da die am Ende des Statements steht, kann ein Angreifer dort beliebigen Code einfügen und den folgenden Rest auskommentieren, ohne die Syntax des gesamten Statements zu zerstören.

Einige Beispiele wurden bereits in About Security #11 und #166 vorgestellt. Gelegentlich gibt es SQL-Injection-Schwachstellen auch in anderen Teilen der SELECT-Abfrage, z.B. in einer 'ORDER BY'-Klausel oder selten auch als Tabellen- oder Spaltenname.

Einfügen leichtgemacht: INSERT

INSERT-Statements dienen zum Eintragen einer neuen Zeile in eine Tabelle, z.B. nach dem Muster

INSERT INTO benutzer (name, passwort, ID,  admin)
              VALUES ('jo', 'geheim', 123, 'n')

Sind die Parameter für name oder passwort für SQL-Injection anfällig, kann der Angreifer beliebige Daten in die Tabelle eintragen, einschließlich eigener Werte für ID und admin. Er muss nur darauf achten, dass die korrekte Anzahl Werte mit den richtigen Datentypen übergeben werden. Erfolgt der Angriff über den Parameter für name, könnte er Folgendes eingeben:

rein', 'nix', 9999, 'j')--

Das würde zu folgendem INSERT-Statement führen:

INSERT INTO benutzer (name,   passwort, ID,   admin)
              VALUES ('rein', 'nix',    9999, 'j')--', 'pass', 124, 'n')

Der neue Benutzer erhält den Benutzernamen rein, das Passwort nix und wird mit der ID 9999 und Administratorrechten angelegt, während die Webanwendung eigentlich die ID 124 vorgesehen hatte und einen normalen Benutzer anlegen wollte.

Da der Angreifer meist nicht genau weiß, wie viele Parameter benötigt werden und welchen Typ sie haben müssen, muss er eventuell mehrere Versuche durchführen, bis ein Angriff erfolgreich ist. Dazu fügt er so lange weitere Felder zu seinem Parameter hinzu, bis der gewünschte Benutzer angelegt wurde. Da die meisten Datenbanken einen Integer-Wert automatisch in einen String umwandeln, sobald das notwendig ist, kann ein Integer-Wert an jeder Position verwendet werden.

Außer Daten einzugeben, kann der Angreifer über das INSERT-Statement manchmal auch Informationen ausspähen. Voraussetzung dafür ist, dass er im Statement auf sie zugreifen kann, um sie dann z.B. in sein Profil zu schreiben. Danach kann er das Profil auf dem normalen Weg aufrufen und die Daten lesen.

Alles neu macht das UPDATE

UPDATE-Statements dienen zum Ändern einer oder mehrerer existierender Zeilen in einer Tabelle, z.B. nach dem Muster

UPDATE benutzer SET passwort='neu' 
   WHERE name='jo' AND passwort='geheim'

Die Abfrage prüft name und passwort, und wenn beide zusammenpassen, wird das Passwort auf den neuen Wert geändert. Ist über den Parameter für den Benutzernamen SQL-Injection möglich, kann der Angreifer durch Eingabe von

admin'--

die Passwortprüfung umgehen und das Passwort des Benutzers mit dem Benutzernamen admin ändern. Würde stattdessen

admin' OR 1=1--

eingegeben, würde das Passwort jedes Benutzers geändert:

UPDATE benutzer SET passwort='neu' 
   WHERE name='admin' OR 1=1--' AND passwort='egal'

Es ist also ziemlich gefährlich, bei der Suche nach ausnutzbaren SQL-Injection-Schwachstellen einfach irgendein mögliches Angriffsmuster einzugeben. Vor allem, wenn man nicht weiß, wo die entsprechende Eingabe überall verwendet wird. Es ist durchaus möglich, dass eine Webanwendung nach einem erfolgreichen Login den übergebenen Benutzernamen verwendet, um weitere Tabellen, z.B. für eine Benutzerstatistik, über UPDATE-Statements zu aktualisieren. Wird die Passwortabfrage wie in About Security #167 beschrieben durch Eingabe des Benutzernamens

' OR 1=1--

ausgehebelt, werden danach alle Zeilen in alle betroffenen Tabellen überschrieben. Einem Angreifer kann das ziemlich egal sein, beim Test einer produktiv eingesetzten Webanwendung kann sowas aber schnell fatale Folgen haben. Zwar könnte man auch eine produktiv eingesetzte Webanwendung entsprechend testen, wenn alle Beteiligten sich des Risikos bewusst sind und ein aktuelles Backup existiert, ich rate davon aber dringend ab. Die Installation eines Testsystems ist jedem auch noch so kurzen Ausfall des Produktivsystems vorzuziehen.

In der nächsten Folge wird das noch fehlende DELETE-Statement vorgestellt, außerdem geht es dann um das Verknüpfen mehrere SELECT-Statements über den UNION-Operator.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #166: Schwachstellen-Suche: SQL-Injection Grundlagen
• About Security #167: Schwachstellen-Suche: SQL-Injection über Strings
• About Security #168: Schwachstellen-Suche: SQL-Injection statt Zahlen
• About Security #169: Schwachstellen-Suche: SQL-Injection Statements