Dies ist der erste Teil der Artikelserie Automated Threat Detection mit CEP, die aufzeigt, wie mittels komplexer Ereignisverarbeitung Angriffe auf eine Website entdeckt werden können. Die Serie besteht aus den folgenden Artikel:

1. Teil 1: Einführung (dieser Artikel)
2. Teil 2: Token Cracking / Credential Cracking
3. Teil 3: Fingerprinting
4. Teil 4: Credential Stuffing

OWASP

Um hier kein Buzzword-Bingo zu spielen, gehe ich zuerst auf die einzelnen Begriffe ein.

Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern.
Quelle: Wikipedia.

Sie ist die Herausgeberin der OWASP Top Ten, einer Auflistung der zehn häufigsten Sicherheitslücken in Webanwendungen und Diensten. Dieses Nachschlagewerk dient Architekten und Entwicklern dazu, ihre Anwendungen gegen Angriffe zu schützen. Zur Top Ten gehören Angriffsvektoren wie Injection (nicht nur SQL), Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) und viele Andere.

Zusätzlich zur OWASP Top Ten hat sie kürzlich das Automated Threat Handbook (PDF) herausgegeben. Dabei geht es darum, häufige automatisierte Angriffe als solche zu erkennen, was nicht immer einfach ist.

CEP

Complex Event Processing (CEP; Verarbeitung komplexer Ereignisse) ist die Echtzeitverarbeitung von grossen Ereignisströmen und dient dem Finden von Zusammenhängen und Mustern zwischen den Ereignissen.
Dazu werden Ereignisse von verschiedenen Event Handlern verarbeitet, die jeweils für unterschiedliche Muster zuständig sind.
Diese Ereignisse werden teilweise zwischengespeichert oder aggregiert um in neuer Form weiterzuleiten.
In einem Kundenprojekt hatten wir beispielsweise die Aufgabe, Messwerte aus dem Stromnetz zu aggregieren und anhand der Messwerte Probleme in der Stromverteilung vorauszusagen. Wir wollen CEP nutzen, um automatisierte Angriffe anhand ihrer Muster zu erkennen.
Für CEP gibt es eine Vielzahl an Produkten, sowohl kommerziell als auch Open Source. Hier eine kleine Auswahl an Open Source CEP-Engines:

1. Apache Spark
2. Apache Storm
3. Esper / NEsper

Da wir uns in dieser Artikelserie nicht in einem verteilten Umfeld befinden, benötigen wir keine zusätzliche Software. Wir nutzen daher die .NET Reactive Extensions.

Rx

Die .NET Reactive Extensions sind eine Open Source Bibliothek von Microsoft, die das .NET Framework erweitert. Sie erlaubt das asynchrone Verarbeiten von Datenströmen.

In den kommenden Artikeln werden wir einzelne Missbrauchsmöglichkeiten von Webanwendungen anschauen und mit den nun kennengelernten Methoden aufdecken.

Dieser Beitrag erschien zuerst auf michaelschuler.ch.

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.