Applikationssicherheit

Mehr als Härten und Patchen von Systemen

Das Thema Sicherheitslücken kennt man in allen Organisationen. Sie machen ein Unternehmen verwundbar und erlauben im schlimmsten Fall einem Hacker einzubrechen oder einem Wurm ins Unternehmensnetz einzudringen, wo er sich weiter verbreiten kann.

Als Ursachen für Verwundbarkeiten denken die meisten Leute vor allem an Fehler in Standard-Software oder an unsichere Konfigurations-Einstellungen.

Als Schutz vor diesen Gefahren sieht man das rechtzeitige Einspielen von „Hotfixes“ oder „Service Packs“ der Hersteller sowie das so genannte „Härten“ von Systemen, bei dem ein Spezialist alle gefährlichen und überflüssigen Programme entfernt und die Konfiguration so sicher wie möglich einstellt.

Leider ist diese Sicht der Realität bezogen auf Web-Server beziehungsweise eigene Web-Applikationen sehr unvollständig und nicht mehr zeitgemäß. Die Fehler, die hier zu Verwundbarkeiten und Einbrüchen führen, liegen meist in der eigenen, individuellen Programmierung der Web-Seiten und dort vor allem in der unzureichenden Eingabeverarbeitung von Formularen dynamischer Webseiten. Das Einspielen von „Patches“ oder „Hotfixes“ ändert an diesen Verwundbarkeiten ebenso wenig wie das „Härten“ des Servers.

Organisationen, die sich freiwillig einer Sicherheitsüberprüfung unterzogen haben, um durch einen externen Spezialisten prüfen zu lassen, ob ihre Server Schwachstellen aufweisen, stellen häufig erst viel zu spät fest, dass bei der Prüfung nur ihre Netzwerk-Komponenten, Server, Betriebssysteme und die darauf installierten Standard-Programme betrachtet wurden. Leider wird immer noch in den meisten Fällen die Überprüfung der eigenen Web-Programmierung ignoriert oder vergessen.

Diesen Problembereich, bei dem es um die Sicherheit von Web-Anwendungen und ihre Verwundbarkeiten geht, nennt man Web-Applikationssicherheit. Unter dem Gesichtspunkt, dass fast alle Software-Hersteller ihre Produkte mit Web-Oberflächen ausstatten, lässt man das „Web-“ auch gelegentlich weg und spricht nur von „Applikationssicherheit“. Damit schließt man dann auch die Probleme mit ein, bei denen es nicht um Web-Oberflächen, sondern um klassische Software geht, die aber ähnliche Verwundbarkeiten auf Ebene der Applikation haben kann. Das Entscheidende ist, dass es nicht mehr um Sicherheit auf Netzwerkebene oder auf Betriebssystemebene geht, sondern dass die Verwundbarkeiten innerhalb von eigenen Anwendungen liegen.

Um diese Arten von Verwundbarkeiten auf Anwendungsebene besser kommunizieren zu können, hat man ihnen Namen wie zum Beispiel „Command-Injection“, „Cross-Site-Scripting“, „Parameter Tampering“ oder „SQL-Injection“ gegeben. Die meisten dieser Verwundbarkeiten haben eine gemeinsame Ursache, die in unzureichender Prüfung von Eingabe- oder Status-Werten liegt.

Meist denken Softwareentwickler bei der Prüfung von Eingabewerten nur an offensichtliche Felder von Eingabemasken und prüfen diese Werte auch nur so weit, wie es für die Funktionalität des Programms nötig ist. Was oft vergessen wird sind Sonderzeichen in Eingabewerten, die in Backend-Systemen wie Datenbanken eine besondere Funktion auslösen oder die bei der Übergabe an ein externes Programm von einer Shell interpretiert werden können. Im Fall von Cross-Site-Scripting werden die besagten Sonderzeichen sogar erst bei der späteren Ausgabe durch den Browser eines Anwenders interpretiert. Eine aus Sicht des Entwicklers vielleicht harmlos aussehende Eingabe wie „Kühlschrank <script> …“ wird bei ungefilterter Verarbeitung und späterer Ausgabe ein JavaScript-Element im Browser des Anwenders ausführen. Eine Eingabe, die Anführungszeichen oder Semikolons und SQL-Schlüsselwörter enthält, könnte in einer Backend-Datenbank unerwünschte Aktionen auslösen. Es gibt in diesem Fall leider keine immer gültige und vollständige Liste aller potentiell gefährlichen Sonderzeichen, die man grundsätzlich verbieten könnte. Stattdessen muss von Formular zu Formular oder sogar von Feld zu Feld individuell entschieden werden, welche Zeichen jeweils benötigt werden und welche verboten werden können.

Erschwerend kommt hinzu, dass jeder Wert, den ein Programm über das Netz übermittelt bekommt, von einem Angreifer manipuliert sein könnte. Dazu gehören eben nicht nur offensichtliche Eingabefelder, sondern auch Parameter in URLs, in Cookies und anderen HTTP-Headern oder versteckte Variable, die von der Anwendung selbst gesetzt wurden.

Alle Variationen hier aufzuzählen würde sicherlich zu weit führen. Wer jedoch tiefer in die Materie der Angriffsmöglichkeiten auf Anwendungsebene einsteigen möchte, sei auf das Training „Hacking Extrem Web-Applikationen“ von cirosec verwiesen, in dem genau dieses Thema in drei Tagen ausführlich behandelt wird.

In der Vergangenheit hat man versucht, die Sicherheit von Web-Applikationen mit Hilfe von mehrstufigen Firewall- und DMZ-Strukturen zu gewährleisten. Die Idee war, dass man die verschiedenen Teile einer Web-Applikation wie Frontend-Webserver, Applikations-Server und Backends jeweils mit Firewalls voneinander trennt, um so einen potentiellen Einbruch auf die jeweilige Zone zu begrenzen. Bei solchen mehrstufigen Firewall-Konstruktionen geht man davon aus, dass ein Angreifer auf klassischem Weg in Systeme einbricht. Er nutzt also eine Verwundbarkeit in einem Netzwerkdienst aus, von dort gelangt er auf das Betriebssystem der betroffenen Maschine, wo er dann die komplette Kontrolle über die Maschine bekommt. Von dieser Maschine aus würde er dann versuchen, weitere Systeme auf klassischem Weg anzugreifen. Genau das sollen die mehrstufigen Firewalls verhindern, da sie zwischen den einzelnen Komponenten einer E-Business-Applikation nur die für die Applikation benötigten Ports erlauben.

Leider ist dieses Konzept der mehrstufigen Firewalls gegen Angriffe auf Applikationsebene unwirksam. Angriffe wie SQL-Injection oder auch Cross-Site-Scripting funktionieren mit oder ohne Firewalls auf dieselbe Weise. Bei SQL-Injection gelangen manipulierte SQL-Abfragen über die benötigten und erlaubten Verbindungen bis in die Backend-Datenbank im internen Netz. Firewalls bemerken davon nichts, denn auf der Anwendungsebene transportieren sie Eingabewerte in Formularen oder Suchabfragen in Datenbanken ungefiltert. Hier muss man von einer logischen Verbindung auf Anwendungsebene ausgehen.

Um moderne E-Business-Systeme oder generell Web-Anwendungen vor Angriffen zu schützen, benötigt man neue Techniken, die über klassische Filter auf Basis von „Stateful Inspection“ oder „Deep Inspection“ hinausgehen. Der Schlüssel zum Erfolg ist das Verständnis der Applikation mit ihren einzelnen Seiten, Formularen, Statuswerten und Eingabefeldern durch den Schutzmechanismus.

Ein Produkt zum Schutz solcher Anwendungen muss in der Lage sein, die maximalen Längen, die erlaubten Zeichen oder Werte je Feld und Eingabeformular bzw. Seite zu erlernen und daraufhin Anfragen aus dem Netz zu filtern. Globale Einschränkungen, die bestimmte Zeichen oder Schlüsselworte generell verbieten, sind in der Praxis zum Scheitern verurteilt, da es bei fast allen Applikationen einzelne Ausnahmen gibt, in denen die Zeichen doch benötigt werden. Ein Sicherheitsprodukt muss solche Ausnahmen und feldspezifische Regeln ermöglichen, um für echte Applikationen einsetzbar zu sein.

Entsprechende Produkte nennt man „Web-Application-Filter“ bzw. kurz „WAF“. Die Grundfunktionen von jedem WAF-Produkt sind die Filterung der angefragten Seiten (URLs), die Filterung von Parametern und Eingabewerten sowie die Filterung von Cookies.

Bereits durch das Filtern von URLs können viele Angriffsarten proaktiv verhindert werden. Dazu muss eine WAF die erlaubten URLs kennen, was entweder durch automatisches Lernen oder manuelle Definition erfolgen kann. Sobald eine WAF die benötigten URLs einer Anwendung kennt und nur noch solche Anfragen zulässt, die auf benötigte Teile der Applikation verweisen, sind alle Angriffe, die manipulierte URLs benötigen, nicht mehr möglich. Selbstverständlich müssen dabei variable Parameter oder Session-IDs, die in der URL übermittelt werden, also solches erkannt und berücksichtigt werden.

Die Filterung von Parametern und Eingabewerten erfolgt ähnlich wie die Filterung von URLs. Zunächst muss der Filter die Grenzen und erlaubten Wertebereiche kennen. Auch hier gibt es in den heute verfügbaren Produkten je nach Hersteller unterschiedliche intelligente Lernmechanismen sowie global definierbare Regeln und Ausnahmen je Feld oder Seite. Im Betrieb stellt der Filter dann sicher, dass keine ungültigen Eingabewerte oder sonstige Parameter mehr zum geschützten Webserver gelangen.

Der Aufbau von WAFs vor kritische Web-Applikationen ist ein Ansatz, der seit zwei bis drei Jahren begonnen hat, sich durchzusetzen. Zunächst versuchen zwar viele Organisationen mit gezielten Applikations-Audits die vorhandenen Verwundbarkeiten ihrer Applikationen herauszufinden, um sie dann gezielt zu beseitigen. Doch je häufiger sie so vorgehen, um so schneller reift die Überzeugung, dass es günstiger ist, mit Hilfe einer komfortablen WAF einen proaktiven Schutz vor die Applikationen zu setzen, als ständig neue Fehler in Applikationen zu finden und auf deren Beseitigung zu warten. Oft ist es nicht einmal möglich, direkten Einfluss auf die Programmierung und Fehlerbeseitigung auszuüben, weil es sich bei der Applikation statt einer Eigenentwicklung um das Produkt eines fremden Herstellers handelt.

Während die Performance von WAFs bei Anwendungen mit sehr hohen Zugriffszahlen am Anfang noch ein Problem darstellen konnte, sind heute Systeme mit speziell entwickelten ASICs verfügbar, mit denen auch bei Applikationen, die mehrere hundert Megabit pro Sekunde an Nutztraffic verarbeiten, keine Engpässe mehr auftreten.

zurück