Runtime Application Self-Protection : Alternativer Schutz für Webanwendungen

Von Maik Schäfer, Heilbronn

Üblicherweise wird eine Web-Application Firewall (WAF) eingesetzt, um einerseits das Risiko eines Angriffs auf eigene Webanwendungen zu minimieren – andererseits dienen sie Compliance-Zwecken: etwa, um Standards wie den „Payment Card Industry Data Security Standard“ (PCI DSS) einzuhalten. Seit einigen Jahren möchte sich das relativ junge Verfahren einer „Runtime Application Self-Protection“ (RASP) etablieren, das eine alternative Schutzlösung darstellt, um Webanwendungen vor Attacken zu schützen.

Funktions-Prinzip

Web-Application-Firewalls (WAF) werden in eine bestehende Netzwerkstruktur des Betreibers so eingebunden, dass der Datenverkehr zwischen Benutzer und Webanwendung über die WAF erfolgt. Alle Anfragen, die der Benutzer stellt, erreichen also nicht direkt die Anwendung, sondern zunächst die WAF – genauso durchlaufen die Antworten zunächst die WAF, bevor sie den Benutzer erreichen. Durch diese Anpassung kann das Sicherheitssystem den eingehenden Datenverkehr auf bekannte Angriffe hin untersuchen und bösartige Anfragen blockieren, bevor sie die Anwendung erreichen und Schaden anrichten können. Analog dazu kann die WAF auch die Antworten einer Webanwendung blockieren, wenn sie etwa erkennt, dass spezielle Datensätze (bspw. Kreditkartennummern) an den Benutzer gesendet würden.

Eine RASP-Schutzlösung wird hingegen direkt auf dem Anwendungsserver der zu schützenden Webanwendung eingerichtet und sorgt dafür, dass die Webanwendung von innen heraus abgesichert wird. Hierzu bindet sich die RASP-Lösung in die Anwendungsausführung beziehungsweise in die Ausführungsumgebung der zu schützenden Anwendung ein und kann somit Sicherheitsfunktionen in die Anwendung integrieren. Diese Sicherheitsfunktionen sollen das Ausnutzen von Schwachstellen innerhalb einer Anwendung erkennen und durch Eingriffe in die Programmausführung verhindern, dass der Angriff erfolgreich ist. Dazu bieten die Hersteller von RASP-Lösungen Schutzmechanismen unter anderem gegen die OWASP-Top-10-Schwachstellen an, wozu vor allem Schutzfunktionen zum Verhindern von SQL-Injection, Remote-Code-Execution und Cross-Site-Scripting-Angriffen zählen, gegen die bisher üblicherweise WAFs eingesetzt werden.

Die eingebrachten RASP-Schutzfunktionen verwenden zur Erkennung und Verhinderung von Angriffen die kontextuellen Informationen aus dem Anwendungsinneren, die erst durch die Integration verfügbar sind. WAFs detektieren Angriffe ausschließlich durch konfigurierte Regeln beziehungsweise Muster, die sich im Datenverkehr zwischen Benutzer und Webanwendung untersuchen lassen. Die Kontextdaten, die einer RASP-Lösung zur Verfügung stehen, umfassen dagegen nicht zuletzt Benutzereingaben, verwendete Code-Pfade, auszuführende Datenbankabfragen und Bibliotheks- und Betriebssystembefehlsaufrufe – vieles, was eine WAF überhaupt nicht betrachten kann.

Die verschiedenen RASP-Hersteller setzen dabei unterschiedliche Mechanismen ein, um Angriffe zu erkennen: Einige Lösungen lernen durch Beobachten der Anwendungsausführung, wie sich die Applikation im Normalbetrieb verhält. Dazu wird das Anwendungsverhalten aufgezeichnet und ein Analysedienst (in der Cloud) leitet daraus Regelsätze ab, die das „normale“ Verhalten beschreiben. Zu den Kriterien des Erlernten zählen beispielsweise die Struktur von Datenbankabfragen (SQL-Injection-Schutz), die Pfade von Dateizugriffen, welche die Anwendung für gewöhnlich veranlasst (Information-Disclosure-Schutz) oder Wertebereiche von Daten, die wieder an den Browser gesendet werden (XSS-Schutz). Von dem erlernten Normalverhalten abweichende Verhaltensweisen werden anschließend im Schutzmodus der RASP-Lösung als Angriff gewertet und an der Ausführung gehindert.

Einen eigenen Weg geht ein einzelner RASP-Hersteller: Sein Verfahren ermöglicht es, Daten, die zur Anwendung selbst gehören, von solchen zu unterscheiden, die aus nicht-vertrauenswürdigen Quellen stammen (beispielsweise HTTP-Anfragen). Verwendet die Applikation solche „riskanten“ Daten an sicherheitsrelevanten Stellen (z. B. in einer SQL-Abfrage oder bei der Ausgabe an den Browser), dann untersuchen die Schutzmechanismen, ob diese Benutzereingabe einen Angriff darstellen könnte – etwa, weil die nicht-vertrauenswürdigen Daten die Struktur einer SQL-Abfrage verändern oder schädliches Javascript in die Website einbringen.

Um beispielsweise einen SQL-Injection-Angriff zu identifizieren, unterscheidet die RASP-Lösung zwischen der vorbereiteten SQL-Abfrage (SQL-Query-String als Variable) und den benutzerkontrollierten Werten, die in die Abfrage eingebaut werden. Verändern die hinzugefügten Daten die Struktur der Abfrage, so wertet die RASP-Schutzlösung die Eingabe als Angriff und kann diesen verhindern: indem ein Datenbankfehler vorgetäuscht wird, anstatt die schädliche Abfrage (Query) tatsächlich an die Datenbank zu schicken.

Integration

WAFs und RASP-Schutzlösungen unterscheiden sich auch in dem Aspekt, wie entsprechende Produkte in eine bestehende Struktur eingebunden werden, um Anwendungen abzusichern: WAFs werden häufig als eigene Hardware-Komponente (Appliance) eingesetzt und so konfiguriert, dass der Datenverkehr der zu schützenden Anwendung(en) – wie eingangs beschrieben – über die WAF erfolgt. Dazu muss man die bestehende Netzwerkstruktur insofern verändern, dass die IP-Adressen an das neue Routing angepasst und bestehende Load-Balancer und Gateways eventuell umkonfiguriert werden.

Die Einrichtung eines RASP-Produkts findet dagegen auf dem Anwendungsserver statt, auf dem eine zu schützende Anwendung läuft – jede zu schützende Anwendung wird damit „ausgestattet“, eine Umkonfiguration der Netzwerkstruktur ist dafür hingegen nicht notwendig. Die verfügbaren Lösungen unterscheiden sich darin, ob für die Integration Code-Änderungen an der zu schützenden Anwendung notwendig sind oder nicht. Bei Lösungen, die keine Änderungen erfordern, muss lediglich die Konfiguration angepasst werden, wie die zu schützende Anwendung auf dem Server gestartet wird, damit sich die RASP-Schutzfunktionen darin einbinden.

Im Falle einer zu schützenden Java-Anwendung heißt das, dass entweder der Pfad zum Java-Interpreter (Java Virtual Machine) gegen eine angepasste Version des RASP-Herstellers ausgetauscht oder ein weiterer Parameter beim Aufruf der Applikation beziehungsweise des Anwendungsservers (z. B. Tomcat) hinzugefügt wird, zum Beispiel:

# java -jar vulnerable_application.jar
-javaagent:/path/to/rasp_agent.jar

Der Ansatz, RASP direkt in den Applikations-Code zu integrieren, erfolgt hingegen, indem der Hersteller für die Integration der Schutzfunktionen ein Software-Development-Kit (SDK) anbietet. Dafür müssen die vom SDK bereitgestellten Schnittstellen in die zu schützende Anwendung einprogrammiert werden, über welche die Applikation anschließend zur Laufzeit mit den Sicherheitsfunktionen der RASP-Lösung kommunizieren kann.

Um beispielsweise SQL-Injection-Angriffe zu verhindern, werden die Funktionen aus dem SDK integriert, die das auszuführende SQL-Statement zusammen mit den im SQL-Statement zu verwendenden Benutzereingaben an ein Analysesystem übertragen. Das Analysesystem untersucht mit proprietären Mechanismen, ob die Benutzereingabe die Struktur der Query verändert und damit eine SQL-Injection bedeutet. Falls ja, bereinigt das Analysesystem die Abfrage von der Angriffseingabe.

Vergleich des Installations-Aufwands

Ob das Einbinden einer WAF oder das Einrichten einer RASP-Lösung in der eigenen Umgebung einfacher ist, lässt sich nicht allgemein beantworten: Das hängt nicht zuletzt individuell davon ab, wie die eigene Netzwerkumgebung aufgebaut ist, wie sich die Serversysteme unterscheiden und wie viele Anwendungen man schützen will.

Während WAFs „zentral“ in den Datenfluss eingefügt werden, muss man RASP-Lösungen auf jedem Anwendungsserver installieren und einrichten. Ein Administrator muss also alle betroffenen Systeme entsprechend anpassen beziehungsweise die Änderungen über ein Konfigurationswerkzeug auf diese Systeme „ausrollen“. Bei der Frage nach dem Aufwand ist daher von Bedeutung, auf wie vielen unterschiedlichen Servern sich die verschiedenen Anwendungen befinden und ob sich diese Serversysteme (Windows oder Linux) und die eingesetzten Versionen unterscheiden – gegebenenfalls wird für jede Serverversion die entsprechende RASP-Version vom Hersteller benötigt. Außerdem ist es für die Integration wichtig, zu berücksichtigen, ob es ein zentrales Konfigurationswerkzeug gibt, das es ermöglicht, RASP auf vielen (gleichen) Servern automatisiert einzurichten.

Nach der Einrichtung einer RASP-Lösung lässt sie sich allerdings ebenfalls zentral über ein Dashboard verwalten und konfigurieren – derartige Managementsysteme bieten alle Hersteller an.

System-Abhängigkeit

Ein Nachteil von RASP ist allerdings die Abhängigkeit von der jeweiligen technischen Basis der zu schützenden Anwendung: Für eine RASP-Lösung ist es eben nicht egal, ob die zu schützende Applikation in Java, .NET, Python oder PHP geschrieben wurde – denn die Integration des RASP-Produkts in diese Anwendung hängt von der jeweils verwendeten „Technologie“ ab. Aktuell konzentrieren sich die Hersteller von RASP-Produkten hauptsächlich auf in Java geschriebene Webanwendungen; einige Hersteller bieten jedoch auch bereits Lösungen für .NET, PHP, Python und Ruby an.

Einer WAF ist es dagegen egal, welche Plattform von den Webanwendungen verwendet wird – wichtig ist nur, dass die WAF auch das Anwendungsprotokoll (HTTP) versteht.

Konfiguration

Ein großes Problem und in der Praxis häufig bemängelter Umstand beim Einsatz von WAFs besteht darin, dass die Konfiguration der Regelsätze ein sehr aufwendiger und zeitintensiver Prozess ist: Oft sind die Regeln deshalb nicht vernünftig konfiguriert, sodass die Erkennungsrate von Angriffen entweder zu gering oder zu sensibel konfiguriert ist und es somit zu vielen Fehlalarmen kommt. Die Schwierigkeit entsteht durch die Vielzahl an Möglichkeiten, mit denen Schwachstellen auftreten und auch ausgenutzt werden können. Besonders kompliziert kann es bei Webanwendungen werden, die sich aktiv in Entwicklung befinden und somit eine ständige Aktualisierung der WAF-Regelsätze erfordern. Um dann beispielsweise vor SQL-Injection- oder Cross-Site-Scripting-Schwachstellen zu schützen, müssen in der WAF große Listen mit Zeichenketten und Angriffsmustern gepflegt werden, die auf die einzelnen Anwendungsparameter abzustimmen sind.

Hersteller von RASP-basierten Schutzlösungen behaupten dagegen, bessere Angriffserkennungsraten aufzuweisen als WAFs – und das mit wesentlich weniger Fehlalarmen und deutlich geringerem Konfigurationsaufwand. Tatsächlich erfordern viele RASP-Lösungen für das Aktivieren der Schutzfunktionen (z. B. gegen SQL-Injection oder Cross-Site-Scripting) lediglich, die passende Option ein- oder auszuschalten. Dass es mit RASP so einfach ist, ist erneut der Tatsache geschuldet, dass dieses Verfahren keine Listen vorhandener Angriffsmuster abgleicht, sondern das Anwendungsverhalten kontextuell analysiert. Eine der Stärken von RASP-Lösungen und ein Vorteil gegenüber WAFs ist also das Erkennen von Angriffen – unabhängig von der Eingabeform, in welcher der Angriff die Anwendung erreicht. Das ermöglicht auch die Erkennung von Angriffen, die bis dato überhaupt nicht bekannt sind (Zero-Day-Exploits).

Darüber hinaus lassen sich durch RASP viele Härtungsmaßnahmen konfigurieren, die durch WAFs prinzipiell nicht abzudecken sind: Das betrifft sämtliche Maßnahmen, die das Anwendungsverhalten einschränken. So kann man beispielsweise in einer RASP-Lösung definieren, auf welche Verzeichnisse, Code-Abschnitte, Dateien oder Programme eine Anwendung zugreifen darf. Zugriffe, die zur Laufzeit der Anwendung gegen diese Regeln verstoßen, werden protokolliert und verhindert.

Ebenfalls sehr interessant ist die Funktion eines „Virtual Patching“, die ein Hersteller in sein RASP-Produkt integriert hat: Damit ist es möglich, den Code einer verwundbaren Anwendung nachträglich zu „patchen“, ohne die betroffene Anwendung oder den Server ausschalten zu müssen. Die geänderten Code-Abschnitte werden von der RASP-Lösung einfach zur Laufzeit in die Anwendung integriert und an der betroffenen Stelle umgesetzt.

Sicherung alter Komponenten

RASP-Lösungen können bezüglich des Anwendungsschutzes sogar noch einen Schritt weiter gehen: Je nach gewähltem Produkt ist es teilweise möglich, eine veraltete Java-Anwendung (z. B. für Java 6) auf einem aktuellen Betriebssystem mit aktueller Java-8- oder Java-9-Version zu betreiben – ohne Code-Änderungen an der Anwendung vornehmen oder Inkompatibilitäten befürchten zu müssen. Möglich macht das der virtualisierungsbasierte Ansatz eines RASP-Anbieters, der die zu schützende Java-Anwendung in einem virtuellen Container ausführt und die Ausführung auf die aktuellste Java-Version abbildet. So sollen veraltete Serverumgebungen auf neue Versionen aktualisiert und die bestehenden Legacy-Java-Anwendungen weiter in einer gesicherten Form betrieben werden können.

Fazit

RASP stellt eine relativ neue Möglichkeit dar, um Webanwendungen zu schützen: Damit lassen sich nicht nur Angriffe auf typische Schwachstellen in Webapplikationen mit wenig Konfigurationsaufwand sichern, es können auch nachträglich – ohne Downtime – Veränderungen oder Härtungsmaßnahmen an einer Anwendung vorgenommen werden. Absicherungen wie einen eingeschränkten Zugriff der Anwendung auf das Dateisystem oder bestimmte Code-Abschnitte lassen sich durch WAFs prinzipbedingt nicht umsetzen, sind jedoch mit RASP problemlos realisierbar.

Individuell zu bewerten ist der Aufwand für die Integration in die eigene Umgebung und die Frage nach den Kosten: WAFs werden gewöhnlich nach Anzahl und Größe der Appliances sowie nach Datendurchsatz lizenziert – RASP-Lösungen hingegen häufig nach der Anzahl der zu sichernden Anwendungen oder Instanzen.

Analysten sehen RASP jedenfalls im Aufwind: Laut Prognosen von Gartner wird dessen Verwendung bis 2020 von bisher 1 % auf 25 % steigen. Möglicherweise etabliert sich das Verfahren demnächst vorzugsweise als Anwendungsschutzlösung für Systeme, die dem PCI DSS unterfallen.

Maik Schäfer ist Berater bei der cirosec GmbH.

Schutz durch RASP am Beispiel

Aktuell legen RASP-Lösungen den Fokus auf das Absichern gegen übliche Angriffe auf Webanwendungen – daher werden vor allem die OWASP-Top-10-Probleme wie SQL-Injection, Cross-Site-Scripting, Cross-Site-RequestForgery und fremde Befehlsausführung abgesichert. Da nicht alle RASP-Lösungen technisch gleich funktionieren, unterscheiden sich Funktionsumfang und Art je nach Hersteller. Ein einzelner Anbieter kann zum Beispiel sogar vor Java-Deserialisierungsschwachstellen schützen – diese Schwachstellenklasse ist in den letzten Jahren unter Sicherheitsforschern und Angreifern besonders populär geworden und hat es mittlerweile auf Platz 8 der überarbeiteten OWASP Top 10 2017 geschafft.

Beispiel SQL-Injection

SQL-Injection-Angriffe werden durch WAFs verhindert, indem etwa Zeichen(-ketten) wie ’, ’’, #, – – oder ’1’ = ’1’’ herausgefiltert werden. RASP-Lösungen untersuchen dagegen, ob eine Benutzereingabe innerhalb der Anwendung die Struktur von Datenbankabfragen verändert. In folgendem Beispiel wird ein Benutzername direkt in eine SQL-Abfrage eingebaut – ein Angreifer könnte also einen beliebigen Username wählen, um eine SQL-Injection durchzuführen.

SELECT * from users
WHERE username = ’ + userName + ’;

Wählt der Angreifer den Namen admin’ or true #, so verändert er damit die Struktur der SQL-Abfrage, da zusätzlich eine weitere Oder-Bedingung ausgewertet wird. Damit ergibt sich eine Abfrage, die zur Folge hätte, dass die Datenbank alle Datensätze zurückliefert:

SELECT * from users
WHERE username = ’admin’ or true # ’

RASP-Lösungen erkennen diese Strukturveränderung zur Laufzeit und verhindern, dass die Anfrage ausgeführt wird. Dabei gibt es unterschiedliche Methoden, die sich von Hersteller zu Hersteller unterscheiden: Einige Lösungen lernen, dass die Abfrage aus dem obigen Beispiel im Normalfall lediglich eine WHERE-Klausel für den Benutzernamen enthält und verhindern eine Abfrage, die zusätzlich eine weitere (zu „true“ ausgewertete) Bedingung enthält. Andere RASP-Lösungen erkennen dagegen eigenständig, welcher Teil der Abfrage in der Anwendung selbst programmiert ist und welcher Teil aufgrund von Benutzerangaben hinzugefügt wurde. Durch diese Unterscheidung ist es anschließend möglich, zu untersuchen, ob eine Eingabe die ursprünglich kodierte Struktur verändert.