Da bin ich doch kürzlich fast auf einen alten Hut reingefallen. Und da das so leicht ging, möchte ich an dieser Stelle eine kleine Warnung aussprechen, um zusätzlich zu sensibilisieren. Es geht mir um SQL-Injection, eine Angriffsmöglichkeit, die in ihrer Schlichtheit und Nachvollziehbarkeit überrascht, in ihrer Gefährlichkeit aber kaum zu hoch eingeschätzt werden kann. Ein erfolgreicher Angriff kann im leichtesten Fall Eingaben manipulieren oder Daten ausspionieren, ebenso einfach ist es jedoch, die Datenbank in ihrer Struktur zu kompromittieren oder sogar Zugriff auf andere Systemressourcen zu erlangen.
Die Funktionsweise ist rasch erklärt. Werden im Quellcode der Webanwendung Datenbankanfragen aus den Eingaben leichtfertig zusammengesetzt, etwa in der Form
UPDATE Projekte SET ProjName='" + projname + "' WHERE ProjID='" + projid + "'"
so kann ein Angreifer mit SQL-Kenntnissen und Wissen um die Datenbank-Struktur durch geschickte Nutzung von Sonderzeichen eigene SQL-Befehle einschleusen.
Was tun?
Eine grundsätzliche Regel sollte es sein, keine System-Fehlermeldungen nach außen sichtbar werden zu lassen. Eigentlich selbstverständlich, da man die Nutzer ja damit nicht belasten will. Durch Provozieren solcher Fehlermeldungen kann ein Angreifer nämlich die nötigen Kenntnisse über Datenbank und Quellcode erlangen und dadurch seinen Angriff ohne viel Probiererei durchziehen.
Dem Angriff selbst kann widerstanden werden, indem die Nutzereingaben genau überprüft und dabei SQL-Sonderzeichen maskiert werden. Es gibt Bibliotheken für alle gängigen Systeme, die genau diese Funktionalität unterstützen.
Ein weiterer richtiger Schritt ist der Einsatz von STORED PROCEDURES und damit die Übergabe der Verantwortung für Parameter an den Datenbank-Server.
Weblinks: