Donnerstag, 7. Juni 2012


Topthema

Donnerstag, 21. August 2008 | Topthema

About Security #169: Schwachstellen-Suche: SQL-Injection Statements

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

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

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

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.

About Security: Die komplette Serie

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.

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

About Security - �bersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren