entwickler.com

In dieser Folge von About Security erfahren Sie, wie es mit der Sicherheit der den Webanwendungen zugrunde liegenden Webserver bestellt ist.

Nicht behobene Schwachstellen

Veraltete Versionen des Betriebssystems und/oder des Webservers enthalten bekannte Schwachstellen. Einige Würmer, zum Beispiel Code Red, Nimda oder Slapper nutzten solche Schwachstellen zur Verbreitung. Patches für Schwachstellen bzw. Updates, die Schwachstellen beseitigen, müssen bei Verfügbarkeit schnellstmöglich installiert werden. Bis zur Verfügbarkeit von Patches können manchmal Workarounds die Gefahr mindern.

Unnötige Angriffsflächen

Nicht benötigte Dienste auf dem Webserver, die von außen zugänglich sind, bieten eine unnötige Angriffsfläche. Dies trifft insbesondere auf telnet zu. Da telnet die Daten ungeschützt überträgt, sollte, wenn nötig, stattdessen sowieso ssh verwendet werden. Generell sollten alle nicht zwingend benötigten Dienste deaktiviert werden, d.h. wenn kein Fernzugang benötigt wird, darf auch kein telnet/ssh-Server laufen.

Vergessene Programme und Skripts

Nicht entfernte Konfigurations-, Beispiel- und Testskripts bzw. -programme können von Angreifern für ihre Zwecke missbraucht werden. So enthält das oft im Verzeichnis cgi-bin enthaltene Skript formmail.pl in verschiedenen Versionen Schwachstellen, die zum Versand von Spam oder zur Ausführung beliebiger Befehle ausgenutzt werden können.

Aufgelistete Verzeichnisse

Verzeichnisse ohne Default-HTML-Seite zeigen ihren kompletten Inhalt an, sodass auf nicht verlinkte Dateien zugegriffen werden kann. Die Manipulation der Pfade in einem URL ist bekanntlich kein Problem, sodass jedes beliebige Verzeichnis auf dem Webserver angesprochen werden kann.

Ungeschützte Versionen der Website

Veraltete Versionen oder Testversionen, die nicht verlinkt sind, können abgefragt werden, wenn die entsprechenden Verzeichnisse nicht geschützt sind. Die Suche nach Verzeichnissen wie /archiv, /alt, /test, ... führt sehr oft zum Erfolg. Auch Suchmaschinen listen oft Pfade auf, die auf dem Webserver nicht mehr verlinkt sind. Daten, die über den Webserver nicht mehr abgefragt werden sollen, sollten gelöscht werden. Alternativ können die entsprechenden Verzeichnisse durch den Webserver vor unbefugten Zugriffen geschützt werden.

Schutz der Inhalte

Alle Daten, insbesondere die Webseiten, müssen einem dafür vorgesehenen Benutzer gehören und dürfen nur von diesem zu schreiben sein. Dies verhindert, dass ein Unbefugter Daten ändert oder löscht. Der Webserver muss unter einem anderen Benutzer laufen, der nur lesend auf die Daten zugreifen darf. So kann ein Angreifer, der über eine Schwachstelle in den Server eindringt und die Rechte des Webservers erlangt, keine Änderungen an den Daten vornehmen.

Ausnutzen von Fehlermeldungen

Ausführliche Fehlermeldungen helfen einem Angreifer, Informationen über das System zu erhalten. Einige Beispiele: Aus Versionsnummern kann auf vorhandene Schwachstellen geschlossen werden, vollständige Pfade helfen bei der Durchführung von Directory-Traversal-Angriffen. Benutzernamen, die z.B. bei Datenbankfehlern ausgegeben werden, können zum Ziel von Brute-Force-Angriffen werden, wenn der Angreifer eine Möglichkeit zum Zugriff auf das System bekommt. Produktiv eingesetzte Systeme sollten daher keine ausführlichen Fehlermeldungen ausgeben, sondern diese in Log-Dateien speichern. Dem Benutzer reicht die Information, dass ein Fehler aufgetreten ist. Die Details sind für ihn von geringem Interesse. Viel wichtiger ist ein Hinweis, wie er nun weiter verfahren soll. Und damit ist kein Hinweis "Bitte notieren Sie die lange, unverständliche Fehlermeldung und senden Sie sie an den Webmaster" gemeint. Erstens macht das sowieso niemand, zweitens liest sich das wie "Wir haben keine Ahnung, was hier wie funktioniert".

Speicherung vertraulicher Daten in zugänglichen Verzeichnissen

Eine weitere häufig auftretende Schwachstelle sind in für den Webserver zugängliche Verzeichnisse gespeicherte Dateien mit vertraulichen Daten. Werden Dateien unterhalb des Document Root gespeichert, können sie über eine URL abgerufen werden. Besonders häufig tritt dies Problem bei virtuellen Webservern auf, bei denen die Wurzel des Kundenververzeichnisses (z.B. /home/www/server/kunde, für den Kunden "/") gleichzeitig die Wurzel des virtuellen Servers ist (z.B. http://www.kunde.example): Alle unterhalb des Wurzelverzeichnisses des Kunden gespeicherte Dateien liegen auch unterhalb des Document Root und sind daher durch den Webserver abrufbar. Zur Beseitigung des Problems gibt es zwei Möglichkeiten: Liegt der Document Root des Webservers tiefer als die Wurzel des Kundenververzeichnisses (z.B. /home/www/server/kunde/www), können weitere Verzeichnisse oberhalb des Document Root angelegt (z.B. /home/www/server/kunde/geheim) und vertrauliche Daten darin gespeichert werden. Alternativ können Verzeichnisse mit vertraulichen Daten durch den Webserver vor Zugriffen über HTTP geschützt werden.

Außer der Beseitigung von Schwachstellen in Konfiguration und Software hat auch die Wahl des richtigen Standorts Auswirkungen auf die Sicherheit des Webservers. In der nächsten Folge werden einige mögliche Standorte und die damit verbundenen Vor- und Nachteile vorgestellt.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver