Sicherheit ist heute eine Notwendigkeit. Sie muss bereits in frühen Entwicklungsstadien einer Software ins Design einbezogen werden und kann kaum später aufgesetzt werden - wenn die Grundlagen einer Anwendung nicht sicher sind, nützen alle später hinzugefügten Sicherheitstechnologien wenig. Dabei kann es nicht schaden, sich in Erinnerung zu rufen, dass es keine wirklich wasserdichte, zu hundert Prozent sichere Software geben kann. Anwendungen sind immer unsicher, die Frage ist bloss, wie unsicher sie sind. Es geht letztlich also nicht darum, Software sicherer, sondern darum, sie weniger unsicher zu machen. Dies gilt umso mehr für Webapplikationen, die gleich auf mehreren verschiedenen Ebenen angegriffen werden können. Dabei handelt es sich hauptsächlich um die folgenden vier Layer:
- Webserver-Ebene: Dieser Layer umfasst nicht nur den eigentlichen Webserver, sondern auch das darunterliegende Betriebssystem. Die Sicherheit auf dieser Ebene ist absolut grundlegend – auch die sicherste Anwendung kann problemlos kompromittiert werden, wenn der Server, auf der sie läuft, angreifbar ist.
-Anwendungs-Ebene (generell): Die generelle Anwendungsebene beinhaltet grundlegende Einstellungen, die für fast jede Webanwendung ähnlich oder identisch sind. Dazu gehören beispielsweise Abfrage-Methoden, Dateizugriffsrechte und ähnliches.
-Anwendungs-Ebene (spezifisch): Auf der spezifischen Anwendungsebene finden sich Vorgänge, die nur für eine bestimmte Webanwendung benötigt werden. Dies könnten in einem E-Commerce-Umfeld beispielsweise Kreditkarten-Transaktionen sein.
-Daten-Ebene: Zur Datenebene schliesslich gehören sämtliche Informationen, die in einer Webanwendung gesammelt und ausgetauscht werden.
Um eine möglichst sichere Webapplikation zu entwickeln, muss jede dieser Ebenen bereits während dem Design-Stadium berücksichtigt werden. Die Unterscheidung von Layern ist dabei hilfreich, indem schrittweise vor-gegangen und jede Ebene einzeln auf ein Minimum an Unsicherheit getrimmt werden kann.
Webserver müssen so konfiguriert werden, dass ihre Angreifbarkeit wirksam minimiert wird. Das beginnt schon bei der Plazierung des Servers im Netz: Ein optimaler Standort ist in einer durch Firewalls geschützten demilitarisierten Zone. Darin sollte der Webserver gemeinsam mit benötigten Zusatzservern wie Applikations- und Datenbankserver, die wiederum über Application-Level-Gateways untereinander und mit dem Webserver verbunden sind, plaziert werden.
Danach gilt es, die zahlreichen potentiellen Schwachstellen der Software durch eine geeignete Konfiguration zu eliminieren. Dafür gibt es wenige feste Regeln, aber zahlreiche Ansatzpunkte. Insbesondere Webserver bieten eine Menge unnötige Angriffsflächen - das beginnt schon bei meist nicht zwingend benötigten, aber dennoch von aussen zugänglichen Diensten wie beispielsweise Telnet. Grundsätzlich sollten alle nicht unbedingt benötigten Serverdienste deaktiviert werden.
Ähnliches gilt für bekannte Schwachstellen, die von Viren oder Würmern gern ausgenützt werden. Sobald Patches für bekannte Löcher in der genutzten Serversoftware veröffentlicht werden, müssen diese sofort installiert werden. Vor der Veröffentlichung von Patches können mitunter Work-arounds den Server provisorisch absichern. Schwachstellen, Angriffspunkte oder Insider-Informationen finden sich aber nicht nur in der eigentlichen Serversoftware, sondern oft auch in Konfigurations- oder Testscripts, die deshalb unmittelbar gelöscht werden sollten, sobald sie nicht mehr zwingend benötigt werden.
Ausserdem sollte in der Server-Konfiguration das Directory-Browsing deaktiviert werden oder pro Verzeichnis zumindest eine Standard-Seite (default.htm) enthalten sein, damit nicht direkt auf die darin enthaltenen Dateien zugegriffen werden kann. Ähnliche Probleme können sich durch veraltete Versionen einer Website ergeben - es ist erstaunlich, wie oft mit der Abfrage nach Verzeichnissen wie /test, /alt oder /archiv auf Daten zugegriffen werden kann, die eigentlich nicht mehr zugänglich sein sollten. Derlei Daten sollten sowohl auf dem Server als auch wenn möglich aus den Verzeichnissen von Suchmaschinen gelöscht werden.
Damit nicht jedermann beliebig Daten verändern kann, ist eine korrekte Rechtevergabe vonnöten. Inhalte sollten einen Besitzer haben, der als Einziger über Schreibrechte verfügt. Besucher dagegen dürfen zwingend nur Leserechte haben. Des weiteren sollte ein Webserver nicht zu ausführliche Fehlermeldungen ausgeben, damit einem Angreifer keine Informationen über die Systemkonfiguration und andere Interna preisgegeben werden.
Genauso wie für die Absicherung von Servern gibt es auch für Anwendungen keine festen Regeln, deren Befolgung garantiert zu mehr Sicherheit führen würden. Vielmehr gibt es einige Richtlinien und Best Practices, die zwar nicht direkt die Sicherheit erhöhen, aber letztlich während der Entwicklung das Bewusstsein für die Sicherheitsproblematik erhalten und so helfen, das Ziel zu erreichen.
Die wichtigste dieser Richtlinien ist sicher, dass nichts als sicher oder vertrauenswürdig gelten darf - solange nicht das Gegenteil bewiesen ist, gelten jede Funktion, jeder Teil der Applikation als unsicher. Es ist dabei sinnvoll, die Anwendung während der Entwicklung mit möglichst restriktiven Berechtigungen auszustatten, weil es einfacher ist, diese später für die Praxis auszuweiten als einzuschränken. Gleichzeitig sollte auch dafür gesorgt werden, dass der Zugriff auf die Anwendung schon von Beginn weg auf die Praxisbedürfnisse eingeschränkt wird.
Grossen Einfluss auf die Sicherheit der fertigen Anwendung hat auch das generelle Vorgehen während der Entwicklung: Sinnvollerweise wird mit sehr kleinen Schritten gearbeitet und jede neue Funktion ausgiebig getestet - auch im Zusammenhang mit den bereits fertigen und «sicheren» Features, da neue Einbauten durchaus auch neue Löcher in bereits getesteten Funktionen aufreissen können. Dies gilt insbesondere auch für fremden Code, den man für bestimmte Funktionen fixfertig aus den zahlreichen Code-Bibliotheken im Internet laden kann - diesen Code-Schnippseln ist im Hinblick auf sichere Anwendungen grundsätzlich nie zu trauen, bevor sie ausgiebig getestet sind.
Nicht zuletzt ist auf einen sinnvollen Umgang mit Daten zu achten. Grundsätzlich ist alles, was vom Anwender an die Applikation geschickt wird, als suspekt einzustufen. Das bedeutet, dass spezielle Validierungs-Mechanismen User-Eingaben oder URLs und ähnliches auf ihre Unverfälschtheit überprüfen müssen.
Der letzte Schritt bei der Entwicklung von sicheren Webanwendungen ist das Testen. Dieser Vorgang sollte keinesfalls unterschätzt werden und benötigt selbst bei weitgehender Automatisierung viel Zeit. Es gilt, auf effektive Weise Angriffsmöglichkeiten zu entdecken und mögliche Löcher zu schliessen. Dabei ist einige Kreativität gefragt, um sich der Denkweise von Angreifern anzupassen und deren Schritte vorwegzunehmen.
Gleichzeitig sollten die Tests möglichst objektiv sein und deshalb nicht vom Programmierer selber durchgeführt werden - dieser kennt zwar den Code und kann dadurch Zeit sparen, er tendiert aber auch eher dazu, potentiell fehlerbehaftete Stellen zu übersehen.
Optimale Platzierung eines Webservers
