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…“
 
Keine Bearbeitungszusammenfassung
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/
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.


Ein Zugriff auf die URL http://www.mynet.de/cgi-bin/skript.pl spricht dann in
Allerdings kann es einen wichtigen Grund für diese Konfiguration geben: Wenn
Wirklichkeit das Skript /usr/local/apache2/cgi-bin/skript.pl an.
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.


Im Grunde ist diese Direktive nur eine Abkürzung für folgende Schreibweise:
Um Dateien in einem bestimmten Kontext CGI-fähig zu machen, müssen Sie die
Alias /cgi-bin/ /usr/local/apache2/cgi-bin/
Kerndirektive Options anpassen und die von mod_mime definierte Konfigurationsanweisung AddHandler hinzufügen. Die grundlegende Verwendung dieser beiden
<Directory "/usr/local/apache2/cgi-bin/">
Optionen wurde bereits in Kapitel 6, »Grundkonfiguration«, beziehungsweise
SetHandler cgi-script
Kapitel 7, »Header und MIME-Einstellungen«, erläutert.
</Directory>


Bei einem Verzeichnis, das mithilfe der Direktive ScriptAlias eingebunden
Options benötigt für das betreffende Verzeichnis (oder den gesamten Server
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:
beziehungsweise Virtual Host) die Eigenschaft ExecCGI, die auch in der allgemeinen Optionenliste All enthalten ist. Sie brauchen also bezüglich Options nichts
* 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
mehr zu tun, wenn im gewünschten (oder übergeordneten) Kontext bereits die
folgende Dateirecht setzen:
folgende Konfigurationsanweisung gesetzt ist:
# chmod a+x skript.pl


Unter Windows entfällt dieser Schritt; diese Art von Dateirechten existiert
Options All
hier nicht.
* Falls es sich um ein interpretiertes Skript handelt, muss dem Webserver mitgeteilt werden, welcher Interpreter für seine Ausführung zuständig ist. Die
traditionelle UNIX-Methode dafür ist die Shebang in der ersten Zeile des
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
Andernfalls müssen Sie ExecCGI zu den bestehenden Optionen hinzufügen.
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
Angenommen, Sie finden im betreffenden Kontext folgende Anweisung:
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
#!C:/Perl/bin/perl.exe
 
Ein kompiliertes, binäres Programm braucht sich natürlich nicht an diese
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
Options Indexes FollowSymLinks
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
Dann müssen Sie die Direktive folgendermaßen ergänzen:
CGI-fähig machen möchten, können Sie dazu die Direktive ScriptAliasMatch
verwenden.


ScriptAliasMatch
Options Indexes FollowSymLinks ExecCGI
Bildet eine durch einen regulären Ausdruck beschriebene Gruppe von Verzeichnissen in die Website ab und aktiviert in ihnen CGI-Skripte.


Modul mod_alias
Um nur in einem untergeordneten Kontext, beispielsweise einem speziellen
Kontext Server, <VirtualHost>
Unterverzeichnis, die CGI-Ausführung zuzulassen, können Sie auch die folgende
Syntax ScriptAliasMatch URL-Pfadmuster Dateisystem-Pfadmuster
Direktive für den entsprechenden Kontext verwenden:
Standardwert nicht gesetzt


Um das Verhalten der Standardkonfiguration der Direktive ScriptAlias mithilfe
Options +ExecCGI
von ScriptAliasMatch nachzuahmen, können Sie die folgende Formulierung verwenden:


ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache2/cgi-bin$1
Diese Schreibweise lässt alle anderen bereits im übergeordneten Kontext gesetzten Optionen unverändert.


Diese Verwendung von ScriptAliasMatch bringt zwar keinen praktischen Nutzen, demonstriert aber das Prinzip: Muster, die dem URL-Pfad (erster Parameter)
Die AddHandler-Direktive muss die Endungen aller Dateitypen auflisten, die als
entsprechen, werden auf den im zweiten Parameter angegebenen Pfad umgesetzt. Geklammerte Ausdrücke aus dem URL-Muster können dabei wie gewohnt
CGI-Skripte gelten sollen. Dazu wird für die CGI-Konfiguration folgendes Schema
als $1, $2 usw. im Ersetzungsteil verwendet werden. Einen kurzen Überblick über
verwendet:
reguläre Ausdrücke finden Sie in Anhang G.


Hier noch drei praxistauglichere Beispiele:
AddHandler cgi-script .Endung1 [.Endung2 ...]


* Angenommen, Sie haben CGI-Skripte für verschiedene Aufgaben und wollen
Wenn Sie beispielsweise Dateien mit den Endungen .cgi und .pl als ausführbare
diese in unterschiedlichen Verzeichnissen ablegen. Die Verzeichnisse heißen
CGI-Skripte konfigurieren möchten, müssen Sie folgende Anweisung verwenden:
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
AddHandler cgi-script .cgi .pl


ScriptAlias /cgi-bin0/ /usr/local/apache2/cgi-bin0/
In der Regel wird diese Direktive einmal für die gesamte Server-Konfiguration
ScriptAlias /cgi-bin1/ /usr/local/apache2/cgi-bin1/
gesetzt. Natürlich steht es Ihnen frei, sie alternativ nur für einzelne Verzeichnisse
[...]
oder andere Unterkontexte einzustellen.
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 kann ein erhebliches Sicherheitsproblem sein, diesen Schritt zu vergessen:
Schritt erledigen:
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.


ScriptAliasMatch ^/cgi-bin([0-9])/(.*) \
Es gibt noch eine (eigentlich veraltete) Alternative zur Verwendung von
/usr/local/apache2/cgi-bin$1/$2
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, z.B.:


* Wenn Sie CGI-Skripte haben, die in mehreren Sprachen geschrieben sind (in
AddType application/x-httpd-cgi .cgi .pl
diesem Beispiel Perl, Shell-Skripte und binäre C-Programme), möchten Sie
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))/(.*) \
Sie könnten diese Zuordnung stattdessen auch in Ihrer MIME-Type-Datei (durch
/usr/local/apache2/cgi-$1/$5
TypesConfig definiert, standardmäßig conf/mime.types) eintragen. Dieser Eintrag sieht beispielsweise so aus:


* 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
application/x-httpd-cgi cgi pl
www.mynet.de/katalog/cgi-bin usw. angesprochen werden, in Wirklichkeit
aber unter der ServerRoot in Verzeichnissen wie cgi-bin/katalog liegen. Das
Konzept soll von vornherein verallgemeinert werden – alle URLs nach dem
Schema www.mynet.de/[a-z]+/cgi-bin sollen in entsprechende CGI-Verzeichnisse umgeleitet werden:


ScriptAliasMatch ^/([a-z]+)/cgi-bin/(.*) \
Wie Sie sehen, werden die Dateiendungen hier ohne führenden Punkt eingetragen. Zu empfehlen ist dieses Verfahren allerdings nicht, weil sich Änderungen in
/usr/local/apache2/cgi-bin/$1/$2
der TypesConfig-Datei nur schwer wiederfinden lassen. Nähere Informationen
zur allgemeinen MIME-Type-Konfiguration finden Sie in Kapitel 7, »Header und
MIME-Einstellungen«.

Version vom 29. März 2025, 23:07 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, z.B.:

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