Kostenersparnis birgt großes Risiko – Web-Applikationen bieten viele Vorteile, in Sachen IT-Sicherheit stellen sie aber eher einen Rückschritt dar.

Immer mehr Unternehmen verlagern ihre geschäftskritischen Anwendungen und Daten auf Web-Oberflächen. Die Gründe dafür liegen auf der Hand: Browser-basierte Anwendungen sind leichter in Betrieb zu nehmen, zu unterstützen und zu warten. Der Trend wird sich sicher fortsetzen, denn die Browser und deren Scriptsprachen werden leistungsfähiger und Internet-Services werden zum Standard. In der Tat sind selbst wichtige Unternehmensanwendungen heute Web-basiert.

Leider sind viele der Eigenschaften, die Browser so komfortabel und kostengünstig machen, auch dafür verantwortlich, dass es zahlreiche Schwachstellen gibt. Deswegen ist es für Hacker kein Problem, sich über Web-basierte Anwendungen Zugang zum Unternehmenssystem zu verschaffen und sensible Kundendaten einzusehen.

Ursachen für Schwachstellen von Anwendungen

Weder Würmer und Viren, noch bekannte Schwachstellen der Anwendungsserver sind heute die Ursache für die gefährlichsten Sicherheitslücken auf der Anwendungsschicht. Denn es sind Schwachstellen in den Anwendungen selbst. Diese Schwachstellen – die bei jeder Anwendung anders sind – machen die Web-Infrastruktur eines Unternehmens anfällig für Angriffe wie Cross-Site-Scripting, SQL-Injections oder Cookie-Poisoning.

Der eigentliche Grund für die Schwachstellen von Anwendungen liegt in ihrer Herkunft. Die meisten Web-Applikationen wurden mit Hilfe von Methoden entwickelt und getestet, die eigentlich für Client-Server-Anwendungen gedacht waren. In einigen Fällen waren die Applikationen am Anfang reine Client-Server-Anwendungen, die dann auf das Web »übertragen« wurden, ein Vorgang, der oft aus kaum mehr Aufwand bestand als aus der Reproduktion der grafischen Benutzeroberfläche des Client im Web-Browser. In anderen Fällen wurden die Anwendungen zwar für das Web entwickelt, aber ihre Programmier- und Testmethoden ließen die besonderen Herausforderungen der Web-Sicherheit unberücksichtigt.

Das ist deshalb problematisch,weil Web-Applikationen ganz bestimmte Sicherheitsanforderungen stellen, die für jemanden, der aus der Client-Server-Welt kommt,nicht offensichtlich sind. Das wird dann deutlich,wenn man das Paradigma der alten Client-Server-Entwicklungsumgebung betrachtet. In den vergangenen Jahrzehnten wurde das Entwicklungs- und Testverfahren für Client-Server-Applikationen ständig verändert, verbessert und verfeinert, was zu sehr widerstandsfähigen Anwendungen führte.Diese Anwendungen bestehen aus Servercode und Clientcode,welche zusammen geschrieben wurden und dazu bestimmt sind, zusammen zu arbeiten.

Dennoch hatte das keinen Einfluss auf die hohen Kosten durch die Inbetriebnahme und Wartung von Client-Server-Applikationen. Um Kosten für Inbetriebnahme und Wartung zu sparen, verlegen Unternehmen einen großen Teil oder sogar alle ihre Anwendungen ins Web.

Dabei wird der Server oft nur geringfügig verändert, während der Client auf eine Web-Oberfläche portiert wird. Damit ist die Inbetriebnahme kostenfrei und die Clients sind plattform unabhängig. Die Unternehmen jedoch sind einem hohen Risiko ausgesetzt, denn der Servercode geht von einem vertrauenswürdigen Client aus, während es sich in Wirklichkeit aber um einen Webbrowser-Client handelt. Das wird dann deutlich,wenn man sich die wichtigsten Unterschiede zwischen den beiden Modellen vergegenwärtigt. Heavy-Client versus Browser Bei zweckgebundenen Heavy-Clients,wie sie in Client-Server-Applikationen verwendet werden, ist ein Reverse-Engineering nur schwer möglich.

Deshalb konnten Hacker Eingaben an den Server nur sehr schwer manipulieren. Ein Beispiel dafür:Wenn auf dem PC eine Software läuft, können die Messages, die an den Server gesendet werden, nicht einfach verändert werden.Denn die Software hat festgelegte Schaltflächen und Widgets, so dass es nicht möglich ist, an den Quellcode heranzukommen und die Befehle, die er generiert, zu manipulieren.

Browser dagegen können sehr leicht manipuliert werden. Der Quellcode auf der Client- Seite ist für jeden über die Internet-Seite zugänglich und veränderbar. So brauchen Anwender beispielsweise nur im Internet-Explorer oder einem anderen Browser auf den Menüeintrag »Quelltext« im Menü »Ansicht« klicken,den Quellcode verändern und dann die Seite erneut laden. Die Manipulation geht sogar so weit, dass einige Hacker-Webseiten Tools wie »Web Proxies «, anbieten, die diese Art der Manipulation automatisieren.

Um die Serverleistung zu verbessern,den Traffic auf dem Netzwerk zu reduzieren und die Anwenderfreundlichkeit zu erhöhen, validieren Client-Server-Applikationen einen großen Teil der Eingaben auf der Client-Seite.Webserver versuchen die Fähigkeiten des Browsers – HTML und Javascript – zur Datenvalidierung zu nutzen, aber der HTML-Code kann verändert und Javascript kann abgeschaltet werden.Mit anderen Worten, alle Validierungen oder Kontrollen, die ein Entwickler im Browser hinterlegen kann, können vom Anwender einfach abgeschaltet oder verändert werden. Damit liegt die gesamte Last der Validierung der Eingaben auf der Server-Seite, und die meisten Entwickler haben einfach nicht die Möglichkeit, jede einzelne Eingabe auf potenziell bösartige Inhalte zu überprüfen.

Dieser Aspekt macht die Web-Applikationen anfällig für Angriffe wie Buffer-Overflow, SQLInjection und Cross-Site-Scripting. Anwender können zum Beispiel die Eingabefelder von Webbasierten Formularen dafür benutzen, einen bösartigen Code einzugeben. Oracle gab vor kurzem bekannt, dass »Oracle Application 11i« – ihre bislang Internet-tauglichste Unternehmenssoftware – mehrere Eingaben unüberprüft durchließ und damit eine Sabotage möglich machte. Ein Online-Auktionshaus entdeckte kürzlich eine besonders gemeine Schwachstelle in seiner E-Commerce-Anwendung: Böswillige Benutzer hatten Auktionen eingegeben, deren Gegenstandsbeschreibungen gefährliche Javascript- Befehle enthielten. Da die Auktionssoftware nicht kontrollierte, was der Benutzer in die Felder für die Gegenstandsbeschreibung eingab, wurden diese Javascript-Befehle an alle übertragen, die die Auktion anklickten.Durch die Ausführung auf ihrem Browser wurden beispielsweise neue Fenster geöffnet und Cookies gestohlen – ein klassischer Angriff durch Cross- Site-Scripting.

Status versus Statuslosigkeit
Ein zweiter Unterschied zwischen Heavy-Client und Browser besteht darin, dass in einer Client- Server-Umgebung eine konstante Sitzung zwischen jedem Benutzer und dem Server hergestellt wird.Wenn sich der Benutzer einmal in die Anwendung einloggt, wird eine Dauerverbindung etabliert, die dem Benutzer alle Informationen bereitstellt. In einer Web-Umgebung gibt es solche Sitzungen nicht; der Benutzer ruft eine Seite auf und verschwindet dann aus dem Blickfeld des Servers, bis eine neue Seite aufgerufen wird.

Das macht die Web-Applikation für viele unterschiedliche Angriffe anfällig.Die häufigste ist Forceful-Browsing – auch Broken-Access- Control genannt. Dieser Angriff besteht darin, vom Webserver einfach Seiten oder Ressourcen anzufordern, für die man eigentlich keine Zugangsberechtigung hat.

Eine weitere inhärente Begrenzung der Statuslosigkeit des Webs liegt darin, dass die Web- Anwendungen irgendetwas im Browser hinterlassen müssen, das die Anwender und die Art der angeforderten Informationen identifiziert, um die Übersicht über die Anwender zu behalten. Wenn der Webserver auf der Seite zum Beispiel ein verstecktes Feld mit einer Information über Preis oder Anwendergruppe hinterlässt, kann man den Quellcode der Seite ansehen, ändern und die Seite erneut an den Server schicken. Die häufigste Methode, die Anwender zu steuern, ist der Einsatz von Session-Cookies. Aber auch hier ist es das Gleiche: Ein Cookie befindet sich auf dem PC, und diese Datei kann daher gefunden, geöffnet und verändert werden.

Es gibt heute zwei Möglichkeiten, mit diesen Bedrohungen umzugehen. Erstens kann man explizite Sicherungen in den Anwendungscode hineinschreiben. Es herrscht kein Mangel an Beratungsunternehmen, die Fortbildungen und Framework für sogenanntes Safe-Coding anbieten. Durch diese werden die Anwendungen sehr viel besser als sie in der Vergangenheit je gewesen sind. Darüber hinaus stellen Plattformen für Anwendungsentwickler weitere Tools zur Verfügung, mit denen die Entwickler beispielsweise Eingaben validieren können, um so eine SQLInjection zu verhindern.Microsoft hat jetzt Web- Form-Validation-Controls auf den Markt gebracht und Java bietet Tools wie Struts mit vergleichbaren Fähigkeiten an.

Allerdings sind diese Tools nur so gut wie die Entwickler, die mit ihnen arbeiten, und sie sind nutzlos, wenn sie nicht eingesetzt werden. Außerdem ist es nicht möglich, einen Code gegen die Schwachstellen zu schreiben.So kann zum Beispiel eine System- oder Konfigurationsdatei, die ungeschützt auf einem Webserver liegt, durch Forceful-Browsing mit einer bekannten oder wahrscheinlichen Adresse aufgerufen werden.

Viele Unternehmen haben Dutzende, wenn nicht sogar Hunderte bereits vorhandener Web- Applikationen, die voller Schwachstellen sind.Ein guter Schritt, um mit der Verbesserung der Anwendungen zu beginnen, ist der Einsatz von Scan- Tools. Produkte wie das »SPI Dynamics’Web- Inspect« helfen bei der Identifizierung von Schwachstellen in Anwendungen sowohl auf dem Plattform- als auch dem Code-Level. Eine ideale Lösung für das Problem wäre es, die Sicherheit auf der Anwendungsschicht einem zentralen Gerät zu überlassen,wo sie leicht verwaltet und überprüft werden könnte. Dieses Gerät würde kostengünstige, leistungsstarke Sicherheit für die Anwendungsschicht gewährleisten und sowohl vor allgemeinen als auch zielgerichteten Angriffen Schutz bieten.

Diese Produkte, so genannte Anwendungs- Firewalls, bestehen aus einem Reverse-Proxy,welcher sich vor den Webservern befindet und der jede Abfrage auf gefährlichen Inhalt oder Forceful- Browsing überprüft und nur legitimierten Traffic auf die nachfolgenden Webserver weiterleitet. Anwendungs-Firewalls können entweder Schwachstellen, die von Scannern wie Webinspect unter Verwendung der Open-Source-Applikation Vulnerability-Description-Language (AVDL) entdeckt werden, abblocken,oder sie erstellen ihren eigenen, anwendungsbezogenen Plan und blockieren alle unbekannten Abfragen. Es gibt natürlich kein Allheilmittel, um das Problem der Verwundbarkeit von Web-Anwendungen zu lösen. Ein vielschichtiger Ansatz ist nötig, einschließlich besserer Codes, engerer Verknüpfung von Entwicklungs- und Sicherheitsinfrastruktur sowie anwendungsbezogener Netzwerkkomponenten, die einen Großteil der Last tragen können.

Fazit

Das Problem der Verwundbarkeit von Web-Applikationen bietet trotz erster vielversprechender Ansätze,wie dem Trafficshield von F5, ernstzunehmende Herausforderungen in puncto Sicherheit. Denn es ist zu befürchten, dass Angriffe auf die Anwendungsschicht immer weiter zunehmen, da die Unternehmen sich auf der Netzwerk- Schicht immer besser absichern und gleichzeitig immer mehr Informationen ins Web stellen. Schon jetzt bieten eine Fülle von Hacker- Webseiten Anleitungen und sogar Shareware- Programme an, um solche Aktivitäten zu erleichtern. Unternehmen müssen im Gegenzug ihre Abwehr ausbauen. So lange sie keine Strategie für die Anwendungssicherheit haben, sind sie nicht sicherer als eine Burg, deren Eingangstor sperrangelweit offen steht.

Alfredo Vistola,
Security Systems Architect,
F5 Networks