Hohe Hürden gegen Angreifer

Eine Grundregel lautet, sich nicht auf «Security by obscurity» zu verlassen (siehe InfoWeek 9/07). Das heisst, dass es theoretisch bedenkenlos möglich sein sollte, alle Implementierungsdetails einer Anwendung offenzulegen, ohne damit ein Sicherheitsrisiko einzugehen. Dennoch ist es ratsam, einem Angreifer diesbezüglich so wenige Informationen wie möglich zuzuspielen, um einen Angriff so schwierig wie möglich zu machen.
Gelingt es einem Angreifer beispielsweise, herauszufinden, auf welchem Betriebssystem mit welcher Umgebung eine Webanwendung läuft, kann er gezielt Sicherheitslücken dieses Systems ausnutzen, um einen Angriff durchzuführen. Ähnliches gilt für eingesetzte Algorithmen: Zwar steigt die Erfolgsquote eines Angriffs auf eine RSA-Verschlüsselung nicht, wenn man weiss, dass RSA eingesetzt wird, aber der Angreifer kann mit diesem Wissen wesentlich gezielter versuchen, Schwachstellen zu finden.
.

Es gilt also, so wenige Details wie möglich nach aussen zu geben. Dies hört sich zunächst einfacher an, als es tatsächlich ist, da zahlreiche Webanwendungen Schnittstellen zur Konfiguration und Administration der Anwendung sowie des dazugehörigen Systems anbieten. Da auf diese in der Regel nicht verzichtet werden kann, müssen sie so gut wie möglich abgesichert werden, um einen Angriff auf dieser Ebene zu verhindern.

Konfigurationsverwaltung

Da über Administrationsschnittstellen und Konfigurationsoberflächen, die über das Web verfügbar sind, in der Regel systemrelevante Parameter eingestellt werden können, könnte ein Angreifer eine Webanwendung oder unter Umständen sogar den gesamten Server lahmlegen, indem er einige Parameter gezielt verändert.
Daher sollte es von diesen Administrationsschnittstellen so wenige wie möglich geben. Bietet eine Anwendung die Konfiguration auf verschiedene Arten an, so sollten nach Möglichkeit all jene deaktiviert werden, die nicht zwingend erforderlich sind. Idealerweise wird gar keine Schnittstelle direkt über das Web angeboten, sondern statt dessen ein Zugang über SSL oder ein Virtual Private Network eingerichtet.
Ausserdem sollte darauf geachtet werden, zur Authentifizierung nur ausreichend sichere Verfahren einzusetzen wie beispielsweise Zertifikate. Es gilt also:



- Bieten Sie so wenige Schnittstellen wie möglich an und sichern Sie diese wenn möglich via SSL oder VPN.
Des weiteren ist es ratsam, nicht nur den Zugriff auf den Konfigurationsspeicher gegen Angriffe zu sichern, sondern auch den Konfigurationsspeicher an sich zu schützen. Zum einen bedeutet dies, den Webserver so zu konfigurieren, dass er den Zugriff von aussen auf Konfigurationsdateien wie beispielsweise Web.Config und Machine.Config verhindert.
Zum anderen sollten solche Dateien nach Möglichkeit an einem Ort ausserhalb des Anwendungsverzeichnisses abgelegt werden. So bietet es sich in PHP beispielsweise an, Include-Dateien in einem gesonderten Ordner zu speichern, der nicht über den normalen Pfad aus dem Web erreichbar ist. Das führt zu den Regeln:

- Konfigurieren Sie den Webserver so, dass er Konfigurationsdateien nicht ausliefert.



- Legen Sie Konfigurationsdateien ausserhalb des Anwendungsverzeichnisses ab.



Um zu verhindern, dass Schaden entsteht, sollte eine solche Datei dennoch in die Hände eines Angreifers fallen, ist es zudem ratsam, die enthaltenen Konfigurationseinstellungen nicht als Klartext, sondern verschlüsselt abzulegen. Beispielsweise ASP.NET bietet für die Konfigurationsdatei Web.Config entsprechende Möglichkeiten an.



- Verschlüsseln Sie Einstellungen in Konfigurationsdateien, statt diese im Klartext abzulegen.



Um im Falle des Falles nachvollziehen zu können, wer welche Veränderungen an einer Konfigurationsdatei vorgenommen hat, müssen sämtliche Informationen darüber protokolliert werden. Das heisst insbesondere, dass jeder Benutzer, der über administrativen Zugriff verfügt, ein eigenes Konto besitzen muss, und dass auch – und insbesondere – diese Konten möglichst umfangreich überwacht und deren Aktivitäten protokolliert werden.
Eine einfache Möglichkeit, Änderungen an Konfigurationsdateien zu überwachen und diese gegebenenfalls auch wieder rückgängig machen zu können, ist, sie in einer Versionskontrolle wie Subversion oder Team Foundation Server zu verwalten. Dadurch wird zudem sichergestellt, dass jeder Zugriff protokolliert wird.
Ausserdem sollten alle administrativen Konten genauso wie Prozess- und Dienstkonten immer mit den geringstmöglichen Privilegien ausgestattet sein, um zu verhindern, dass mit einem gekaperten Konto das gesamte System kompromittiert werden kann. Ein Beispiel für die Umsetzung dieser geringstmöglichen Privilegien ist die User Account Control von Windows Vista. Insgesamt gilt also:



- Jeder Benutzer mit administrativem Zugriff benötigt ein eigenes Konto.



- Administrative Konten müssen überwacht und protokolliert werden.



- Kein Konto darf über mehr Berechtigungen als absolut notwendig verfügen.

Ausnahmeverwaltung ist zwingend

Ein von Angreifern häufig genutzter Weg, um sensible Daten über eine Webanwendung und das ihr zugrundeliegende System zu erhalten, ist die Provokation von Fehlern. Werden Ausnahmen im Code der Anwendung nicht korrekt gefangen und entsprechend behandelt, wird dem Angreifer unter Umständen eine ausführliche Systemfehlermeldung übermittelt, aus deren Details er relevante Informationen erhalten kann.
Informationen, die in der Regel durch diesen unsicheren Umgang mit Fehlerseiten bekannt werden, sind beispielsweise Datenbank- und Tabellennamen, SQL-Abfragen, Verbindungszeichenfolgen und ähnliches. Als Folge davon verfügt der Angreifer über genaue Details der Implementierung, die er darauf gezielt ausnutzen kann.
Zudem müssen alle Ausnahmen protokolliert werden, um im Falle eines Angriffs in einer Analyse ermitteln zu können, über welche Daten der Angreifer verfügt. Die Regeln für Ausnahmen und Fehlerbehandlung lauten also:



- Sämtliche Ausnahmen müssen vom Code abgefangen und behandelt werden.

- Dem Endbenutzer werden keine systeminternen Daten angezeigt.



- Alle Ausnahmen müssen protokolliert werden.



Darüber hinausgehend muss zwingend darauf geachtet werden, dass die Systemstabilität durch eine nicht behandelte Ausnahme unter Umständen gefährdet werden könnte. Ausser der Gefahr, dass die Anwendung selber kompromittiert wird, kann ein Angreifer auf diese Art beispielsweise auch einen Denial-of-Service-Angriff durchführen, auf Grund dessen die Anwendung anderen Benutzern nicht mehr zur Verfügung steht.
Um solche Angriffe zu vermeiden, bietet es sich zum einen an, sämtliche Benutzereingaben auf ihre Gültigkeit zu überprüfen, zum anderen aber auch, alle Ausnahmen im Code zu behandeln. Die Regeln zur Vermeidung eines möglichen Denial-of-Service-Angriffs lauten also:



- Misstrauen Sie grundsätzlich allen Benutzereingaben.



- Alle Ausnahmen müssen vom Code behandelt werden.

Überwachen und Protokollieren

Die Überwachung und Protokollierung sämtlicher sicherheitsrelevanter Aktivitäten hat neben der Nachvollziehbarkeit und der Informationssammlung im Falle eines Angriffs noch einen weiteren Zweck: Aus der Analyse dieser Daten lassen sich unter Umständen Anzeichen auf einen bevorstehenden Angriff erkennen, so dass präventiv eingegriffen werden kann und potentiell aufgedeckte Schwachstellen geschlossen werden können.
Verzichtet man auf eine derartige umfassende Protokollierung, kann sich gleich eine ganze Reihe von Problemen ergeben. An erster Stelle steht die Beweisbarkeit, dass ein gegebener Benutzer eine bestimmte Aktion tatsächlich durchgeführt hat. Existiert kein umfassendes Protokoll der Benutzeraktivitäten, kann ein möglicher Täter die Durchführung von Vorgängen abstreiten. Die umzusetzenden Direktiven heissen:



- Jeder Benutzer verfügt über ein eigenes Konto.

- Sämtliche sicherheitsrelevanten Ereignisse auf dem Web-, dem Datenbank- und dem Applikationsserver müssen protokolliert werden.



Protokolle sind allerdings nur dann hilfreich, wenn sie auch für eine Analyse genutzt werden. Daher sollten Protokolle möglichst regelmässig, am besten täglich, auf verdächtige Ereignisse überprüft werden.
Ausserdem sollten Protokolle aufbewahrt und unbedingt in das Backup eingeschlossen werden, um längerfristige Angriffe erkennen und im schlimmsten Fall noch auf eine Kopie der Protokolle zugreifen zu können.
Schliesslich muss der Zugriff auf die Protokolldateien an sich ebenfalls gesichert werden, denn das beste Protokollierungsverfahren nützt nur dann etwas, wenn es dem Angreifer nicht gelingen kann, die Protokolle unbrauchbar zu machen. Daher bietet es sich an, die Protokolldateien in einem anderen als dem Standardverzeichnis abzulegen und den Zugriff auf sie nur gewissen Konten zu gestatten.



- Überprüfen Sie Protokolle regelmässig.



- Bewahren Sie Protokolle auf und nehmen Sie sie in das Backup mit auf.



- Schützen Sie den Zugriff auf die Protokolldateien.

Fazit

Die Sicherheit einer Webanwendung steht und fällt mit der Sicherheit jeder einzelnen Komponente. Bedrohungen sind dabei so vielfältiger Natur, dass sich letztendlich gar nicht sämtliche Angriffsmöglichkeiten einzeln aufzählen lassen. So dienen auch die Tips und Tricks, die in diesem und den vorangegangenen Artikeln vorgestellt wurden, nur als Richtlinie, nicht als Katalog der absoluten Sicherheit. Selbst wenn alle genannten Risiken berücksichtigt wurden, so können nach wie vor Sicherheitslücken bestehen. Dessen sollte man sich jederzeit bewusst sein: Absolute Sicherheit gibt es nicht und wird es nie geben.
Dennoch kann man zahlreiche der heute bekannten Bedrohungen dadurch abwehren, dass man die genannten Punkte bei der Entwicklung berücksichtigt. Wer das macht, kann bereits einem Grossteil der einfach gestrickten Angriffe entgehen. Einem Angreifer werden dann deutlich mehr Steine in den Weg gelegt, und der Aufwand steigt, womit gleichzeitig die Attraktivität des Ziels unter Umständen sinkt.
Insgesamt lässt sich trotzdem eines feststellen: Sämtliche noch so ausgefeilten Techniken können immer nur davor schützen, was an Angriffen bekannt ist. Angreifer schlafen nicht, sie sind kreativ, um neue Sicherheitslücken aufzudecken und diese auszunutzen. Und genau davor schützt nur stetige Wachsamkeit, aktives Mitdenken und Hinterfragen von Verfahrensweisen und Techniken. Wer diesen Aufwand in Kauf nimmt, kann guten Gewissens sagen, dass er gut vorgesorgt hat.