Vor Kurzem habe ich am Kurs «Web Application Security» von SWITCHcert teilgenommen.

Kurz darauf habe ich diesen Comic-Strip getweetet, welchen wir am Kurs angeschaut hatten weil er mir so gut gefallen hat.

Inzwischen habe ich merken müssen, dass nur Geeks und andere Security-affine Personen den Gag verstehen. Ich gebe hier also eine kurze Erklärung ab:

Eine der Sicherheitslücken, die in unsorgfältig erbauten Websites vorkommen kann, sind sogenannte SQL-Injections. SQL ist die Script-Sprache, mit welcher Datenmanipulationen Datenbanken ausgeführt werden. Damit können Datensätze ausgelesen werden, die gewissen Kriterien entsprechen oder diese geändert oder gelöscht werden.

Die meisten modernen Webanwendungen verwenden Datenbanken.

Das Problem von SQL-Injections tritt dann auf, wenn Benutzereingaben mit SQL-Strings kombiniert werden.

Das ist oft der Fall: Der Suchbegriff in einem Suchfeld soll in die Abfrage integriert werden, z. B.  wenn ein Formular anbietet, nach  einen Mitarbeiter mit einem bestimmten Namen oder einem Produkt mit einer bestimmten Bezeichnung zu suchen. Oder wenn man sich mit Vornamen, Nachnamen, E-Mail-Adresse registrieren soll.  Diese Werte, die man in einem Formular eingibt sollen selbstverständlich in einer Benutzertabelle gespeichert werden bzw. in der Suchabfrage berücksichtigt werden.

Wenn aber diese Eingaben unkontrolliert übernommen werden, kann es eben schiefgehen. Davon handelt der Comic:

Robert') DROP TABLE Students; --

Das ist ein Beispiel, wie eine SQL-Injection aussehen könnte.

In der fiktiven Web-Anwendung der Schule, gibt es ein Formular, in welches der Name ausgefüllt werden soll, vielleicht für die Anmeldung zum Abschlussball oder was auch immer.

Little Bobby Table oder seine Mutter hat als Name «Robert›)  DROP TABLE Students; –» eingegeben und so die Datenbanktabelle «Students» komplett gedropt = gelöscht.

Der SQL-Befehl der hätte ausgeführt lautete etwas, wie:

INSERT INTO Students (Name, Geburtsdatum, ...) VALUES ("Robert", "23.05.1978", ...)

Die Werte, also «Robert», das Geburtsdatum und vielleicht weitere Felder sollten über das Formular eingetragen werden.

Man könnte das so darstellen:

'INSERT INTO Students (Name, Geburtsdatum, ...) VALUES ("' . [Webformular.Name.Value] . '", ' . [Webformular.Geburtsdatum.Value], ...)

Der SQL-Befehl wird aus mehreren Teilen zusammengesetzt: Der eigentliche Befehl bis und mit VALUES (» und dann wird mit Hilfe des Punktes der Wert aus dem Formularfeld Name angehängt. Anschliessend geht der Befehl (wieder durch den Punkt verbunden weiter mit «,  und dann soll der nächste Wert, das Geburtsdatum kommen.

Soweit kommt es aber gar nicht: Nach dem Namen Robert beendet das Hochkomma den angefangenen SQL-Befehl und fügt einen neuen ein:

DROP TABLE Students

Dieser löscht die Studententabelle ratzeputz weg.

Das Script würde aber noch weitere Felder erwarten (Geburtsdatum und so).

Damit jetzt kein Fehler auftritt, wird der Befehl mit dem Semikolen beendet und mittels den beiden «-» ein Kommentar gestartet.

Alle Inhalte der folgenden Felder oder jeder weitere SQL-Befehl wird also ignoriert.

So könnte der Schaden

We lost this years students records

entstanden sein. Die schlechten Noten können nicht mehr zugeordnet werden – und die guten auch nicht.

Verhindert werden kann eine solche Attacke, indem sogenannte parametrisierte Abfragen verwendet werden. Dabei handelt es sich um eine Technik, die von allen Datenbanksystemen unterstützt wird. Der SQL String wird dabei nicht Stück für Stück zusammengesetzt, sondern als ganzes verwendet. Einzelne Platzhalter werden durch die Werte aus dem Formular ersetzt. Selbstverständlich wird dabei überprüft, ob die übergebenen Werte der Erwartung entsprechen, also wenn ein Datum erwartet wird, auch ein gültiges Datumsformat eingegeben wurde.

Solche Attacken kann man ausprobieren mit WebGoat, einer absichtlich unsicheren Webanwendung, die zum Lehren und Lernen von Sicherheitsthemen entwickelt wurde.

Das haben wir am Kurs auch intensiv gemacht und darum bin ich jetzt

Mehr von mir: [follow_me]