Haben sie ihr Kind wirklich ‚;DELETE FROM dbo.Schueler; genannt?

Wenn man diese Frage am Telefon gestellt bekommt hat man als Eltern vermutlich Spaß mit der Schule. Natürlich ist das ein sehr überspitztes Beispiel. Aber SQL-Injection ist immer noch eine der größten und am häufigsten ausgenützten Sicherheitslücken. Nachdem immer häufiger Frameworks in der Softwareentwicklung verwendet werden wird die SQL Injection immer weniger. Aber auch die schützen nicht automatisch davor, da ist immer noch die Sorgfalt des Entwicklers gefragt.

Was ist eigentlich SQL Injection?

Wenn eine SQL Injection zum Einsatz kommt versucht der Angreifer SQL Code zu manipulieren und so entweder mehr Daten ausgegeben zu bekommen oder Daten zu löschen. Um SQL Code zu manipulieren werden dabei Parameter überschrieben. Nehmen wir Mal folgendes Beispiel:

SELECT username
FROM Tabelle
WHERE userid = 7;

Wenn nun die 7 als Parameter bspw. aus einem Webrequest kommt und direkt übernommen wird kann diese Abfrage einfach manipuliert werden. Nehmen wir als Beispiel folgende Webadresse: www.domain.de/index.php?userid=7 Wenn man diese Adresse nun so manipuliert, dass man als neue Adresse www.domain.de/index.php?userid=’7 OR 1=1′ bekommt wird nicht mehr nur der Parameter 7 sondern ein String als Parameter übergeben.

Daraus ergibt sich folgender SQL Code:

SELECT username
FROM Tabelle
WHERE userid = 7 OR 1=1;

Dieses SQL liefert nun nicht mehr nur den einen Usernamen zurück sondern alle, da die WHERE Bedingung immer erfüllt ist. Statt des Integer-Wertes 7 den der Entwickler hier erwartet bekommt er nun einen String der die komplette Prüfung aushebelt. Der Fall könnte auch noch deutlich schlimmer ausgeführt werden, wenn nicht nur einfach alle Daten ausgegeben werden sondern Code hinzugefügt wird der dann Datensätze löscht oder manipuliert. Ein weiteres Beispiel wäre, sich unberechtigt Zutritt zu Systemen zu schaffen. Bei einer schlechten Implementierung der Zugriffskontrolle ist sowas möglich, indem durch Manipulation von Benutzername oder Passwort bspw. immer ein Datensatz zurückgegeben wird bei der Abfrage ob Benutzername und Passwort korrekt sind. Wenn hier der Zugriff gewährt wird sobald ein Datensatz durch die Überprüfung zurückgegeben wird kann man gegebenenfalls Zugriff bekommen.

Was kann man gegen SQL Injection tun?

In unserem Beispiel von oben ist es relativ einfach diesen Fall zu verhindern. Im Code der Anwendung muss überprüft werden ob der Parameter den richtigen Typ hat. Bei einer Typüberprüfung wäre es hier ganz einfach festzustellen, dass ein String übergeben wird obwohl eigentlich nur ein Integer erwartet wurde. In so einem Fall dürfte das SQL nicht ausgeführt werden.

Der wichtigste Punkt ist, traue keinem Wert der von außen kommt. Wenn man hier jeden Wert überprüft, Sonderzeichen maskiert und z.b. auf saubere Typen achtet hat man schon Mal die wichtigste Aufgabe getan. Parametrisierte SQLs sind weniger anfällig für SQL Injection als dynamisch zusammengebaute SQLs. Das sind aber Aufgaben die durch den Applications-Entwickler erledigt werden müssen. Wenn man erst ab dem SQL Server Einfluss hat wird es schwieriger hier einzugreifen. Um einen der worst cases der SQL Injection zu verhindern, das löschen von Daten, können Zugriffe begrenzt werden. Dann könnte bspw. bei einer Webanwendung ein Benutzer für das Schreiben und ein Benutzer für das lesen der Daten zuständig sein. Das würde zumindest einen Fall verhindern.

Grundsätzlich gilt: SQL Injection ist ein Thema das man auf dem Schirm haben muss. Da wir alle wissen, dass wir in der Entwicklung immer mal Fehler machen sollten Anwendungen immer gut auf mögliche SQL Injection getestet werden.