Eine Brandschutzmauer für Webanwendungen

Den meisten Entwicklern, IT-Managern und Testern sitzt die Zeit im Nacken. Von ihnen verlangt die Geschäftsführung, eine sichere IT-Umgebung zu schaffen. Immerhin geht es dabei heutzutage um einen nicht unerheblichen Teil der Geschäftsgrundlage. Gleichzeitig sollte das Ganze wenn möglich seit gestern schon ‘up and running’ sein.

Bei diesem Dilemma leidet vor allem die Sicherheit. Die Programmierer versuchen sich um alle geforderten Details zu kümmern, zu oft allerdings steht der Schutz der Webanwendung so weit unten auf der Liste, dass diese Notwendigkeit nicht selten “ignoriert oder vergessen” wird, wie es die Marktforscher von Forrester in einer Studie zum Thema formuliert haben.

Es gilt also, die verfügbaren Schutzmechanismen zu nutzen, um das IT-Umfeld nicht gänzlich zum offenen Scheunentor zu machen. Und da haben sich die Web Application Firewalls oder Filter, kurz WAF, in den Vordergrund gedrängt. Sie funktionieren wie die klassische Firewall im Netzwerk. Allerdings verrichten sie ihren Dienst auf einer anderen Schicht, der Anwendungsebene, legt man das OSI-Referenzmodell zugrunde. Dort prüfen sie Daten, die über einen Webbrowser an die Anwendung geschickt werden. Enthält der Datensatz bekannten schadhaften Code, blockiert die Firewall diesen und schützt so die Applikation vor Angriffen über HTTP oder andere Protokolle wie LDAP.

Die Möglichkeiten einzudringen sind vielfältig, die denkbaren Schwachstellen kaum noch überschaubar. SQL-Injection, Cross Site Scripting, CommandExe, Path Traversal oder Parameter Tampering beispielsweise sind Schwachstellen, die durch fehlerhafte oder unzureichende Eingabekontrollen zustande kommen. Ein fehlerhaftes Software-Design oder die mangelnde Überprüfung von Benutzereingaben tun ihr Übriges, die Sicherheit von Webseiten und das Backend zu strapazieren.

Sonderzeichen stressen das Backend

WAFs nehmen ankommende Daten genau unter die Lupe. Sie sind Filter und analysieren Eingabewerte, maximale Längen und erlaubte Zeichen für jedes einzelne Formular-Eingabefeld einer Webseite, jeden Parameter, jede URL und jedes Cookie.

Ein Beispiel, mit dem der Sicherheitsspezialist Securenet das Problem verdeutlicht, geht so: In einem bestimmten Dialogschritt sind in einem Formular Vorname und Nachname einzugeben. Das Formular enthält also nur zwei Felder, mit zugeordneten Variablennamen ‘Vorname’ und ‘Nachname’. In der Datenbank ist vermerkt, dass beim Abschicken dieses Formulars nur zwei Formvariablen übertragen werden können. Entdeckt die WAF bei diesem Request weitere Formvariablen, liegt ein Fehler vor, versehentlich oder aufgrund bewusster Manipulation. Das Shield leitet sie nicht an den Webserver weiter, sondern blockt die Anfrage.

Was passiert, wenn Softwareentwickler nur offensichtliche Felder von Eingabemasken überprüfen und auch nur soweit, wie für die Funktion der Anwendung am Ende erforderlich ist, ist schnell erzählt. Das Backend bekommt Probleme, und zwar nicht zu knapp. Wenn dann noch Sonderzeichen übersehen werden, wird es eng. Die nämlich können in Datenbanken besondere unerwünschte Prozesse auslösen oder Hacker könnten Eingaben in Formularen so manipulieren, dass sie am Ende Zugriff auf die Datenbank haben.