Suche
W-JAX Blog von Dominik Schadow

The Web Application strikes back

Dominik Schadow

©Shutterstock/Andrey_Kuzmin

In den letzten Jahren hat die Sicherheit vieler Webanwendungen vor allem durch ein höheres Sicherheitsbewusstsein und mehr Know-how unter den Entwicklern spürbar zugenommen. Auch wenn das Optimum längst noch nicht erreicht ist, bieten sich als nächster Schritt selbst verteidigende Webanwendungen an. Diese können – in einem festgelegten Rahmen – selbst und vollautomatisiert auf laufende Angriffe reagieren und einen als Angreifer identifizierten Benutzer z.B. ausloggen oder vollständig sperren. Analog zu Intrusion Detection Systems spricht man hierbei von Application Intrusion Detection.

Keine künstliche Intelligenz

Mit sich selbst verteidigenden Anwendungen ist nicht der alte Traum der künstlichen Intelligenz und lernenden Anwendungen gemeint. Es sind auch keine Signaturen wie etwa bei Virenscannern im Spiel. Stattdessen nutzen die Entwickler einer Webanwendung die häufig bereits ohnehin vorhandenen Daten zusätzlich zur Angriffserkennung und lassen einen laufenden Angriff so früh wie möglich automatisch abwehren.

Als Einstiegsbeispiel für die Application Intrustion Detection lassen sich Drop-Down-Boxen in Eingabeformularen verwenden. Erreicht ein nicht im Drop-Down vorhandener Wert das Backend, erkennt das System einen Angriff und reagiert entsprechend. Einem normalen Benutzer ist eine solche Eingabe verwehrt, also muss ein Angreifer z.B. mittels eines Intercepting Proxies den Request nach dem Abschicken manipuliert haben.

Nicht immer sind Angriffe allerdings eindeutig erkennbar. Enthält etwa ein Formular im Feld Vorname die Zeichen ’; kann das auf einen Angriffsversuch per SQL Injection hinweisen. Der Angreifer könnte etwa bestimmte Eingaben durchprobieren und so die Webanwendung austesten. Aber auch, dass sich der Benutzer bei der Eingabe einfach nur vertippt hat. Gibt es allerdings vom selben Benutzer mehrere solcher Eingaben innerhalb einer definierten Zeitspanne, erhöht sich die Angriffswahrscheinlichkeit signifikant. Als Reaktion darauf wird der Benutzer nach einer festgelegten Anzahl von Ereignissen abgemeldet und bei einer Wiederholung beispielsweise für die nächsten 60 Minuten gesperrt.
Aus diesen beiden Beispielen lassen sich drei wichtige Anforderungen an selbstverteidigende Webanwendungen ableiten:

  1. Es sind verschiedene Stellen für die Erkennung eines Angriffs nötig (sogenannte Detection Points), gleichzeitig ist deren Kontext wichtig
  2. Eine minimale Anzahl von als Angriff eingestufter Ereignisse muss für jedes Ereignis individuell konfiguriert werden können (als Thresholds bezeichnet)
  3. Die Reaktion (d.h. die Response) auf einen erkannten Angriff muss konfigurierbar sein

Diese drei Punkte muss man als Entwickler nicht in jeder Webanwendung vollständig aufs Neue umsetzen. Unterstützung bietet das OWASP AppSensor Projekt, das sich ganz der Echtzeiterkennung von Angriffen, deren Analyse und einer passenden Antwort widmet. Zusätzlich ermöglicht die umfassende Protokollierung von (vermeintlich) erkannten Angriffen, Angreifer während ihrer Arbeit zu beobachten und Angriffsmuster zu studieren.

Detection Points

Detection Points sind die Stellen, an denen ein potenzieller Angriff auf eine Webanwendung erkannt werden kann. Die Webanwendung muss für eine brauchbare Angriffserkennung dafür nicht mit tausenden Detection Points zugepflastert werden. Es genügt, einen Angreifer frühzeitig zu identifizieren, wozu nicht jedes existierende Angriffsmuster abgedeckt werden muss (was in der Realität ohnehin unmöglich ist).

Zahlreiche brauchbare Stellen für Detection Points sind in vielen Webanwendungen ohnehin bereits vorhanden. Die Backend-Validierung von Eingabedaten etwa eignet sich perfekt als Detection Point: werden die Daten bereits im Frontend validiert, sollten hier keine ungültigen Daten mehr ankommen. Im else-Zweig der if-valid-Prüfung lässt sich daher der erste Detection Point unterbringen. Ohne weitere Prüfung ist dieser aber mit Vorsicht zu behandeln: Es könnte sich ja auch um eine Eingabe handeln, die nicht korrekt in der Whitelist berücksichtigt wurde. Damit ein Angriff per SQL Injection oder Cross-Site Scripting (XSS) erkannt werden kann, müssen die Eingabedaten daher in diesem else-Zweig zusätzlich gegen eine Blacklist validiert werden. In dieser Blacklist sind bekannte Angriffspattern enthalten, mit denen die Eingaben abgeglichen werden (etwa eine Prüfung auf ein script-Element). Diese Blacklist wird wie jede Blacklist niemals vollständig sein. Manche Angriffe werden daher nicht erkannt werden, dank der Whitelist bei der Eingabevalidierung aber dennoch nicht ins System gelangen.

Einfacher fällt die Entscheidung bei der eingangs beschriebenen Drop-Down-Box. Hier wird häufig ohnehin der Wert in eine enum umgewandelt. Ein nicht existierender Wert wird erkannt und als Angriff eingestuft.

Bei Datenbankabfragen ist häufig ein weiterer geeigneter Detection Point vorhanden. So wird mit getSingleResult() auf das eine erwartete Ergebnis zugegriffen, etwa bei der Ermittlung eines Benutzers anhand der Benutzer-ID. Zwar kann ein leeres Ergebnis bei einer fehlerhaften ID durchaus vorkommen, aber mehr als eines darf nicht möglich sein. Eine Ergebnismenge größer eins deutet damit auf eine Query-Manipulation per SQL Injection hin. Anstatt nun ausschließlich die Exception zu protokollieren, reagiert die Webanwendung entsprechend auf diesen Angriff.

Thresholds

Gerade bei einer fehlgeschlagenen Validierung ist es wichtig, nicht sofort mit der maximalen Stärke zurückzuschlagen. Evtl. hat sich der Benutzer einfach nur vertippt und unwillentlich die Eingabevalidierung ausgetrickst. In diesem Fall empfiehlt es sich zunächst, das Ereignis zu protokollieren und erst bei wiederholtem Auftreten innerhalb einer gewissen Zeitspanne etwa mit dem Ausloggen des Benutzers zu reagieren. Anders sieht der Fall bei einer erkannten Eingabe von SQL Injection oder Cross Site Scripting aus. Hier sollte bereits das erste Ereignis zum Sperren des Benutzers und der Benachrichtigung des Administrators führen.

Wichtig ist, dass sich alle Grenzwerte pro Ereignistyp individuell konfigurieren lassen und auch Erweiterungen wie “6 Ereignisse eines Benutzers pro 24 Stunden bzw. 4 Ereignisse eines Benutzers pro 4 Stunden” berücksichtigt werden können. Gleichzeitig sollen diese Grenzwerte und auch die Antworten selbst zur Runtime geändert werden können um etwa auf einen laufenden DDoS-Angriff reagieren zu können.

Responses

Die Beispiele haben bereits einige unterschiedliche Antworten auf erkannte Angriffe gezeigt. Je zweifelsfreier ein Angriff identifiziert werden kann, desto deutlicher (härter) sollte die Antwort ausfallen. Bei vermeintlich schädlichen Daten gilt aber “Im Zweifel für den Benutzer”. Hier bietet es sich an, als erste Reaktion die Protokollierung zu verstärken – d.h. den Benutzer zu beobachten und seine Operationen zu protokollieren – und einen Administrator per SMS oder E-Email zu benachrichtigen. Bei wiederholtem Auftreten kann der Benutzer abgemeldet, gesperrt oder seine IP-Adresse auf eine Blacklist gesetzt werden.

Responses sind prinzipiell kaum Grenzen gesetzt, alles was die Anwendung unterstützt, kann als Antwort verwendet werden. Hierbei sollte allerdings der Rahmen der Legalität nicht verlassen werden, ein Gegenangriff auf den PC des Angreifers ist daher definitiv keine angebrachte Antwort.

Grenzen der Selbstverteidigung

Sich selbst verteidigende Webanwendungen lösen nicht alle Probleme oder sollten gar als einzige Schutzmaßnahme eingesetzt werden. Application Intrusion Detection ist aber sehr viel näher an der Webanwendung dran als eine Web Application Firewall. Schließlich kennt niemand die Webanwendung besser als deren Entwickler, und niemand kann die für einen Angriff lohnenswerten Stellen besser identifizieren. Anstelle einer generischen Firewall verwendet man so eine sehr individuelle Angriffserkennung, der Kontext der Daten wird viel stärker berücksichtigt. Grundvoraussetzung für den Einsatz der Application Intrusion Detection ist in jedem Fall eine vor den üblichen Sicherheitsproblemen wie Cross-Site Scripting oder SQL Injection abgesicherte Webanwendung. Weiterhin ist ein gewisser Zusatzaufwand für die Planung und Integration der Detection Points, Thresholds und Responses notwendig. Belohnt wird man anschließend aber mit einer deutlich sichereren und stärker automatisierten Webanwendung und erfährt gleichzeitig noch etwas über deren Angreifer.

Aufmacherbild: shield and swords isolated coat of arms von Shutterstock / Urheberrecht: Andrey_Kuzmin

Geschrieben von
Dominik Schadow

Dominik Schadow hat über zehn Jahre Erfahrung in der Java-Entwicklung und arbeitet als Senior Consultant beim IT-Beratungsunternehmen BridgingIT. Er ist auf die Architektur und Entwicklung von Java-Enterprise-Applikationen, Enterprise Application Integration und die sichere Softwareentwicklung mit Java spezialisiert. Daneben ist er regelmäßiger Speaker auf verschiedenen Konferenzen rund um die Themen Java und sichere Softwareentwicklung, Buchautor und Autor zahlreicher Fachartikel. In seiner Freizeit leitet er das Open-Source-Projekt JCrypTool, mit dem Anwender für die Kryptografie begeistert werden und ihre eigenen Krypto-Plug-ins entwickeln können.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.