entwickler.com

In dieser Folge erfahren Sie, wie Sie die in About Security #11 vorgestellten SQL-Injection-Angriffe durch das Prüfen der Benutzereingaben verhindern können.

Um das Einschleusen von SQL-Code zu verhindern, müssen alle Eingaben vor ihrer Verwendung in einer SQL-Abfrage geprüft und ggf. bereinigt werden. Und zwar wirklich alle und nicht nur die, die ein Benutzer offiziell ändern kann. Ein Angreifer kann auch z.B. im Formular versteckte Felder oder Cookies manipulieren. Außerdem müssen die Eingaben auf dem Server geprüft werden. Eine Prüfung auf dem Client kann vom Angreifer manipuliert oder umgangen werden. Auch der manchmal genannte Rat, die Länge von Eingabefeldern zu beschränken, schützt nicht vor dem Einschleusen manipulierter Daten. Ein Angreifer kann problemlos eine eigene, manipulierte Webseite verwenden, bei GET-HTTP-Requests die URL manipulieren oder die Daten direkt über Telnet an den Server senden. Daher darf nur den direkt auf dem Server geprüften Daten vertraut werden.

Bestimmte Eingaben prüfen

Der einfachste Fall sind Parameter, die nur numerische Werte annehmen dürfen. Diese Eingaben können direkt in Werte des entsprechenden Wertebereichs umgewandelt werden. Im Beispiel aus About Security #11 trifft dies auf die Spalte BenutzerNr zu: Alle Eingaben dafür können in ganzzahlige positive Werte umgewandelt werden.

Ähnlich ist es bei Eingaben, die nur bestimmte Werte annehmen dürfen. Dies sind z.B. Eingaben für Staaten, Monatsnamen oder Produktgruppen in Webshops. In derartigen Fällen kann die Eingabe mit einer Liste zulässiger Werte verglichen und eine unzulässige Eingabe verworfen werden. Im Beispiel aus About Security #11 trifft dies auf den Wert für den Status zu. Da dort nur die Werte normal und admin zulässig sind, können alle anderen Eingaben verworfen werden.

Beliebige Eingaben prüfen

Schwieriger ist die Behandlung von Eingaben, die beliebige Werte annehmen können. Dies trifft z.B. auf alle Arten von Namen oder allgemein Suchwörter zu.

Für manche Eingaben, z.B. E-Mail-Adressen oder Telefonnummern, kann man die Menge zulässiger Zeichen exakt bestimmen und die Eingabe dann mithilfe regulärer Ausdrücke darauf prüfen. Alle Eingaben, die unzulässige Zeichen enthalten, werden verworfen. Diese Methode ist jedoch nur anwendbar, wenn keine potenziell gefährlichen Zeichen wie z.B. das Quote-Zeichen (') zulässiger Teil der Eingabe sind. Ihr Vorteil: Die Eingabe enthält nach der Filterung mit Sicherheit nur erwünschte Zeichen.

Es gibt Fälle, in denen eine Einschränkung nicht möglich ist oder potenziell gefährliche Zeichen zulässiger Bestandteil der Eingabe sind. In diesen Fällen muss die Menge der möglichen gefährlichen Zeichen festgelegt und diese dann gezielt ausgefiltert oder maskiert werden. Der Nachteil dieser Methode: Ein für Angreifer nützliches Zeichen könnte bei der Festlegung der auszufilternden Zeichen übersehen werden.

Im Beispiel in About Security #11 gehört das Feld BenutzerName zu diesen Fällen: Ein O'Conner wäre wohl kaum begeistert, wenn sein Name zu OConner verkürzt oder sogar zurückgewiesen würde. Daher muss in diesem Fall das Zeichen "'" so maskiert werden, dass es als Bestandteil der Zeichenkette und nicht des Befehls interpretiert wird. Dies geschieht meist durch Voranstellen eines Backslash: \'. Dabei sollte jedoch bedacht werden, dass eine Eingabe wie z.B. O'Conner zu O\'Conner wird. Damit der Eintrag in der Datenbank gefunden wird, muss er daher auch so gespeichert worden sein.

Einige für Webanwendungen verwendete Programmiersprachen stellen bereits Funktionen zum Maskieren bereit, ansonsten können derartige Funktionen aber auch sehr einfach selbst formuliert werden.

In PHP gibt es die Funktionen addslashes() und speziell für MySQL mysql_real_escape_string() zum Maskieren bestimmter Zeichen wie "'" und "\". Den gleichen Effekt erzielt man durch Einschalten von magic_quotes_gpc in der Konfigurationsdatei php.ini. Beides zusammen führt jedoch zu Problemen, da die betreffenden Zeichen doppelt maskiert werden. Daher müssen bei aktiviertem magic_quotes_gpc alle Variablen vor der Behandlung mit mysql_real_escape_string() mit stripslashes() von den bereits eingefügten Backslashes befreit werden.

In Perl gibt es die Funktion quote() aus dem DBI-Modul, die die für die jeweils verwendete Datenbank kritischen Zeichen maskiert. Für ASP gibt es keine fertige Lösung, eine entsprechende Funktion kann jedoch mithilfe von replace() implementiert werden.

Ein Problem aller Filtermethoden ist, dass die Filter unter Umständen durch andere Darstellungsformen für die zu filternden Zeichen (z.B. UTF, URL-Kodierung) umgangen werden können.

Oben erfuhren Sie, wie SQL-Injection durch die Prüfung und Filterung der Eingaben verhindert werden kann. Eine weitere Möglichkeit, das Einschleusen von SQL-Code zu verhindern, ist die Verwendung von Stored Procedures. Diese und weitere Gegenmaßnahmen gegen SQL-Injection-Angriffe werden in der nächsten Folge vorgestellt.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver