Bedrohungen und Vorgehensmodelle

ITMAGAZINE
Bedrohungen und Vorgehensmodelle
30. März 2007 - Die weltweite Vernetzung eröffnet Sicherheitsrisiken und Angriffs-möglichkeiten, gegen die
Webapplikation gesichert werden müssen. 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
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
Copyright by Swiss IT Media 2017