Bedrohungen und Vorgehensmodelle

Als MS-DOS und Windows 3.x noch aktuell waren, wurde eine Anwendung in der Regel auf dem Computer ausgeführt, auf dem sie auch gespeichert war. Im weitreichendsten Fall lief eine Anwendung verteilt über ein lokales Netzwerk. Für einen Angreifer bedeutete dies in der Regel, dass er physikalischen Zugriff auf den Computer benötigte, auf dem die Anwendung installiert war, um diese anzugreifen.

Heute gehören verteilte Anwendungen hingegen zum Alltag: Webapplikationen können auf einem Server irgendwo in der Welt installiert sein und jederzeit und von überall genutzt werden, ohne dass sich der Anwender Gedanken über diesen Umstand machen muss. Das bedeutet aber auch, dass Angreifer irgendwann und von irgendwoher zuschlagen können – der Angriff erfordert keine physikalische Präsenz des Eindringlings mehr.
Durch ihre beständige, allgegenwärtige Verfügbarkeit und die Unterstützung von zahlreichen, teilweise auch anonymen Benutzern bieten Webanwendungen deutlich mehr Angriffsfläche als klassische Applikationen. Erschwerend kommt noch hinzu, dass bei einer Webanwendung ein Angriff auch indirekt erfolgen kann, indem beispielsweise die zugrundeliegende Infrastruktur anstelle der eigentlichen Applikation attackiert wird.

Mögliche Angriffsebenen und -ziele

Auch wenn man als Entwickler von Webanwendungen lediglich Einfluss auf die eigene Applikation und im besten Fall noch auf den oder die Server hat, schadet es nicht, über ein grundlegendes Wissen an Angriffsmöglichkeiten im Internet zu verfügen und ein wenig über den Tellerrand hinauszuschauen, um ein umfassendes Verständnis von den Problemen zu entwickeln.
Betrachtet man also zunächst die möglichen Angriffsziele, ergeben sich drei potentielle Punkte. Zum einen kann die Webanwendung an sich angegriffen werden, indem beispielsweise eine Schwachstelle bei der Authentifizierung oder eine fehlerhafte Funktion ausgenutzt wird. Zum zweiten lässt sich der Server angreifen, um die Ausführung der Anwendung zu beeinträchtigen oder komplett zu verhindern. Zum dritten schliesslich kann ein Angriff auch gegen das umgebende Netzwerk erfolgen, um der Anwendung eine andere Umgebung vorzuspiegeln und dadurch ihr Verhalten zu verändern.

Da an dieser Stelle noch keine technischen Sicherheitslücken besprochen werden, sondern konzeptionelle Schwachstellen, sind diese auch unabhängig von der eingesetzten Technologie und sollten daher nach Möglichkeit bereits beim Entwurf der Webanwendung berücksichtigt werden. Damit das Rad hierbei nicht immer und immer wieder neu erfunden werden muss und sich zudem Standards etablieren, gibt es inzwischen einige Verfahren zur Bedrohungsmodellierung wie beispielsweise STRIDE, das im folgenden näher erläutert wird.
Doch auch bestehende Anwendungen sollten von Zeit zu Zeit immer wieder geprüft und gegebenenfalls besser abgesichert und geschützt werden. Dazu können zum einen die gleichen Verfahren eingesetzt werden wie bei der Konzeption neuer Applikationen, zusätzlich kann auf der technischen Ebene aber auch mit Hilfe von entsprechenden Werkzeugen die Sicherheit geprüft und analysiert werden.

Das «STRIDE»-Modell

Zunächst muss aber die Frage gestellt werden, welche Bedrohungsszenarien überhaupt geprüft werden müssen. Das von Microsoft stammende STRIDE-Modell (zu finden im MSDN, http://msdn.microsoft.com) gibt dazu die folgenden sechs Bedrohungen mit den jeweiligen Abwehrmassnahmen vor:

- Vorgetäuschte Identität (Spoofing Identity): Hierbei täuscht ein Angreifer eine andere, fremde Identität vor, indem er beispielsweise gestohlene Benutzernamen und Kennwörter verwendet, um sich als diesen anderen Benutzer auszuweisen.
Als Abwehrmassnahme ist hier eine durchgängige Authentifizierung zu nennen, so dass innerhalb der Anwendung jederzeit bekannt ist, auf wessen Verantwortung bestimmter Code ausgeführt wird. Ausserdem sollten starke Kennwörter erzwungen und die Zugangsdaten nicht an einem leicht zugänglichen Ort gespeichert werden.




- Datenmanipulation (Tampering with Data): Hier manipuliert der Angreifer Daten, wie beispielsweise in einer Datenbank abgelegte Datensätze, oder Daten, die über ein Netzwerk übertragen werden.
Als Abwehrmassnahme ist hier an aller erster Stelle Lock-down zu nennen, das heisst das Einschränken der Möglichkeiten der betroffenen Software auf das absolute Minimum. Je weniger eine Software kann, desto weniger Angriffspunkte gibt es. Zum zweiten sollte die Anwendung mit minimalen Rechten laufen, so dass jederzeit nur auf die absolut notwendigen Daten zugegriffen werden kann. Ausserdem sollten jegliche Eingaben als «böse» betrachtet werden, bevor ihre jeweilige Gültigkeit geprüft wurde.




- Nichtanerkennung (Repudiation): Bei der Nichtanerkennung gelingt es dem Angreifer, eine nicht erlaubte Aktion in einem System auszuführen, ohne dass dies von anderen Benutzern bemerkt oder nachgewiesen werden kann.
Als Abwehrmassnahmen sind Authententifizierung und Logging zu nennen, so dass jederzeit klar ist, wer welche Aktion in der Anwendung ausführt.




- Enthüllung von Daten (Information Disclosure): Hierbei kann ein Angreifer Daten einsehen, die vor seinem Zugriff geschützt sein sollten.
Die beste Abwehrmassnahme gegen die versehentliche Freigabe von sensitiven Informationen ist, keine sensitiven Informationen zu speichern. An Stelle von Kennwörtern reicht es beispielsweise aus, Hashes der Kennwörter zu speichern. Falls sensitive Informationen wirklich gespeichert werden müssen, sollten diese verschlüsselt sein, und zum Zugriff muss eine starke Authentifizierung eingesetzt werden.




- Verhinderung der Verfügbarkeit (Denial of Service): Hier überlastet der Angreifer eine Webanwendung in der Regel derart, dass sie nicht mehr verfügbar ist und somit ihrer eigentlichen Aufgabe nicht mehr nachgehen kann.
Als Abwehrmassnahmen haben sich Throttling, also das Begrenzen der Anzahl möglicher Verbindungen, sowie das Sperren bekannter IP-Adressen, von denen derartige Angriffe ausgehen, bewährt. Sich gegen eine DoS-Attacke zu wehren, ist äusserst schwierig und erfordert vor allem eine sehr gute Administration der Webanwendung. Stress-Tests können helfen, das Gefahrenpotential besser zu kennen.




- Anheben der Rechte (Elevation of Privilege): Bei der Anhebung der Privilegierung erhält ein Angreifer vom System Rechte zugewiesen, über die er aufgrund seiner Rolle nicht verfügen dürfte.
Als Abwehrmassnahme gegen das Anheben der Rechte ist die Ausführung der Anwendung mit minimalen Rechten zu nennen, so dass der Schaden, den ein Angreifer anrichten kann – wenn er denn schon erhöhte Rechte erhält – möglichst gering bleibt.

Methoden und Vorgehensmodelle

Die Vorgehensweise bei der Planung neuer Anwendungen ist vergleichsweise einfach, die Schwierigkeit besteht darin, Vollständigkeit zu erreichen. Prinzipiell müssen nämlich nur alle Komponenten sowie alle Verbindungen innerhalb und ausserhalb der Anwendung aufgelistet und die potentiellen Bedrohungen zugeordnet sowie ihre Gefährlichkeit eingeschätzt werden. Im nächsten Schritt wird dann überlegt, mit welchen Massnahmen man die Bedrohungen in den Griff bekommen könnte, und schliesslich werden diese Massnahmen entsprechend umgesetzt. Eine umfangreiche Anleitung dazu, die sich natürlich vor allem auf die Microsoft-Welt bezieht, findet sich in Microsofts Developer Network (http://msdn.microsoft.com).
Diese Schritte werden im Verlauf des Projekts immer und immer wieder wiederholt. Damit wird gewährleistet, dass Sicherheit von vornherein mit in die Architektur des Systems eingeplant und nicht im nachhinein als zusätzliche Komponente aufgesetzt wird.

Bestehende Anwendungen können zunächst genauso analysiert werden, indem sie in ihre Komponenten und Verbindungen aufgegliedert und die genannten Schritte wie bei einer neuen, zu planenden Software ausgeführt werden. Zusätzlich können sogenannte Vulnerability-Scanner eingesetzt werden, um Schwachstellen im System zu identifizieren.
Diese gibt es dabei nicht nur auf Anwendungs-, sondern auch auf Serverebene. Als Beispiele sind hier der Microsoft Baseline Security Analyzer (MSBA), der Windows, IIS, SQL Server, Internet Explorer und Office auf fehlerhafte Sicherheitskonfigurationen prüft, sowie Nessus als bekannter Vulnerability-Scanner auf Anwendungsebene zu nennen. Eine Liste von bekannten und bewährten Vulnerability-Scannern findet sich bei insecure.org (http://sectools.org/vuln-scanners.html).

Fazit

Sicherheit in Webanwendungen ist kein Hexenwerk. Sie erfordert aber eine durchdachte Planung und ein ständiges Überprüfen und Anpassen des Sicherheitskonzepts an die eigene Anwendung. Als Faustregel lässt sich sagen, dass Sicherheit desto billiger zu haben ist, je früher man beginnt, sie als integralen Bestandteil einer Anwendung zu sehen. Keinesfalls darf man sie als zusätzliches Feature betrachten, das erst über kurz oder lang eingebaut werden muss.





Bedrohungen und geeignete Abwehrmassnahmen