Der Angriffsvektor “SQL-Injection” ist seit Jahren die Nummer 1 bei den OWASP Top 10, und aus meiner Sicht ist das auch absolut berechtigt.
Was ist eine SQL-Injection?
Kurz gesagt, ermöglicht man einem Angreifer beliebige SQL-Kommandos auszuführen. Die Konsequenz: der Angreifern kann beliebige Daten aus der Datenbank abfragen (z. B. Passwörter), Daten in der Datenbank manipulieren oder die Struktur der Datenbank zu ändern bzw. Daten zu löschen.
Technisch gesehen wird das eigentlich SQL-Kommando, das von der Applikation ausgeführt wird, so manipuliert, dass auf Daten zugegriffen werden kann, auf ein “normaler” Benutzer keinen Zugriff haben sollte.
Eine detaillierte Beschreibung kann auf der Seite der OWASP finden.
Warum ist die SQL-Injection so gefährlich?
Fast alle großen Fälle von Passwortdiebstählen der letzten Zeit sind auf SQL-Injection Lücken zurückzuführen. Das Gefährliche daran ist, das schon eine Unachtsamkeit an einer Stelle im Code reichen kann um an sämtlich Daten der Datenbank heran zu kommen.
Blind SQL-Injection
Bei der “normalen” SQL-Injection werden die “gewünschten” Daten direkt auf der Webseite angezeigt. Bei der “Blind SQL-Injection” werden die Daten nicht direkt auf der Webseite angezeigt, was zu der Annahmen verleitet, dass diese Lücke nicht so schlimm sei. Aber mit Hilfe von Tools wie “sqlmap” ist es sehr einfach möglich die gewünschten Daten systematisch auszulesen. Dieses Video auf Youtube veranschaulicht dies sehr schön.
Gegenmaßnahmen
Wie so oft ist sind die wichtigsten Gegenmaßnahmen Input- und Output-Validierung. Die Output-Validierung, wo eigentlich eine Encodieren, der vom User eingeben Daten, durchgeführt wird, wird von Datenbank-Frameworks (wie z. B. JPQL oder Hibernate im Java Umfeld) oder Prepraed-Statements automatisch gemacht. Daher ist der beste Schutz vor SQL-Injection solche Frameworks konsequent zu benutzen.
Eine ausführliche Zusammenfassung der Gegenmaßnahmen bietet wieder die OWASP an.