(SQL)Injection – Hier gibt der Angreifer die Richtung vor

Sowohl in den „OWASP Top Ten", als auch bei den „SANS Top 25 Most Dangerous Software Errors" taucht die Schwachstelle der Injection auf. Deren bekanntester Vertreter ist wohl die SQL-Injection,. Allerdings lassen sich auch andere Befehle oder Code-Schnipsel in anfällige Anwendungen injizieren. Doch welche Schwachstelle steckt eigentlich hinter dieser Art der Angriffe, wie funktionieren sie und welche Gegenmaßnahmen sollten dagegen ergriffen werden? Diese Fragen werden wir im Rahmen dieses Beitrags klären!

Befehle statt Anfragen

Klären wir zuerst die Frage, was man unter „Injection-Angriffen" versteht. Vereinfacht gesagt, kann der Angreifer spezielle Zeichenketten erstellen, die er durch die Eingabemasken an das Programm übergibt. Diese Zeichenketten führen dazu, dass das Programm Befehle auf den dahinterliegenden Systemen ausführt, die der Angreifer durch die Wahl der Zeichenketten definiert.

Beginnen wir mit einem einfachen Beispiel:

Angenommen in unserem Unternehmen existiert ein Web-Tool, mit dem beliebige Hostnamen via nslookup aufgelöst werden können. (Die Notwendigkeit des Tools hinterfragen wir an dieser Stelle nicht). Der Benutzer trägt in der Eingabezeile den Hostnamen ein, das Programm führt anschließend auf der Befehlszeile den Befehl „nslookup [hostname]" aus und liefert das Ergebnis an den Benutzer zurück.

Bei normaler Verwendung des Programms funktioniert alles ohne weitere Probleme und in einem normalen Test würden vermutlich keine Fehler gefunden. Wenn der Angreifer nun den Hostnamen „Server123 && ls" auflösen lässt, wird auf dem System der Befehl „nslookup Server123 && ls" ausgeführt. Infolgedessen erhält der Angreifer nicht nur das Ergebnis des nslookup-Befehls zurück, sondern auch ein Dateisystemlisting des aktuellen Verzeichnisses.

Der Fehlerteufel steckt im Detail

Deine Eingabe prüfen, du musst!

Im vorausgegangenen Kapitel wurden nur zwei möglich Beispiele für „Injection"-Angriffe dargestellt, wobei das grundlegende Vorgehen immer gleichbleibt – der Angreifer kann (beliebige) Befehle an das Programm übergeben, welche im Anschluss ausgeführt werden. Doch was kann man nun dagegen tun?

Die einfachste und in einem Großteil der Fälle auch wirksamste Gegenmaßnahme ist die Prüfung der Eingabe. Die meisten Hostnamen werden keine doppelten „&"-Zeichen in ihrem Namen haben, und dass Mitarbeiter ein Hochkomma und ein Semikolon im Namen haben, ist auch eher ungewöhnlich. Werden die Eingaben auf solche Steuer- oder Befehlszeichen serverseitig (!) gefiltert und entweder vor der Ausführung entfernt oder die Befehle daraufhin überhaupt nicht ausgeführt, können die meisten Angriffe bereits vermieden werden.

Auf der einen Seite gibt aber es sicherlich Sonderfälle, in denen eine solche Prüfung nicht das gewünschte Ergebnis erzielt und auf der anderen Seite ist es auch nicht immer einfach die korrekten Filter zu finden und wirklich alle entsprechenden Zeichen (in jeglichen Zeichensätzen) korrekt zu identifizieren. Daher lohnt es sich häufig andere Lösungen zu verwenden. Die meisten verbreiteten Frameworks und Plattformen haben bereits einen guten Schutz gegen SQL-Injection, sodass man bei der Eigenentwicklung das Rad nicht neu erfinden muss, sondern auf bestehende Lösungen aufbauen sollte. Ist es dennoch unabdingbar selbst SQL-Statements zu schreiben, sollten diese als sog. „Prepared Statements" auf den Datenbanken vor dem Zusammensetzen mit der Benutzereingabe geparst werden. Denn dann wird der „neue" Befehl nicht mitgeparst, sondern wirklich als Name an die Datenbank weitergereicht.

Zusammenfassung