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