SQL- & NoSQL-Datenbanken by Andreas Meier & Michael Kaufmann

Autor:Andreas Meier & Michael Kaufmann
Die sprache: deu
Format: epub
Herausgeber: Springer Berlin Heidelberg, Berlin, Heidelberg

Als stark vereinfachtes Beispiel nehmen wir an, dass nach dem Einloggen in das Benutzerkonto eines Webshops die Zahlungsmethoden angezeigt werden. Die Webseite, welche die gespeicherten Zahlungsmethoden des Benutzers anzeigt, hat folgende URL:

http://example.net/payment?uid=117

Im Hintergrund gibt es ein Java-Servlet, welches die Kreditkartendaten (Kartennummer und Name), welche die Webseite mit HTML tabellarisch darstellt, aus der Datenbank holt.

ResultSet resultset =

statement.executeQuery(

"SELECT creditcardnumber, name FROM PAYMENT" +

"WHERE uid = " + request.getParameter("uid"));

while (resultset.next()) {

out.println("<tr><td>" +

resultset.getString("creditcardnumber") +

"</td> <td>" +

resultset.getString("name") + "</td></tr>"

}

Zu diesem Zweck wird eine SQL-Anfrage auf die Tabelle PAYMENT dynamisch generiert, welche über die Identifikation des Benutzers (uid) parametrisiert wird. Diese Codegenerierung ist anfällig für eine SQL-Injection. Wird in der URL der Parameter uid folgendermassen ergänzt, werden sämtliche Kreditkartendaten aller Benutzer auf der Webseite angezeigt:

http://example.net/payment?uid=117%20OR%201=1

Der Grund dafür ist, dass das oben dargestellte Servlet aufgrund des GET-Parameters den folgenden SQL-Code generiert:

SELECT creditcardnumber, name

FROM PAYMENT

WHERE uid = 117 OR 1=1;

Der zusätzlich eingefügte SQL-Code „OR 1 = 1“, die SQL-Injection, bewirkt also, dass der Suchfilter mit der Benutzeridentifizierung in der generierten Abfrage inaktiv wird, da 1 = 1 immer stimmt, und eine OR-Verknüpfung immer wahr ist, auch wenn nur eine der Bedingungen zutrifft. Deshalb gibt in diesem einfachen Beispiel die Webseite aufgrund dieser SQL-Injection schützenswerte Daten preis.

SQL-Injection ist eine große Sicherheitslücke, und Hackern gelingt es immer wieder, auch namhafte Webseiten über diesen Mechanismus anzugreifen. Um eine Webseite davor zu schützen, gibt es verschiedene Möglichkeiten: Erstens werden heute vermehrt NoSQL-Datenbanken wie MongoDB oder CouchDB für die Entwicklung von Webseiten verwendet, die aufgrund fehlender SQL-Schnittstelle naturgemäß keine Angriffsfläche für SQL-Injection bieten. Wird dennoch im Web-Umfeld mit SQL-Datenbanken gearbeitet, kann die Auslagerung von SQL-Codegenerierung in streng typisierte Stored Functions auf der Datenbank vorgenommen werden (siehe Abschn. 3.5.2). Im obigen Beispiel könnte eine Funktion als Input eine Benutzer-ID als Zahl akzeptieren, und dann als Output die Kreditkarteninformationen zurückgeben. Würde dieser Funktion der Text „OR 1 = 1“ als SQL-Injection mitgegeben, würde eine Fehlermeldung generiert.

Im Sicherheitsbereich kann also zusammenfassend gesagt werden, dass auf Ebene des Datenbanksystems die SQL-Datenbanken einen umfassenden Schutzmechanismus mit den Konstrukten CREATE VIEW , GRANT und REVOKE bieten, welche keine NoSQL-Datenbank in ähnlichem Ausmaß abdecken kann. Allerdings können diese Kontrollmechanismen im größeren Rahmen von webbasierten Informationssystemen mit SQL-Injection ausgehebelt werden. Dort bieten NoSQL-Datenbanken mit ihren direkteren API-Anbindungen einen besseren Schutz.

Download

Haftungsausschluss:
Diese Site speichert keine Dateien auf ihrem Server. Wir indizieren und verlinken nur                                                  Inhalte von anderen Websites zur Verfügung gestellt. Wenden Sie sich an die Inhaltsanbieter, um etwaige urheberrechtlich geschützte Inhalte zu entfernen, und senden Sie uns eine E-Mail. Wir werden die entsprechenden Links oder Inhalte umgehend entfernen.