Das ist der Alptraum jedes Unternehmens: Über eine harmlose Web-Anwendung auf seiner Homepage, die dem Kunden besseren Service bieten soll, lassen sich völlig andere, überhaupt nicht zur Veröffentlichung gedachte Informationen aus der damit verbundenen Datenbank auslesen.
Wer denkt, es handle sich hierbei um ein konstruiertes Horrorszenario, irrt: Der Computerhersteller Gateway musste Anfang des Jahres am eigenen Leib erfahren, wie real die Bedrohung ist. Die Website des Unternehmens wies jedem registrierten Besucher eine sechsstellige Identifizierungsnummer zu. Anhand dieser Zahl sollte das System den Kunden bei seinem nächsten Besuch wiedererkennen und ihm sogleich die für ihn relevanten Daten anzeigen. Leider ließ sich diese lokal auf dem Anwender-Desktop gespeicherte Nummer verändern, wodurch nicht nur die eigenen, sondern auch Kontodaten anderer Benutzer einsehbar waren. Es war sogar möglich, mit Hilfe eines Skripts alle möglichen Zahlenkombinationen durchzugehen und so die dazu gehörigen Informationen abzurufen.
Pannen wie diese können verschiedene Ursachen haben. Die Quelle des Übels liegt entweder in der fehlerhaften Programmierung der Web-Anwendung, der Backend-Applikation oder dem Zusammenspiel zwischen diesen beiden. Gewiefte Hacker sind dann in der Lage, via Browser Abfragen zu starten und Daten einzusehen, die eigentlich nicht dafür gedacht sind. Maßnahmen zur so genannten Web Application Security (WAS) sollen derlei Angriffe verhindern. Wie die Computing Technology Industry Association (Comptia) unlängst warnte, nimmt die Zahl solcher Attacken zu und könnte aus Sicht der Organisation der "nächste große Alptraum der IT-Security" sein.
Neue Chancen für Hacker
Aus Sicht von Wilfried Schmitz, Chief Technology Officer bei der Ludwigshafener SHE Informationstechnologie AG, ist "Applikationssicherheit ein altes Problem", das Anwender viel zu lange ignoriert hätten. "Bei der Anwendungsentwicklung sind Security-Aspekte eigentlich nie ein Thema gewesen." Dies blieb nur deshalb ohne größere Folgen, weil Unternehmen ihre Systeme in klar begrenzten, abgeschotteten Umgebungen betrieben haben. Brisant wurde das Problem laut Schmitz erst durch den Internet-Hype: "Jeder wollte möglichst schnell online sein. Viele dachten, die Sicherheitszone an der Unternehmensgrenze wird schon ausreichen."
Herkömmliche Schutzmechanismen wie Firewalls greifen bei derartigen Problemen jedoch nicht. Die Angriffe erfolgen auf Applikationsebene über den Browser und somit über die Kommunikationsports 80 (bei Verwendung von HTTP) beziehungsweise 443 (bei HTTPS). Wie Thomas Schreiber, Geschäftsführer des Münchner Sicherheitsunternehmens Securenet GmbH, warnt, weisen herkömmliche Firewalls hier eine größere Lücke auf. Sie seien entweder nicht in der Lage, die Inhalte von Datenübertragungen über diese beiden Schnittstellen ausreichend zu kontrollieren, oder aber die Ports seien schlicht offen.
Löchrige Firewalls
Im Einzelnen gibt es eine ganze Reihe von Angriffsmöglichkeiten, die im Umfeld von Web-Anwendungen vorkommen und ein immenses Sicherheitsrisiko darstellen. Eine gute Orientierung bietet das Open Web Application Security Project (Owasp) mit seiner jährlich aktualisierten Liste der zehn gefährlichsten Fehler. Ganz oben auf der im Januar 2004 erschienenen Aufzählung stehen nicht überprüfte Eingabeparameter, gefolgt von unzureichender Zugriffskontrolle, Fehlern bei der Authentisierung und dem Session-Management, Cross-Site-Scripting, Pufferüberläufen in Anwendungen, Injektions-Fehlern (zum Beispiel SQL-Injection), der falschen Behandlung von Fehlern durch die Web-Anwendung, unsicherer Speicherung, Denial of Service und unsicherem Konfigurations-Management (siehe Kasten "Die zehn gefährlichsten Fehler").
Nicht überprüfte Eingaben sind deshalb riskant, weil Hacker in der Lage sind, jeden Bestandteil eines HTTP-Requests zu manipulieren - dazu gehören auch die URL, Abfrage-Strings oder Formularfelder. Um Missbrauch und Angriffe auf Backend-Anwendungen zu verhindern, sollten Web-Anwendungen daher immer nur Eingaben zulassen, die sinnvoll sind und innerhalb der Erwartungen des jeweiligen Kontexts liegen. Wird beispielsweise eine Postleitzahl abgefragt, dürfen in dem dazugehörigen Feld keine Buchstaben oder Sonderzeichen auftauchen.
Bei unzureichenden Zugriffskontrollen können Hacker Zugriff zu Benutzerkonten erhalten, nicht für sie bestimmte Daten einsehen oder Funktionen nutzen. Ähnliches gilt für unzureichende Authentisierung und Session-Management: Hier besteht die Gefahr, dass ein Hacker - wie im Gateway-Beispiel - über eine manipulierte Session-Information an nicht für ihn bestimmte Informationen gelangt.
Wenn Entwickler nicht sauber definieren, wie und in welchem Umfang Anwendungen den Puffer im Speicher benutzen, kann es hier zu Überläufen, den berüchtigten "Buffer Overflows", kommen. Hacker können diese ausnutzen, um besondere Privilegien zu erhalten und beliebigen Code auf einem Rechner auszuführen oder dessen Steuerung zu übernehmen. Das Owasp warnt, dass Buffer Overflows häufiger in selbst geschriebenen Web-Anwendungen auftauchen, da diese oft weniger intensiv auf mögliche Fehlerquellen untersucht werden als kommerziell verfügbare Lösungen.
Attacken über Browser
Ebenfalls bekannt und äußerst gefährlich sind Injektions-Fehler. Die meisten Web-Applikationen greifen auf weitere Programme und Systeme zurück, um bestimmte Aufgaben zu erfüllen. Hacker nutzen dies aus, um über den Browser Shell-Kommandos oder SQL-Befehle an die Backend-Server oder Datenbanken zu schicken. Die Owasp-Experten warnen, dass sich komplette Skripts in Perl, Python oder anderen Sprachen über unsauber programmierte Web-Anwendungen eingeben und ausführen lassen.
Eine ausführlichere Beschreibung dieser sowie der übrigen WAS-Schwachstellen findet sich in der aktuellen Ausgabe des Owasp-Reports ("The Ten Most Critical Web Application Security Vulnerabilities, 2004 Update"). Er steht im Internet unter http://prdownloads.sourceforge.net/owasp/OWASPTopTen2004.pdf?download zum Herunterladen bereit. Neben den darin beschriebenen Risiken gibt es laut Owasp "viele andere kritische Bereiche, die für die Top-Ten-Liste in Betrachtung gezogen, aber nicht aufgenommen wurden", obwohl auch sie bedeutsame Gefahren für Unternehmen darstellen.
Dazu zählt eine Schwachstelle, von der Daniel Wagner, Berater bei SHE, zu berichten weiß: Demzufolge kommt es zuweilen vor, dass sich Programmierer eine Hintertür im Programm offen lassen, um später darauf zugreifen zu können. Dies ist aus Sicht des Experten äußerst problematisch, weil Hacker diese Schwachstelle ebenfalls ausnutzen können. Hinzu kommt, dass solche Lücken häufig nicht dokumentiert werden.
Unternehmen müssen handeln
Momentan neigen viele Anwender dazu, die Gefahr zu ignorieren. Wie Experte Schmitz berichtet, gibt es zwar Unternehmen, die bereits etwas zur Sicherung ihrer Web-Anwendungen unternommen haben, allerdings seien das erst "sehr wenige".
Er empfiehlt, Web-Anwendungen unbedingt einer Risikoanalyse zu unterziehen. Unternehmen sollten Sofortmaßnahmen zur Absicherung ergreifen, beispielsweise eine Application-Firewall installieren. "Damit lässt sich schon relativ viel reparieren", findet der Spezialist. Diese Vorgehensweise favorisiert auch Securenet-Mann Schreiber: Ein "Web-Shield" überprüft dabei Eingaben durch die Benutzer (zum Beispiel innerhalb von Web-Formularen) auf die korrekte Syntax und ihre Gültigkeit hin, um Fehler zu vermeiden.
Derartige Produkte sind von verschiedenen Herstellern entweder als reine Softwarelösung oder als Appliance erhältlich. "Interdo 3.0" von Kavado beispielsweise erkennt und blockt viele Standardattacken auf Web-Anwendungen, darunter SQL-Injection und Cross-Site-Scripting. "Appshield 4.0" von Sanctum ist eine weitere Lösung, die gängige Schwachstellen in Web-Anwendungen kennt und Versuche abwehrt, diese auszunutzen. Leider sind derartige Produkte nicht ganz billig. Wer sich auf diese Weise absichern will, muss mit Investitionen von 15000 bis 30000 Dollar rechnen.
Doch damit ist es nicht getan. Unternehmen sollten die Quelle des Übels angehen, Fehler im Programmcode suchen und beseitigen. "Das ist die unangenehme Wahrheit", kommentiert Sicherheitsspezialist Schreiber, demzufolge das Beseitigen der Schwachstellen "aufwändig und teuer" ist. Hier hapert es jedoch: SHE zufolge werden inzwischen zwar häufiger Security-Gateways eingesetzt, nur wenige Anwender seien jedoch bereit, den Code durchzusehen.
Branchenriese Microsoft geht hier mit gutem Beispiel voran. Die Redmonder unterziehen seit dem Beginn ihrer "Trustworthy-Computing"-Initiative ihre gesamte Software einer strengen Prüfung auf mögliche Programmierfehler. Der Hersteller hat überdies angekündigt, ein spezielles Tool zur Überprüfung von Code auf Security-Schwachstellen zum festen Bestandteil der nächsten Version des Entwicklungswerkzeugs "Visual Studio.NET" zu machen. Anwender können dies einsetzen, um selbst entwickelte Programme einem Sicherheitscheck zu unterziehen.
Dieses Vorgehen ist jedoch nicht nur während der Entwicklung, sondern auch nach der Fertigstellung einzelner Komponenten oder Softwarefunktionen zu empfehlen. Denn gerade im Zusammenspiel verschiedener, womöglich von unterschiedlichen Programmierern geschriebener Bestandteile können Fehler auftreten, die aktuell zu verarbeitende Daten, das System und schließlich die Sicherheit des kompletten Unternehmens gefährden. Daher sollte auch vor dem Rollout eine intensive Testphase eingeplant werden.
Hersteller wie Fortify ("Source Code Analyser"), Sanctum ("Appscan") oder Spidynamics ("Webinspect") bieten Lösungen, um Unternehmen bei dieser mühsamen Arbeit zu unterstützen. Fortifys Source Code Analyser soll beispielsweise in der Lage sein, in Java oder C++ geschriebenen Sourcecode schon während der Entwicklung auf mögliche Sicherheitslecks hin zu untersuchen. Diese Programme sind nicht zu verwechseln mit Debugging-Tools, die Code unter anderem daraufhin mustern, ob die Programmiersyntax fehlerfrei ist, so dass Programme absturzfrei laufen. Stattdessen kontrollieren sie, an welcher Stelle eines Programms ein Entwickler eine potenziell unsichere Funktion benutzt.
Der Einsatz eines solchen Software-Scanners gibt jedoch keine 100-prozentige Sicherheit. SHE-Mann Schmitz warnt, dass auch diese Lösungen "Fehler haben oder an einer bestimmten Abzweigung eines Programms aussteigen können". An einer manuellen Überprüfung des Codes führe daher kein Weg vorbei. Fachmann Schreiber weist zudem darauf hin, dass es nicht mit einmaligen Überprüfungen getan ist: Vielmehr müsse die Sicherheit von Web-Anwendungen bei jeder Änderung aufs Neue getestet werden.
Fazit
Ein für alle Mal zu lösen ist das Problem aus Sicht von Schmitz nicht: "Es wird immer unsichere Altlasten geben, die weiterbenutzt werden müssen und die sich nicht von heute auf morgen abschalten oder überarbeiten lassen."
Zehn Fehler
1. Nicht überprüfte Eingabeparameter,
2. Unzureichende Zugriffskontrolle,
3. Fehler bei Authentisierung und Session-Management,
4. Cross-Site-Scripting,
5. Pufferüberläufe,
6. Injection-Fehler (zum Beispiel SQL-Injection),
7. Falsche Fehlerbehandlung durch die Web-Anwendung,
8. Unsichere Speicherung,
9. Denial of Service,
10. Unsicheres Konfigurations-Management.
Quelle: Owasp