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.
.
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:
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.
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.
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.
