Wenn Sie heute eine Website veröffentlichen, vergehen kaum ein paar Minuten, bis sie das erste Mal angegriffen werden. Diese Artikelserie beschäftigt sich mit den OWASP Top 10, den zehn meisten Sicherheitsrisiken, und gibt Tipps, wie sie sich und ihre Produkte schützen können.
Diese Serie besteht aus den folgenden Artikeln:
- Teil 1: Injection (dieser Artikel)
- Teil 2: Fehler in Authentifizierung und Session-Management
- Teil 3: Cross-Site Scripting (XSS)
- Teil 4: Unsichere direkte Objektreferenzen
- Teil 5: Sicherheitsrelevante Fehlkonfiguration
- Teil 6: Verlust der Vertraulichkeit sensibler Daten
- Teil 7: Fehlerhafte Autorisierung auf Anwendungsebene
- Teil 8: Cross-Site Request Forgery (CSRF)
- Teil 9: Nutzung von Komponenten mit bekannten Schwachstellen
- Teil 10: Ungeprüfte Um- und Weiterleitungen
Injection
Auf Platz 1 der OWASP Top 10 ist Injection, also das Einschleusen von Schadcode in eine Anwendung. Am bekanntesten ist zweifelsohne SQL Injection, dazu gehören jedoch auch Angriffe wie LDAP Injection oder Command Injection. Wir schauen uns hier SQL Injection näher an.
SQL Injection
SQL Injection ist das am meisten verbreitete Sicherheitsrisiko im Internet. Das liegt sicher auch daran, dass es sehr einfach zu entdecken ist. Tragischerweise lässt sich mit SQL Injection viel Schaden anrichten. OWASP stuft die Auswirkung von SQL Injection als schwer ein.
Die Gefahr ist überall dort, wo Eingaben eines Benutzers für Datenbankabfragen benutzt werden. Diese Eingaben können von einem Angreifer gezielt manipuliert werden.
Gehen wir davon aus, Sie entwickeln ein CRM-System. Der Benutzer kann Kunden in einer Liste anzeigen lassen und mit einem Klick auf den Kunden kommt der Benutzer auf eine Detailansicht. Die Liste ist unter der URL https://domain.tld/customers erreichbar, die Detailansicht unter https://domain.tld/customers/edit?id=12, wobei 12 die ID des Kunden ist. Möglicherweise sieht Ihr Quellcode dann so aus:
var sql = "select * from customer where id = " + customerId; var customer = FetchData<Customer>(sql);
Unter normalen Umständen funktioniert dieser Code wie gewünscht. Aber was geschieht, wenn der Benutzer die URL auf https://domain.tld/customers/edit?id=hallo ändert? Das Ausführen des Queries schlägt dann fehl. Zeigt die Website die Fehlermeldung an, weiss der Angreifer, dass es sich hier erstens um einen Datenbankfehler handelt und zweitens, dass die Website durch SQL Injection angreifbar ist.
Sobald ein solches Einfallstor gefunden ist, ist praktisch alles mit der Datenbank machbar. Sie lässt sich komplett auslesen, ändern oder sogar löschen. Beispielsweise gelangte die Gruppe LulzSec 2011 über eine einfache SQL Injection bei Sony Pictures an über eine Million Zugangsdaten.
Befolgen Sie drei Punkte, um sich gegen SQL Injection zu schützen. Erstens, unterscheiden Sie zwischen vertrauenswürdigen und nicht vertrauenswürdigen Daten. Dazu müssen Sie sich Gedanken darüber machen, was überhaupt vertrauenswürdige Daten sind. Dann darüber, wie Sie das unterscheiden können. Zweitens, nutzen Sie parametrisierte SQL Commands. Dadurch trennen Sie das SQL Statement von den Eingaben, diese können das Statement nicht mehr ändern. Drittens, nutzen Sie einen Datenbankzugriff, der nur die benötigten Berechtigungen hat. Man sieht leider zu oft Anwendungen, die DB Owner-Berechtigungen haben.
Um nur vertrauenswürdige Daten zuzulassen, können Sie beispielsweise einen Regulären Ausdruck verwenden. Wenn Sie lediglich Zahlenwerte erwarten, können Sie den Eingabewert entsprechend konvertieren.
Parametrisierte SQL Commands ersetzen von Hand zusammengesetzte Commands. Mit klassischem ADO.NET sieht das Beispiel nun folgendermassen aus:
var command = new SqlCommand("select * from customer where id = @id");
var parameter = command.Parameters.Add("id", SqlDbType.Int);
parameter.Value = customerId;
Zuerst verwenden Sie im SQL Statement den Parameter @id anstatt dem händischen Zusammensetzen des Statements. Dann deklarieren Sie den Parameter mit dem dazugehörigen SQL Datentyp, danach können Sie den Wert zuweisen.
Ist Ihre Anwendung sicher? Nebst der in diesem Blog beschriebenen Möglichkeiten gibt es viele weitere Strategien, sich gegen Angreifer zu verteidigen. Gerne beraten wir Sie in Sicherheitsfragen oder führen ein Security Review in Ihrem Projekt durch. Kontaktieren Sie mich dazu per E-Mail oder rufen Sie mich unverbindlich an, um Ihre dringlichsten Fragen zu besprechen.
Dieser Beitrag erschien zuerst auf michaelschuler.ch.
