Sie befinden sich hier: Themen IT-Grundschutz-Kataloge. Inhalt. Dokumententitel: M 4.197 Servererweiterungen für dynamische Webseiten beim Apache-Webserver - IT-Grundschutz-Kataloge - Stand 2006
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

M 4.197 Servererweiterungen für dynamische Webseiten beim Apache-Webserver

Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement

Verantwortlich für Umsetzung: Administrator

Der Apache-Webserver bietet viele Möglichkeiten für die Realisierung dynamischer Webseiten. Diese sind über Erweiterungsmodule realisiert. In der Quelltext-Distribution des Apache-Webservers sind beispielsweise folgende Module enthalten:

Bei der Ausführung von Programmen über die Schnittstellen CGI, SSI und ISAPI werden diese prinzipiell mit den Berechtigungen des Apache-Webservers ausgeführt. Dies führt zu einer Reihe von Problemen, da der Apache-Webserver mit möglichst wenig Berechtigungen ausgestattet sein sollte. Um diese grundsätzliche Einschränkung zu umgehen, existiert das Modul mod_suexec, das die Ausführung von Programmen unter einer anderen Benutzerkennung als der des Apache-Webservers erlaubt.

Neben den Modulen aus der Apache-Distribution selbst existiert eine große Zahl weiterer Module, mit denen sich dynamische Webseiten realisieren lassen. Teilweise werden diese Module von Projekten entwickelt, die ebenfalls unter dem Dach der Apache Software Foundation (ASF) arbeiten, teilweise von unabhängigen Projekten oder kommerziellen Anbietern. Einige verbreitete Beispiele sind

Da sich Arbeitsweise, Möglichkeiten und Probleme der einzelnen Module stark unterscheiden, kann im Rahmen dieser Maßnahme nicht auf alle Aspekte eingegangen werden, sondern es werden lediglich einige grundlegende Hinweise gegeben. Administratoren und Entwickler dynamischer Webseiten müssen sich daher in jedem Fall gründlich mit den Sicherheitsaspekten des jeweils gewählten Erweiterungsmoduls beschäftigen.

Prinzipiell müssen die Dateien des jeweiligen Erweiterungsmoduls genau so vor unbefugtem Zugriff geschützt werden, wie die Dateien des Apache-Webservers selbst. Dies gilt sowohl für die ausführbaren Dateien, die meist im Bibliotheksverzeichnis des Apache-Webservers abgelegt sind, als auch für etwa vorhandene Konfigurationsdateien wie beispielsweise die Datei php.ini bei der Verwendung von mod_php.

Für Programme, die über den cgi-Mechanismus ausgeführt werden, kann in der Datei httpd.conf mit der Direktive ScriptAlias ein Verzeichnis angegeben werden, in dem die Programme vom Webserver gesucht werden. Dieses Verzeichnis sollte in jedem Fall außerhalb des normalen WWW-Dokumentenbaums gewählt werden. Beispiel:

Dateien innerhalb des WWW-Dokumentenbaums sollten grundsätzlich (zumindest für den Apache-Webserver) nicht ausführbar sein, das heisst mit den Mitteln des jeweiligen Betriebssystems sollte für den Benutzeraccount des Apache-Webserver das Ausführungsrecht für diese Dateien entfernt werden.

Die Grundregel für die Entwicklung dynamischer Webseiten, bei denen Informationen verarbeitet werden, die von außen über den Webserver an das jeweilige Programm übergeben wurden, ist, dass diese Eingaben niemals ungefiltert im Programm verwendet werden dürfen, sondern stets vor ihrer Verwendung mit einer geeigneten Funktion "bereinigt" werden sollten. Dies muss bei der Programmierung stets berücksichtigt werden.

Die Skriptsprache Perl bietet darüber hinaus den sogenannten taint-Modus, in dem Daten, die von außen kommen, für bestimmte Funktionsaufrufe nicht zugelassen sind. Werden cgi-Skripte in Perl geschrieben, so sollten sie stets im taint-Modus ausgeführt werden.

Diese Regel gilt selbst dann, wenn es sich nicht um Eingaben handelt, die Benutzer direkt in ein Eingabeformular eingeben, sondern nur um solche Informationen, die über Auswahllisten übergeben wurden. Nicht einmal Eingaben, die bei der Erzeugung der "absendenden" Webseite vom Programm selbst als "versteckte Parameter" in die Webseite eingebettet wurden, dürfen direkt übernommen werden. Da HTML-Seiten auf der Client-Seite im Klartext vorliegen und über das Klartext-Protokoll HTTP übertragen werden, können alle Daten und Eingaben entweder auf dem Client-Rechner oder bei der Übertragung beliebig manipuliert werden.

Dynamische Webseiten werden meist so realisiert, dass in einer Datei HTML-Code und Anweisungen der jeweils verwendeten Programmiersprache vermischt sind. Bei der Verarbeitung einer Anfrage werden dann die Anweisungen vom jeweiligen Modul ausgeführt und die Ausgaben der betreffenden Programmfunktionen in die HTML-Seite eingebettet, die an den Client geschickt wird. Eine andere Möglichkeit ist es, dass ein weiteres Programm ausgeführt wird, welches als Ausgabe eine vollständige HTML-Seite erzeugt.

Beim Design dynamischer Webseiten sollte darauf geachtet werden, dass Programmcode und HTML-Code möglichst gut voneinander getrennt werden. Sofern das verwendete Modul diese Möglichkeit bietet sollte Programmcode am besten gar nicht direkt in der HTML-Seite enthalten sein, sondern nur über einen Verweis auf eine entsprechende Datei eingebettet werden. Dies erlaubt eine bessere Rollentrennung zwischen dem graphischen Design der Webseiten und der Programmierung.

In keiner Datei, die sich im "öffentlich zugänglichen" Bereich des Webservers befindet, dürfen in "Skript-Komponenten" Zugangsdaten für den Zugriff auf Datenbanken oder ähnliches stehen. Wird für die Realisierung von dynamischen Seiten der Zugriff auf Datenbanken benötigt, so muss dies so implementiert werden, dass Zugangsdaten außerhalb des WWW-Dokumentenbaums vorgehalten werden.

Als zusätzlicher Schutz sollte mit entsprechenden Apache-Direktiven dafür gesorgt werden, dass Dateien, die typischerweise Konfigurationsdateien sind, nicht ausgeliefert werden. Beispielsweise kann mit

die Auslieferung von Dateien mit den Endungen .conf und .cnf verboten werden. Die Liste der so verbotenen Dateitypen sollte jeweils an die konkreten Gegebenheiten angepasst werden.

Ergänzende Kontrollfragen: