Zum Inhalt springen

Apache/14 CGI/2 Konfiguration/2 Aktivieren: Unterschied zwischen den Versionen

Aus Foxwiki
Die Seite wurde neu angelegt: „=== 14.2.1 CGI-Verzeichnisse === Standardmäßig ist die Ausführung von CGI-Skripten in der DocumentRoot einer Website nicht aktiviert. Stattdessen gibt es in der Normalkonfiguration ein separates Verzeichnis, das sich aus Sicherheitsgründen außerhalb des Website-Verzeichnisses befindet. Dieses Verzeichnis wird durch die Direktive ScriptAlias aus dem Modul mod_alias bereitgestellt. ScriptAlias Bildet ein Verzeichnis unter den Verzeichnisbaum der Webs…“
 
K Textersetzung - „z.B.“ durch „beispielsweise“
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=== 14.2.1 CGI-Verzeichnisse ===
=== 14.2.2 CGI in normalen Verzeichnissen aktivieren ===
Standardmäßig ist die Ausführung von CGI-Skripten in der DocumentRoot einer
Die Verwendung spezieller CGI-Verzeichnisse ist nur eine von zwei Möglichkeiten der CGI-Konfiguration. Die andere Methode besteht darin, Dateien mit
Website nicht aktiviert. Stattdessen gibt es in der Normalkonfiguration ein separates Verzeichnis, das sich aus Sicherheitsgründen außerhalb des Website-Verzeichnisses befindet. Dieses Verzeichnis wird durch die Direktive ScriptAlias
bestimmten Endungen allgemein zu CGI-Skripten zu erklären. Beachten Sie, dass
aus dem Modul mod_alias bereitgestellt.
dies aus sicherheitstechnischen Erwägungen nicht die Ideallösung ist. Es handelt
sich meistens um interpretierte Skripte, mindestens aber um ausführbare Programme, deren Funktionalität hinter den Kulissen niemanden etwas angeht.


ScriptAlias
Apache für CGI-Skripte konfigurieren 14.2
Bildet ein Verzeichnis unter den Verzeichnisbaum der Website ab und aktiviert
darin CGI-Skripte.
 
Modul mod_alias
Kontext Server, <VirtualHost>
Syntax ScriptAlias URL-Pfad Dateisystem-Pfad
Standardwert nicht gesetzt
 
Der traditionelle Name des CGI-Verzeichnisses ist cgi-bin. Bei einer normalen
Apache-Installation wird dieses Verzeichnis unter der ServerRoot angelegt und
mit einer Anweisung wie dieser in das htdocs-Verzeichnis abgebildet:
 
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/


Ein Zugriff auf die URL http://www.mynet.de/cgi-bin/skript.pl spricht dann in
Schlimmer: Manche CGI-Skripte enthalten äußerst kritische Informationen wie
Wirklichkeit das Skript /usr/local/apache2/cgi-bin/skript.pl an.
beispielsweise Zugangsdaten für Datenbanken oder geschützte Verzeichnisse.
Wenn Sie diese nicht ausreichend schützen, erleichtern Sie Crackern auf diese
Weise ihr gefährliches Handwerk.


Im Grunde ist diese Direktive nur eine Abkürzung für folgende Schreibweise:
Allerdings kann es einen wichtigen Grund für diese Konfiguration geben: Wenn
Alias /cgi-bin/ /usr/local/apache2/cgi-bin/
Sie Hoster sind und die Websites zahlreicher Kunden als virtuelle Hosts auf Ihren
<Directory "/usr/local/apache2/cgi-bin/">
Server-Rechnern ablegen, gibt es kaum eine andere Möglichkeit, Ihren Kunden
SetHandler cgi-script
den Einsatz von CGI-Skripten zu gestatten. Schließlich greifen die Kunden von
</Directory>
außen auf Ihren Webspace zu, und Sie können es sich aus Sicherheitsgründen
kaum leisten, ihnen den Zugriff auf ein separates CGI-Verzeichnis zu gestatten.
Sind Sie umgekehrt Kunde eines solchen Hosters, dann müssen Sie die ApacheInstallation, auf der Sie Ihre Website im eigenen Netzwerk testen, an diese Besonderheit anpassen.


Bei einem Verzeichnis, das mithilfe der Direktive ScriptAlias eingebunden
Um Dateien in einem bestimmten Kontext CGI-fähig zu machen, müssen Sie die
wird, gelten die enthaltenen Dateien daher automatisch als CGI-Skripte und werden vom Server auch so behandelt. Aus diesem Grund benötigen sie keine spezielle Dateiendung. CGI-Skripte müssen aber stets einige andere spezielle Voraussetzungen erfüllen:
Kerndirektive Options anpassen und die von mod_mime definierte Konfigurationsanweisung AddHandler hinzufügen. Die grundlegende Verwendung dieser beiden
* Auf einem UNIX-System müssen sie als ausführbar für alle Benutzer gekennzeichnet sein. Sie müssen also nach dem Erstellen eines solchen Skripts das
Optionen wurde bereits in Kapitel 6, ''Grundkonfiguration'', beziehungsweise
folgende Dateirecht setzen:
Kapitel 7, ''Header und MIME-Einstellungen'', erläutert.
# chmod a+x skript.pl


Unter Windows entfällt dieser Schritt; diese Art von Dateirechten existiert
Options benötigt für das betreffende Verzeichnis (oder den gesamten Server
hier nicht.
beziehungsweise Virtual Host) die Eigenschaft ExecCGI, die auch in der allgemeinen Optionenliste All enthalten ist. Sie brauchen also bezüglich Options nichts
* Falls es sich um ein interpretiertes Skript handelt, muss dem Webserver mitgeteilt werden, welcher Interpreter für seine Ausführung zuständig ist. Die
mehr zu tun, wenn im gewünschten (oder übergeordneten) Kontext bereits die
traditionelle UNIX-Methode dafür ist die Shebang in der ersten Zeile des
folgende Konfigurationsanweisung gesetzt ist:
Skripts. Sie gibt den vollständigen Pfadnamen des Programms an, z.B.:
#!/usr/bin/perl


Windows kennt diesen Mechanismus eigentlich nicht. Hier entscheidet normalerweise allein die Dateiendung darüber, welches Programm ein Dokument
Options All
oder Skript öffnen soll. Apache benötigt allerdings auch hier die Shebang-Zeile, um die Zuordnung vorzunehmen (es sei denn, Sie ändern die weiter unten
beschriebene spezielle Win32-Konfigurationsdirektive ScriptInterpreterSource). Deshalb ist dies eine der wichtigsten Anpassungen, die Sie an einem
Perl-CGI-Skript vornehmen müssen, das ursprünglich für UNIX geschrieben
wurde.


; Beispiel
Andernfalls müssen Sie ExecCGI zu den bestehenden Optionen hinzufügen.
#!C:/Perl/bin/perl.exe
Angenommen, Sie finden im betreffenden Kontext folgende Anweisung:


Ein kompiliertes, binäres Programm braucht sich natürlich nicht an diese
Options Indexes FollowSymLinks
Regel zu halten, da es für sich selbst ausgeführt werden kann. Solche Programme werden aber in der Praxis eher selten als CGIs eingesetzt, zum einen
 
Apache für CGI-Skripte konfigurieren 14.2


aus Sicherheitsgründen und zum anderen, weil andere Sprachen praktischere
Dann müssen Sie die Direktive folgendermaßen ergänzen:
Hilfsmittel für die CGI-Programmierung enthalten.
* Wie bereits erwähnt, muss sich das CGI-Programm nicht nur um die Erzeugung eines vollständigen (meist HTML-)Dokuments auf der Standardausgabe
kümmern, sondern auch die nötigen HTTP-Antwort-Header selbst generieren.
Die Mindestanforderung ist ein Content-Type-Header mit einem zur Ausgabe
passenden MIME-Type. Hinter den Headern muss bekanntermaßen eine Leerzeile folgen.


Wenn Sie gleich eine ganze Gruppe von Verzeichnissen nach diesem Schema
Options Indexes FollowSymLinks ExecCGI
CGI-fähig machen möchten, können Sie dazu die Direktive ScriptAliasMatch
verwenden.


ScriptAliasMatch
Um nur in einem untergeordneten Kontext, beispielsweise einem speziellen
Bildet eine durch einen regulären Ausdruck beschriebene Gruppe von Verzeichnissen in die Website ab und aktiviert in ihnen CGI-Skripte.
Unterverzeichnis, die CGI-Ausführung zuzulassen, können Sie auch die folgende
Direktive für den entsprechenden Kontext verwenden:


Modul mod_alias
Options +ExecCGI
Kontext Server, <VirtualHost>
Syntax ScriptAliasMatch URL-Pfadmuster Dateisystem-Pfadmuster
Standardwert nicht gesetzt


Um das Verhalten der Standardkonfiguration der Direktive ScriptAlias mithilfe
Diese Schreibweise lässt alle anderen bereits im übergeordneten Kontext gesetzten Optionen unverändert.
von ScriptAliasMatch nachzuahmen, können Sie die folgende Formulierung verwenden:


ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache2/cgi-bin$1
Die AddHandler-Direktive muss die Endungen aller Dateitypen auflisten, die als
CGI-Skripte gelten sollen. Dazu wird für die CGI-Konfiguration folgendes Schema
verwendet:


Diese Verwendung von ScriptAliasMatch bringt zwar keinen praktischen Nutzen, demonstriert aber das Prinzip: Muster, die dem URL-Pfad (erster Parameter)
AddHandler cgi-script .Endung1 [.Endung2 ...]
entsprechen, werden auf den im zweiten Parameter angegebenen Pfad umgesetzt. Geklammerte Ausdrücke aus dem URL-Muster können dabei wie gewohnt
als $1, $2 usw. im Ersetzungsteil verwendet werden. Einen kurzen Überblick über
reguläre Ausdrücke finden Sie in Anhang G.


Hier noch drei praxistauglichere Beispiele:
Wenn Sie beispielsweise Dateien mit den Endungen .cgi und .pl als ausführbare
CGI-Skripte konfigurieren möchten, müssen Sie folgende Anweisung verwenden:


* Angenommen, Sie haben CGI-Skripte für verschiedene Aufgaben und wollen
AddHandler cgi-script .cgi .pl
diese in unterschiedlichen Verzeichnissen ablegen. Die Verzeichnisse heißen
cgi-bin0 bis (maximal) cgi-bin9 und befinden sich unterhalb der ServerRoot.
Natürlich ist es kein Problem, sie mit einzelnen ScriptAlias-Direktiven wie
den folgenden einzubinden:


14 CGI
In der Regel wird diese Direktive einmal für die gesamte Server-Konfiguration
gesetzt. Natürlich steht es Ihnen frei, sie alternativ nur für einzelne Verzeichnisse
oder andere Unterkontexte einzustellen.


ScriptAlias /cgi-bin0/ /usr/local/apache2/cgi-bin0/
Es kann ein erhebliches Sicherheitsproblem sein, diesen Schritt zu vergessen:
ScriptAlias /cgi-bin1/ /usr/local/apache2/cgi-bin1/
Wenn Ihr Server außerhalb der speziellen cgi-bin-Verzeichnisse CGI-Skripte enthält, deren Endungen nicht mittels AddHandler als ausführbar markiert sind, werden diese vom Server im Quelltext ausgeliefert. Warum das so gefährlich ist, wurde bereits erläutert.
[...]
ScriptAlias /cgi-bin9/ /usr/local/apache2/cgi-bin9/


Sehr effizient ist diese Lösung allerdings nicht; außerdem könnte es auch passieren, dass Sie nicht 10, sondern 100 Verzeichnisse auf diese Weise behandeln müssen. Mit einer ScriptAliasMatch-Direktive lässt sich dies in einem
Es gibt noch eine (eigentlich veraltete) Alternative zur Verwendung von
Schritt erledigen:
AddHandler: Sie können die gewünschten Dateiendungen dem MIME-Type
application/x-httpd-cgi zuordnen. Dies erreichen Sie durch eine AddTypeDirektive im gewünschten Kontext, beispielsweise:


ScriptAliasMatch ^/cgi-bin([0-9])/(.*) \
AddType application/x-httpd-cgi .cgi .pl
/usr/local/apache2/cgi-bin$1/$2


* Wenn Sie CGI-Skripte haben, die in mehreren Sprachen geschrieben sind (in
Sie könnten diese Zuordnung stattdessen auch in Ihrer MIME-Type-Datei (durch
diesem Beispiel Perl, Shell-Skripte und binäre C-Programme), möchten Sie
TypesConfig definiert, standardmäßig conf/mime.types) eintragen. Dieser Eintrag sieht beispielsweise so aus:
diese möglicherweise in unterschiedlichen Verzeichnissen wie cgi-perl, cgish und cgi-bin (eben Binaries!) speichern. Mit ScriptAliasMatch lässt sich
dies folgendermaßen erledigen:


ScriptAliasMatch ^/cgi-((perl)|(sh)|(bin))/(.*) \
application/x-httpd-cgi cgi pl
/usr/local/apache2/cgi-$1/$5


* Angenommen, Ihre Website besitzt drei interaktive Bereiche: einen datenbankgestützten Katalog, einen Shop und ein Diskussionsforum. Diese Bereiche befinden sich unter www.mynet.de/katalog, www.mynet.de/shop beziehungsweise www.mynet.de/forum. Jeder dieser Bereiche soll sein eigenes CGIVerzeichnis erhalten; die URLs dieser Verzeichnisse sollen von außen als
Wie Sie sehen, werden die Dateiendungen hier ohne führenden Punkt eingetragen. Zu empfehlen ist dieses Verfahren allerdings nicht, weil sich Änderungen in
www.mynet.de/katalog/cgi-bin usw. angesprochen werden, in Wirklichkeit
der TypesConfig-Datei nur schwer wiederfinden lassen. Nähere Informationen
aber unter der ServerRoot in Verzeichnissen wie cgi-bin/katalog liegen. Das
zur allgemeinen MIME-Type-Konfiguration finden Sie in Kapitel 7, ''Header und
Konzept soll von vornherein verallgemeinert werden – alle URLs nach dem
MIME-Einstellungen''.
Schema www.mynet.de/[a-z]+/cgi-bin sollen in entsprechende CGI-Verzeichnisse umgeleitet werden:


ScriptAliasMatch ^/([a-z]+)/cgi-bin/(.*) \
[[Kategorie:Apache/CGI]]
/usr/local/apache2/cgi-bin/$1/$2

Aktuelle Version vom 28. April 2025, 10:23 Uhr

14.2.2 CGI in normalen Verzeichnissen aktivieren

Die Verwendung spezieller CGI-Verzeichnisse ist nur eine von zwei Möglichkeiten der CGI-Konfiguration. Die andere Methode besteht darin, Dateien mit bestimmten Endungen allgemein zu CGI-Skripten zu erklären. Beachten Sie, dass dies aus sicherheitstechnischen Erwägungen nicht die Ideallösung ist. Es handelt sich meistens um interpretierte Skripte, mindestens aber um ausführbare Programme, deren Funktionalität hinter den Kulissen niemanden etwas angeht.

Apache für CGI-Skripte konfigurieren 14.2

Schlimmer: Manche CGI-Skripte enthalten äußerst kritische Informationen wie beispielsweise Zugangsdaten für Datenbanken oder geschützte Verzeichnisse. Wenn Sie diese nicht ausreichend schützen, erleichtern Sie Crackern auf diese Weise ihr gefährliches Handwerk.

Allerdings kann es einen wichtigen Grund für diese Konfiguration geben: Wenn Sie Hoster sind und die Websites zahlreicher Kunden als virtuelle Hosts auf Ihren Server-Rechnern ablegen, gibt es kaum eine andere Möglichkeit, Ihren Kunden den Einsatz von CGI-Skripten zu gestatten. Schließlich greifen die Kunden von außen auf Ihren Webspace zu, und Sie können es sich aus Sicherheitsgründen kaum leisten, ihnen den Zugriff auf ein separates CGI-Verzeichnis zu gestatten. Sind Sie umgekehrt Kunde eines solchen Hosters, dann müssen Sie die ApacheInstallation, auf der Sie Ihre Website im eigenen Netzwerk testen, an diese Besonderheit anpassen.

Um Dateien in einem bestimmten Kontext CGI-fähig zu machen, müssen Sie die Kerndirektive Options anpassen und die von mod_mime definierte Konfigurationsanweisung AddHandler hinzufügen. Die grundlegende Verwendung dieser beiden Optionen wurde bereits in Kapitel 6, Grundkonfiguration, beziehungsweise Kapitel 7, Header und MIME-Einstellungen, erläutert.

Options benötigt für das betreffende Verzeichnis (oder den gesamten Server beziehungsweise Virtual Host) die Eigenschaft ExecCGI, die auch in der allgemeinen Optionenliste All enthalten ist. Sie brauchen also bezüglich Options nichts mehr zu tun, wenn im gewünschten (oder übergeordneten) Kontext bereits die folgende Konfigurationsanweisung gesetzt ist:

Options All

Andernfalls müssen Sie ExecCGI zu den bestehenden Optionen hinzufügen. Angenommen, Sie finden im betreffenden Kontext folgende Anweisung:

Options Indexes FollowSymLinks

Dann müssen Sie die Direktive folgendermaßen ergänzen:

Options Indexes FollowSymLinks ExecCGI

Um nur in einem untergeordneten Kontext, beispielsweise einem speziellen Unterverzeichnis, die CGI-Ausführung zuzulassen, können Sie auch die folgende Direktive für den entsprechenden Kontext verwenden:

Options +ExecCGI

Diese Schreibweise lässt alle anderen bereits im übergeordneten Kontext gesetzten Optionen unverändert.

Die AddHandler-Direktive muss die Endungen aller Dateitypen auflisten, die als CGI-Skripte gelten sollen. Dazu wird für die CGI-Konfiguration folgendes Schema verwendet:

AddHandler cgi-script .Endung1 [.Endung2 ...]

Wenn Sie beispielsweise Dateien mit den Endungen .cgi und .pl als ausführbare CGI-Skripte konfigurieren möchten, müssen Sie folgende Anweisung verwenden:

AddHandler cgi-script .cgi .pl

In der Regel wird diese Direktive einmal für die gesamte Server-Konfiguration gesetzt. Natürlich steht es Ihnen frei, sie alternativ nur für einzelne Verzeichnisse oder andere Unterkontexte einzustellen.

Es kann ein erhebliches Sicherheitsproblem sein, diesen Schritt zu vergessen: Wenn Ihr Server außerhalb der speziellen cgi-bin-Verzeichnisse CGI-Skripte enthält, deren Endungen nicht mittels AddHandler als ausführbar markiert sind, werden diese vom Server im Quelltext ausgeliefert. Warum das so gefährlich ist, wurde bereits erläutert.

Es gibt noch eine (eigentlich veraltete) Alternative zur Verwendung von AddHandler: Sie können die gewünschten Dateiendungen dem MIME-Type application/x-httpd-cgi zuordnen. Dies erreichen Sie durch eine AddTypeDirektive im gewünschten Kontext, beispielsweise:

AddType application/x-httpd-cgi .cgi .pl

Sie könnten diese Zuordnung stattdessen auch in Ihrer MIME-Type-Datei (durch TypesConfig definiert, standardmäßig conf/mime.types) eintragen. Dieser Eintrag sieht beispielsweise so aus:

application/x-httpd-cgi cgi pl

Wie Sie sehen, werden die Dateiendungen hier ohne führenden Punkt eingetragen. Zu empfehlen ist dieses Verfahren allerdings nicht, weil sich Änderungen in der TypesConfig-Datei nur schwer wiederfinden lassen. Nähere Informationen zur allgemeinen MIME-Type-Konfiguration finden Sie in Kapitel 7, Header und MIME-Einstellungen.