Verteidigung gegen SQL-Injection-Angriffe - ETH Zürich

Grundsätzlich wird davon abgeraten, Benutzereingaben direkt in SQL-Code einzubetten (auch wenn die Wertesorgfältig überprüft worden sind). Stattdessen sollten immer Prepared-Statements verwendet werden. Wirdein Datenbank-Produkt verwendet, das keine Prepared-Statements verwendet, sollte unbedingt auf ein anderesProdukt ausgewichen werden. Die meisten Datenbank-Produkte und Datenbank-Bibliotheken unterstützenPrepared-Statements.Neben direkten kann es auch indirekte Angriffe geben. Dies ist dann potenziell möglich, wenn aus der Datenbankausgelesene Daten für eine weitere Abfrage in ein SQL-Statement eingebettet werden. Gelingt es einem Angreifer,bestimmten SQL-Code als Wert in die Datenbank zu schreiben, ist es unter Umständen möglich, dass eineAbfrage, die diesen aus der Datenbank ausgelesenen Wert in den SQL-String einbettet, Schaden anrichten kann.Wie ein solcher Angriff genau aussieht, wollen wir an einem (fiktiven) Beispiel aufzeigen. Nehmen wir an, einAngreifer konnte den Wert ’ or ’’ = ’ als Benutzername (Feld username) auf legalem Weg in die Datenbankschreiben (z. B. mittels eines Formulars, womit er sein Profil bearbeiten kann). Nehmen wir weiter an, dass eineApplikation diesen Benutzernamen aus der Datenbank liest und in eine SQL-Abfrage einbettet:SELECT * FROM interests WHERE username = ’${username}’Mit ersetzter Variablen sieht diese Abfrage folgendermassen aus:SELECT * FROM interests WHERE username = ’’ or ’’ = ’’Es werden sämtliche Datensätze aus der Tabelle interests zurückgeliefert. Somit kann der Angreifer unterUmständen an unberechtigte Informationen gelangen.In der Demo-Applikation sind die folgenden Seiten potenziell von indirekten Angriffen betroffen (weil Datenaus einer vorhergehenden Abfrage verwendet werden):• main.jsp (zweites SELECT-Statement)• showmsg.jsp (zweites SELECT-Statement)Weil aber die eingebetteten Daten (Feld authorid) nicht vom Benutzer manipuliert werden können (die Wertevon authorid werden ausschliesslich von der Applikation generiert), kann das Auftreten von indirekten Angriffenausgeschlossen werden.Anhand der indirekten Angriffe erkennt man die Wichtigkeit, Benutzer-Eingaben auf einen möglichst minimalenWertebereich zu beschränken. Insbesondere ist dies für Primary- und Foreign-Keys notwendig. Wir müssen beidiesen Eingaben sicherstellen, dass sie keine potenziell gefährlichen Zeichen enthalten. Noch besser ist es, keineFelder als Primary- und Foreign-Keys zu verwenden, die vom Benutzer manipuliert werden können (z. B.parallel zum Benutzernamen eine von der Applikation generierte Benutzer-ID führen, die jeweils als Primarybzw.Foreign-Key verwendet wird).4.5.3 Verwendung von Beans für das Ausführen von SQL-StatementsBei falscher Konfiguration des Application-Servers kann es unter Umständen vorkommen, dass der Quellcodean den Browser gesendet wird, statt dass der Code auf dem Server ausgeführt wird und das Resultat an denBrowser gesendet wird. Damit würde ein Angreifer sehr einfach Einsicht in die verwendeten SQL-Statementserhalten.Um die Auswirkungen dieses Problems zu verringern, sollten alle SQL-Statements in Java-Beans ausgelagertwerden. Einem solchen Bean werden zuerst die notwendigen Parameter übergeben. Dann überprüft das Bean dieParameter. Schliesslich führt das Bean den SQL-Code unter Verwendung eines Prepared-Statements aus. Falls21