Applikationen, speziell Web-basierte Anwendungen, sind zu einem wahren Problem geworden. Netzwerk-Administratoren sehen sich ebenso wie Applikations-Architekten mit der Notwendigkeit konfrontiert, ihre Lösungne entweder von Grund auf neu zu entwickeln oder andere effektive Schutz-maßnahmen zu ergreifen. Eine Forderung, die durch neue gesetzliche Vorschriften wie PCI nur noch drängender wird.

Was haben neue Betriebssysteme und die neuen Arten von Applikationen historisch betrachtet gemeinsam, was IT-relevante Aspekte betrifft? Von wenigen rühmlichen Ausnahmen abgesehen, ist es die Tatsache, dass die Sicherheit kein integraler Bestandteil der Entwicklung war. Dies ist per se keine Kritik, denn schließlich gelten für Applikations-Entwickler andere Prioritäten (etwa Zweckdienlichkeit, Benutzerfreundlichkeit usw.), die den Vorrang gegenüber der Einbindung von teurem und kompliziertem, sicherheitsorientiertem Code haben. Die seit einiger Zeit stark gewachsene Verbreitung Web-basierter Applikationen hat bezüglich der Sicherheit nur wenig Aufmerksamkeit erregt. Hier ist erst seit einiger Zeit eine Änderung erkennbar. Weshalb aber gerade jetzt? Bekanntermaßen neigen Sicherheits-Experten dazu, jede Menge abgedroschener Erkenntnisse herunterzuleiern, wenn man ihnen die Gelegenheit dazu gibt. Fakt ist aber, dass alles, was populär ist, auch ein potenzielles Angriffsziel darstellt. Die PCs der meisten Menschen auf der Welt laufen unter Windows, und so zielt der Großteil der Attacken aus dem Internet auf eben dieses Betriebssystem. Folgerichtig ist ebenfalls, dass der Popularitätszuwachs von Mac OS seit Einführung des iPod im Jahr 2001 den unliebsamen Nebeneffekt hatte, dass die Zahl der Angriffe auch hier zunahm. Und dies sind nur zwei von vielen Beispielen. Wenn eine Aussage zum Thema Sicherheit zutrifft, dann die, dass es sich hier um einen niemals endenden Kampf handelt. Nur die Art, wie die Attacken geführt werden, ändert sich fortwährend, denn auch die Angreifer werden ständig cleverer. Spamming wird zunehmend durch Phishing verdrängt, und auch die Motivation wandelt sich, denn anstatt um persönlichen Ehrgeiz geht es immer mehr ums Geld. Die Anbieter von Sicherheits-Lösungen schließen alle möglichen Einfalltore, nur um festzustellen, dass sich an anderer Stelle wieder neue Pforten öffnen. Sobald alte Angriffs-Vektoren unterbunden werden, entstehen neue, angetrieben vom Einfallsreichtum jener Subjekte, die alles daran setzen, uns das Geld aus der Tasche zu ziehen. Dieser Personenkreis richtet seine Schaffenskraft auf alles, was eine gewisse kritische Masse erreicht und so populär wird, dass es als Angriffsziel lohnend erscheint. Was sich in den letzten Jahren abzeichnet ist zudem ein Trend immer zielgerichteter Angriffe, da diese erheblich einträglicher sein können. Ein solches Angriffsziel sind die immer zahlreicher werdenden Applikationen, auf die per Browser zugegriffen wird. Es geht dabei um Tools von Firmen wie SAP, Salesforce.com und anderen, die zunehmend genutzt werden, um die in Datenzentren ruhenden Informationsbestände so aufzubereiten, dass sie von Vertriebsmitarbeitern, Konsumenten und unzähligen anderen Anwendern genutzt werden können. Dieser Beitrag soll aufzeigen, weshalb diese Applikationen anfällig sind und was man gegen diese Anfälligkeit unternehmen kann.

Worin genau liegt das Problem?

Zum Schutz von Web-Applikationen setzt man in der Regel auf das Konzept der Risikostreuung mit einem mehrschichten Paketfilter-Design. Man platziert die verschiedenen Komponenten einer Web-Applikation (Front-End-Web-Server, Applikations-Server, Back-End-Server) hierzu in verschiedenen Zonen. Die einzelnen Komponenten in den unterschiedlichen Zonen werden jede für sich geschützt konfiguriert, und auch das Betriebssystem wird zusätzlich abgesichert. Selbst wenn es einem Angreifer gelingen sollte, aufgrund einer Sicherheitslücke die Kontrolle über eines der Systeme zu erlangen, kommt es zu keinen größeren Schäden, da zwischen den Zonen nur die für die Applikation benötigten Ports geöffnet sind (Bild 1). Nachteilig ist die vollkommene Machtlosigkeit dieses Konzepts gegen Angriffe auf der Ebene der Web-Applikation, denn Eingabefelder oder Formulare lassen sich aus der Sicht der Applikation nicht als legal oder illegal identifizieren. Im Unterschied zu konventionellen Client/Server-Applikationen wird bei Web-basierten Applikationen der Quellcode an den Client-PC übertragen, wo er naturgemäß von jedermann gelesen (und geändert) werden kann. Es ist folglich sehr einfach möglich, im Rahmen eines Requests an den Server in einem Eingabefeld auch einen veränderten Quellcode, eine angehängte URL oder einen Angriffsversuch zu senden, die vom Ziel-Server mitverarbeitet werden. Wenn es einem Angreifer beispielsweise gelänge, über ein Eingabefeld einen SQL-Befehl per Internet in den Applikations-Server zu schmuggeln, würde dieses SQL-Kommando auf vollkommen legalen Wegen über die zulässige Verbindung und durch die Paketfilter bis in die Datenbank gelangen. Obwohl hier keinerlei Regeln verletzt worden wären, könnte das betreffende Unternehmen Opfer eine potenziell gefährlichen Attacke werden. Moderne Web-Applikationen besitzen üblicherweise eine „n-Tier Architecture“, also eine in mehrere Ebenen gegliederte Struktur. Meistens sind es die drei Ebenen Präsentation, Logik und Daten (Bild 2). Die Präsentationsschicht enthält Einrichtungen zur Entgegennahme von Eingaben und zur Ausgabe von Ergebnissen. Die Logik-Ebene übernimmt die Eingaben von der Präsentationsschicht, nimmt (möglicherweise unterstützt von der Daten-Ebene) bestimmte Arbeiten daran vor und leitet die Ergebnisse an die Präsentationsschicht zurück. Die Daten-Ebene ist für die nichtflüchtige Speicherung der Daten zuständig, die von der Logik-Ebene abgefragt und modifiziert werden können. Die meisten Technologien (ASP, J2EE, PHP usw.) ähneln in ihrer Arbeitsweise eher Executables als statischen, textbasierten HTML-Seiten. Im Prinzip hat jeder dezentrale User die Möglichkeit, Code im Web-Server mit anwenderspezifischen Eingaben auszuführen. Absichern des Web-Servers bringt hier keine Verbesserung. Eine ins Auge fallende, wirksame Abwehrmaßnahme gegen diese Attacken könnte sein, die Web-Applikation selbst sicher zu programmieren, doch in der Praxis erfolgen meist nur rudimentäre Prüfungen. Hinzu kommt, dass Elemente wie Cookies, HTTP-Header, Session-Informationen in der URL sowie verborgene Felder im HTML-Quellcode nicht selten vollständig ignoriert werden. Der Code kann und wird deshalb gravierende Sicherheitslücken enthalten, die Attacken wie SQL-Injection, Cross Site Scripting, Cookie Poisoning, Parameter Tampering, Command Injection und Buffer-Overflow-Attacken Tür und Tor öffnen.

Nachbessern oder neu entwickeln?

Auf die Sicherheit des Codes können sich Unternehmen somit nicht verlassen. Interessant ist an dieser Stelle die Frage nach dem warum. Die Gründe sind zahlreich, doch im Vordergrund dürfte ein generelles Wissensdefizit stehen, was umfassende Angriffstechniken auf der Applikations-Ebene betrifft, gepaart mit der Tatsache, dass die Programmierung von sicherem Code komplex, zeitaufwändig und damit auch teuer ist. Entwickler neigen dazu, sich auf den Aspekt mit der höchsten Priorität zu konzentrieren: die Applikation muss die Aufgabe erfüllen, für die sie konzipiert ist. Noch unübersichtlicher wird die Lage, wenn Applikationen zugekauft werden oder die Programmierung an externe Unternehmen vergeben wird. Hier setzen Firmen auf das Prüfen ihrer Web-Applikationen, um die mit gekaufte Anfälligkeit ebenso beurteilen zu können wie die neu hinzugekommene Funktionalität. Alle eben gemachten Aussagen gipfeln in der Erkenntnis, dass ein Unternehmen verwundbar ist mit der daraus resultierenden Frage, was dagegen getan werden kann. Die Neuentwicklung wäre eine Option, doch kann dies eine geplante Produkteinführung um Monate oder auch ein ganzes Jahr hinauszögern. Als wäre dies nicht genug, kommen entscheidende Mehrkosten hinzu, die für sich genommen schon für erhebliches Stirnrunzeln in der Vorstandsetage sorgen dürften. Der Karriere eines IT-Direktors oder CIO sind solche Dinge kaum dienlich. Also ist Nachbesserung das Mittel der Wahl. Ebenso wie die nicht von Grund auf sicheren Betriebssysteme den Anbietern von Virenschutz-Programmen und dergleichen eine Lebensgrundlage geschaffen haben, stellt eine Web Application Firewall (WAF) in den meisten Situationen (hoffentlich) die richtige Lösung dar. Diese Technologie wird vor der Web-Applikation in das Netzwerk integriert
und leistet mehr als klassische Firewalls. Der Unterschied besteht darin, dass WAFs in der Lage sind, zwischen verschiedenen Eingabefeldern, Parameterwerten und Cookies der einzelnen Applikationen zu unterscheiden, und dass sie mehrere Web-Applikationen gleichzeitig unterstützen können.

Web Application Firewalls

WAFs sollten mit einer vorgefertigten Sperrliste geliefert werden, in der bekannte Angriffs-Signaturen verzeichnet sind. Auch einen automatischen Update-Service sollte der Anbieter bieten. Wichtig ist in jedem Fall, dass die gewählte Technologie die Funktion enthält, bestimmte Eingabefelder von dieser Prüfung auszuschließen, um Fehlalarme zu vermeiden. Zum Beispiel ist es denkbar, dass Sie die Eingabe von HTML-Code oder Scripts in bestimmten Web-Applikationen (etwa in technischen Diskussionsforen) ausdrücklich gestatten möchten. Eine weiter reichende Konfigurations-Option für den Administrator ist das Konzept der Freilisten. Hierin wird alles Erlaubte verzeichnet, während alles nicht ausdrücklich Aufgeführte automatisch als verboten eingestuft wird. Dies ergibt einen weitaus umfassenderen Schutz und verhindert auch Day-Zero-Attacken. Im Idealfall sollte eine gute WAF eine Kombination dieser Positiv- und Negativlisten-Verfahren enthalten. Auf dem Positivlisten-Konzept aufbauend, kommt der Hauptvorteil der WAF ins Spiel, nämlich die Fähigkeit, von der Web-Applikation zu lernen und sie zu interpretieren. Dynamische und statische Aspekte werden dabei zu einer effektiven Policy verbunden. Der Hauptunterschied zwischen beiden Konzepten ist, dass eine dynamische Policy zur Laufzeit, eine statische Policy dagegen im Voraus generiert wird. Zum Beispiel definiert ein Administrator bei einer dynamischen Policy während der Installation die zulässigen Einstiegspunkte (Seiten) für eine WAF. Greift der Anwender auf eine solche Einstiegsseite zu, werden sämtliche Links und Parameter des HTMLCodes aus der Antwort während der Laufzeit zu einer dynamisch erstellten Policy hinzugefügt, die nur im Speicher existiert und nicht (etwa für ein Sicherheits-Audit) angezeigt werden kann. Leider kann diese Option nicht sinnvoll für komplexe Applikationen verwendet werden, die Client-seitig mit Javascript arbeiten, denn sie ermöglicht das Erstellen der geforderten URL mit den Parametern auf der Client-Seite. Dies wiederum hat die Konsequenz, dass der Administrator die entsprechenden URLs als Sonderregel definieren muss. Es gibt mehrere Beispiele dafür, dass die Anwendung von Client-seitigen Javascripts mit dynamischen Policies Probleme bringt. Deshalb wird in der Praxis meist die statische Variante bevorzugt. In diesem Fall erstellt der Administrator eine Policy vorab mit Hilfe eines Tools (manuell oder automatisch), was die transparente Darstellung jeder einzelnen Policy-Regel oder -Definition gestattet. Dies kann in einigen Fällen (beispielsweise bei einem Sicherheits-Audit) sehr wichtig sein.

Weitere Features

Ein weiteres sinnvolles Feature einer WAF ist die Fähigkeit zum Konfigurieren des Navigationspfads, um zu kontrollieren, wie und von wo aus eine bestimmte Seite zugänglich sein soll. Ist beispielsweise festgelegt, dass auf das Objekt „z.html“ nur zugegriffen werden darf, wenn der Anwender zuvor einen Zugriff auf „y.html“ ausgeführt hat, blockiert die WAF jeden direkten Zugriff auf „z.html“. Dies wird als selektive Flusskontrolle bezeichnet. Die meisten WAFs können prüfen, ob ein statischer Wert in der HTTP-Abfrage von einem Angreifer geändert wurde oder nicht. Die WAF muss allerdings auch Schutz vor dem Ändern dynamischer, im Server generierter Werte bieten können. Ein solcher dynamischer Wert, der zur Laufzeit von der Applikation generiert wird, kann beispielsweise in der URL oder in verborgenen Feldern vorkommen. Wird ein solcher Wert geändert, was relativ leicht möglich ist, so kann dies die Konsequenz haben, dass ein Produkt im Einkaufskorb zu einem günstigeren Preis ausgewiesen wird oder dass der Zugriff auf die Daten anderer User möglich ist, ohne deren Benutzernamen und Passwort einzugeben (Bild 3). Applikationen verwenden häufig schwache Algorithmen zum Generieren der Session ID, welches dynamisch im Server erfolgt und als klare Kennung für den Benutzer verwendet wird. Gelingt es einem Angreifer, dies auszunutzen und in den Besitz der Session ID eines anderen Users zu gelangen, ist der Zugriff auf die Daten dieses Anwenders möglich, ohne dessen Benutzername und Passwort einzugeben. Eine WAF sollte Schutz hiergegen bieten, indem sie beispielsweise diesen Wert aus einer zurückliegenden Antwort extrahiert und im folgenden Request überprüft. Eine weitere wichtige Funktion einer WAF ist die Fähigkeit zum Überprüfen von Cookies. Eine effektive WAF muss feststellen können, ob ein Cookie ungewollt modifiziert wurde (Cookie Poisoning), um die Weiterleitung entsprechender Anfragen an die Web-Applikation zu unterbinden. Ein Angreifer könnte damit nicht mehr auf die Applikations-Session eines anderen Users zugreifen. Eine Möglichkeit für die WAF bestände darin, die Namen und Inhalte sämtlicher Applikations-Cookies zu zerhacken und zu signieren und einem weiteren Cookie abzuspeichern, das zusätzlich verschlüsselt werden könnte. Dieses ergänzende Session Cookie wäre nur im Speicher des Clients existent. Schließlich arbeiten die meisten WAFs als Reverse Proxy und sind somit in der Lage, auf Basis einer Policy eine Verbindung zu beenden und eine HTTP-Anfrage des Clients zu analysieren. Daraufhin öffnet die WAF eine vollkommen neue Verbindung zum Senden des HTTP-Requests an den Web-Server oder den Load Balancer. Einige Anbieter kombinieren Application-Delivery-Funktionen wie etwa Traffic Management, Kompression, Caching und SSL-Beschleunigung mit der Applikations-Sicherheit (WAF) auf ein und derselben Appliance-Hardware, was vorteilhaft ist, weil es die Performance verbessert, das Management vereinfacht und die Kosten senkt.

Alfredo Vistola

Diesen Artikel finden Sie auch in der Ausgabe 1-2008 des it security.