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: Erst Anfang Februar 2009 konnten die Kunden von 1&1 auf die Verbindungsdaten anderer Nutzer zugreifen. Dazu genügte es, nach dem Login die eigenen Daten aufzurufen und anschließend in der URL die Rechnungs-ID zu ändern. Mehr zu dieser Datenpanne lesen Sie in unserem Artikel Massives Datenleck bei 1und1.
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 für sie gedacht sind. Maßnahmen zur so genannten Web Application Security (WAS) sollen derlei Angriffe verhindern. Wie die Computing Technology Industry Association (Comptia) ständig warnt, nimmt die Zahl solcher Attacken zu und könnte aus Sicht der Organisation zum Alptraum der IT-Security werden.
Neue Chancen für Hacker
Aus Sicht von Wilfried Schmitz, Chief Technology Officer bei der Ludwigshafener SHE Informationstechnologie, 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, 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.
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 Liste der zehn gefährlichsten Fehler. Ganz oben auf der 2007 erschienenen Aufzählung stehen Cross Site Scripting und Injection-Fehler, allen voran SQL-Injection. Auf Platz vier findet sich dort übrigens der nicht überprüfte direkte Objektzugriff über eine Referenznummer, wie bei 1&1 geschehen.
Häufige Fehler
Nicht überprüfte Eingaben und Anforderungen sind stets 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 1&1-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 Speicherbereiche benutzen dürfen, 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.
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.
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 einiges zur Sicherung ihrer Web-Anwendungen unternommen haben. Allerdings gibt es in vielen Bereichen noch zu wenig Know-how, um die Risiken zu erkennen und abzuwehren.
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. 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.
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.
Fazit
Software-Scanner sollen bei dieser mühsamen Arbeit unterstützen. Sie sollen den Sourcecode schon während der Entwicklung auf mögliche Sicherheitslecks hin 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.
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." (ala)