archived-doc-de/security/cgi-bin.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
<!-- EN-Revision: 87d3bf2e9ea7da5abbeca3e60ea7cf7abfa6f7f3 Maintainer: wiesemann Status: ready -->
  <chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
   <title>Installiert als CGI-Version</title>

   <sect1 xml:id="security.cgi-bin.attacks">
    <title>Mögliche Angriffe</title>
    <simpara>
     PHP als <acronym>CGI</acronym>-Version zu nutzen, ist eine Möglichkeit
     für Installationen, bei denen aus irgendwelchen Gründen kein Modul in
     die Serversoftware eingebunden werden soll (wie beim Apache) oder für
     Systeme, bei denen verschiedene <acronym>CGI</acronym>-Wrapper genutzt
     werden sollen, um sichere <command>chroot</command>- und
     <command>setuid</command>-Umgebungen für Skripte zu schaffen. Bei dieser
     Konfiguration wird das ausführbare <command>php</command>-Binary
     üblicherweise im <filename class="directory">cgi-bin</filename>-Verzeichnis
     des Webservers installiert. CERT-Advisory
     <link xlink:href="&url.cert;">CA-96.11</link> spricht sich gegen die
     Platzierung von Interpretern im
     <filename class="directory">cgi-bin</filename>-Verzeichnis aus. Obwohl das
     <command>php</command>-Binary als eigenständiger Interpreter verwendet
     werden kann, wurde PHP so entwickelt, um den durch diese Konfiguration
     möglich werdenden Angriffe vorzubeugen:
    </simpara>
    <itemizedlist>
     <listitem>
      <simpara>
       Zugriff auf Systemdateien: <filename
       role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
      </simpara>
      <simpara>
       Die auf ein Fragezeichen (<literal>?</literal>) folgende
       Abfrageinformation in einer URL wird durch das CGI-Interface als
       Kommandozeilenargument an den Interpreter weitergereicht. In der
       Kommandozeile wird üblicherweise die im ersten Argument angegebene Datei
       von Interpretern geöffnet und ausgeführt.
      </simpara>
      <simpara>
       Beim Aufruf als CGI-Binary verweigert <command>php</command> die
       Interpretation der Kommandozeilenargumente.
      </simpara>
     </listitem>
     <listitem>
      <simpara>
       Zugriff auf beliebige Web-Dokumente auf dem Server: <filename
       role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>
      </simpara>
      <simpara>
       Der Teil der URL-Pfadinformation nach dem Namen der PHP Binärdatei,
       <filename role="uri">/secret/doc.html</filename>, wird im
       Allgemeinen benutzt, um den Namen der Datei zu übergeben,
       die durch das <acronym>CGI</acronym>-Programm geöffnet und
       interpretiert werden soll.
       Normalerweise werden einige Einträge in der Konfigurationsdatei
       des Webservers benutzt (Apache: <literal>Action</literal>), um Aufrufe
       von Dokumenten wie
       <filename role="url">http://my.host/secret/script.php</filename> an den
       PHP-Interpreter umzuleiten. Bei dieser Konfiguration überprüft der
       Webserver zuerst die Zugriffsrechte im Verzeichnis
       <filename role="uri">/secret</filename> und erstellt anschließend den
       umgeleiteten Aufruf <filename
       role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
       Unglücklicherweise wird, wenn der Aufruf bereits in dieser Form
       geschieht, vom Webserver keine Zugriffsüberprüfung der Datei
       <filename role="uri">/secret/script.php</filename>, sondern
       lediglich der Datei <filename role="uri">/cgi-bin/php</filename>
       vorgenommen. So ist
       jeder Benutzer, der auf <filename role="uri">/cgi-bin/php</filename>
       zugreifen darf, in der Lage, sich zu jedem geschützten Dokument
       auf dem Webserver Zugriff zu verschaffen.
      </simpara>
      <simpara>
       Bei PHP können beim Kompilieren die Konfigurationsdirektiven <link
       linkend="ini.cgi.force-redirect">cgi.force_redirect</link>,
       <link linkend="ini.doc-root">doc_root</link> und <link
       linkend="ini.user-dir">user_dir</link>
       benutzt werden, um diesen Angriff zu verhindern, falls
       der Verzeichnisbaum des Servers Verzeichnisse mit
       Zugriffsbeschränkungen beinhaltet.
       Ausführliche Informationen über die verschiedenen Kombinationen
       sind weiter unten beschrieben.
      </simpara>
     </listitem>
    </itemizedlist>
   </sect1>

   <sect1 xml:id="security.cgi-bin.default">
    <title>Fall 1: Nur öffentliche Dateien vorhanden</title>
    <simpara>
     Wenn der Server keine Inhalte hat, die durch ein Passwort oder
     IP-basierte Zugriffskontrolle geschützt sind, werden diese
     Konfigurationsoptionen nicht benötigt.
     Wenn der Webserver keine Redirects erlaubt oder keine Möglichkeit
     hat, dem PHP-Binary mitzuteilen, dass es sich um eine sicher umgeleitete
     Anfrage handelt, kann die Konfigurationsdirekive
     <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>
     aktiviert werden. Nichtsdestotrotz müssen Sie sicherstellen, dass Ihre
     PHP-Skripte nicht auf die eine oder andere Art des Aufrufs angewiesen
     sind, weder direkt durch
     <filename role="php">http://my.host/cgi-bin/php/dir/script.php</filename>
     noch durch einen Redirect
     <filename role="php">http://my.host/dir/script.php</filename>.
    </simpara>
    <simpara>
     Beim Apache kann der Redirect durch Verwendung der Direktiven
     <literal>AddHandler</literal> und <literal>Action</literal> konfiguriert
     werden (siehe unten).
    </simpara>
   </sect1>

   <sect1 xml:id="security.cgi-bin.force-redirect">
    <title>Fall 2: <literal>--enable-force-cgi-redirect</literal> benutzen</title>
    <simpara>
     Die Konfigurationsdirektive
     <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>
     verhindert grundsätzlich den Aufruf von <command>php</command> mit einer
     URL wie <filename
     role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>.
     Stattdessen parst PHP in diesem Modus nur dann, wenn der Aufruf durch
     einen korrekten Redirect des Webservers erfolgte.
    </simpara>
    <simpara>
     Normalerweise wird der Redirect in der Apache-Konfiguration mit den
     folgenden Einträgen festgelegt:</simpara>
    <programlisting role="apache-conf">
<![CDATA[
Action php-script /cgi-bin/php
AddHandler php-script .php
]]>
    </programlisting>
    <simpara>
     Diese Option wurde nur mit dem Apache Webserver getestet und
     ist abhängig davon, wie Apache die nicht standardmäßige
     CGI-Umgebungsvariable <envar>REDIRECT_STATUS</envar> bei
     Redirect-Anfragen setzt.
     Sollte Ihr Webserver keine Möglichkeit unterstützen, zu übermitteln,
     ob es sich um einen direkten Aufruf oder einen Redirect handelt,
     können Sie diese Option nicht verwenden und müssen einen der
     anderen hier beschriebenen Wege gehen, die CGI-Version zu
     nutzen.
    </simpara>
   </sect1>

   <sect1 xml:id="security.cgi-bin.doc-root">
    <title>Fall 3: doc_root oder user_dir festlegen</title>
    <simpara>
     Aktiven Inhalt, wie beispielsweise Skripts und ausführbare
     Dateien, in den Dokumentverzeichnissen des Webservers abzulegen,
     wird manchmal als unsichere Methode angesehen.
     Wenn, beispielsweise aufgrund von Konfigurationsfehlern, die
     Skripte nicht ausgeführt, sondern als reguläre HTML-Dokumente
     angezeigt werden, kann dies ein Durchsickern von geistigem Eigentum
     und sicherheitsrelevanter Informationen wie Passwörtern zur Folge
     haben. Deshalb ziehen es viele Systemadministratoren vor, eine
     zweite Verzeichnisstruktur für Skripte einzurichten, auf die nur
     durch das PHP-CGI zugegriffen werden kann. Diese werden dann stets
     interpretiert und nicht angezeigt.
    </simpara>
    <simpara>
     Auch wenn die Methode zum sichergestellten Verhindern einer Umleitung
     von Anfragen (wie im vorangegangenen Abschnitt beschrieben) nicht
     verfügbar ist, ist es notwendig, ein
     <link linkend="ini.doc-root">doc_root</link> für Skripte zusätzlich zum
     Web-Dokumentenverzeichnis einzurichten.
    </simpara>
    <simpara>
     Sie können das PHP-Skriptverzeichnis durch die Direktive
     <link linkend="ini.doc-root">doc_root</link> in der
     <link linkend="configuration.file">Konfigurationsdatei</link>
     festlegen, oder Sie setzen die Umgebungsvariable
     <envar>PHP_DOCUMENT_ROOT</envar>. Wenn sie gesetzt ist, wird die
     <acronym>CGI</acronym>-Version von PHP den Namen der zu öffnenden Datei
     stets aus <parameter>doc_root</parameter> und der Pfadinformation der
     Anfrage zusammensetzen, sodass man sicher sein kann, dass außerhalb
     dieses Verzeichnisses keine Skripte ausgeführt werden (außer
     <parameter>user_dir</parameter>, siehe unten).
    </simpara>
    <simpara>
     Eine weitere hier nützliche Option ist <link
     linkend="ini.user-dir">user_dir</link>. Wenn
     <parameter>user_dir</parameter> nicht gesetzt ist, hat nur
     <parameter>doc_root</parameter> Einfluss auf die zu öffnende Datei.
     Der Aufruf einer URL wie <filename
     role="url">http://my.host/~user/doc.php</filename> hat nicht zum
     Ergebnis, dass eine Datei im Heimatverzeichnis des Benutzers geöffnet
     wird, sondern eine Datei namens
     <filename role="uri">~user/doc.php</filename> unterhalb von
     <parameter>doc_root</parameter>. (Ja, ein Verzeichnisname, der mit einer
     Tilde anfängt [<literal>~</literal>].)
    </simpara>
    <simpara>
     Ist <parameter>user_dir</parameter> beispielsweise auf
     <filename role="dir">public_php</filename> gesetzt, wird eine Anfrage wie
     <filename role="url">http://my.host/~user/doc.php</filename> eine Datei
     namens <filename>doc.php</filename> im Verzeichnis
     <filename role="dir">public_php</filename> im Heimatverzeichnis des
     Benutzers öffnen. Wenn das Heimatverzeichnis des Benutzers
     <filename role="dir">/home/user</filename> ist, so ist die ausgeführte
     Datei <filename>/home/user/public_php/doc.php</filename>.
    </simpara>
    <simpara>
     Die <parameter>user_dir</parameter>-Expansion erfolgt ohne Berücksichtigung
     der <parameter>doc_root</parameter>-Einstellung. So können Zugriffe
     auf die Dokumenten- und Benutzerverzeichnisse separat gesteuert werden.
    </simpara>
   </sect1>

   <sect1 xml:id="security.cgi-bin.shell">
    <title>Fall 4: PHP-Parser außerhalb des Webverzeichnisbaums</title>
    <para>
     Eine sehr sichere Sache ist es, das PHP-Parser-Binary irgendwo
     außerhalb des Webverzeichnisbaums zu platzieren, beispielsweise
     in <filename role="dir">/usr/local/bin</filename>. Der einzige
     Nachteil dieses Verfahrens ist, dass eine Zeile ähnlich der
     folgenden Zeile:
     <informalexample>
      <programlisting>
<![CDATA[
#!/usr/local/bin/php
]]>
      </programlisting>
     </informalexample>
     als erste Zeile in jeder Datei, die PHP-Tags enthält, stehen muss.
     Außerdem muss die Datei ausführbar sein. Ansonsten ist sie genauso
     zu behandeln wie ein beliebiges CGI-Script in Perl oder sh oder
     anderen gebräuchlichen Skriptsprachen, die den
     <literal>#!</literal>-shell-escape-Mechanismus nutzen, um sich
     selbst aufzurufen.
    </para>
    <para>
     Damit PHP bei dieser Konfiguration die <envar>PATH_INFO</envar>- und
     <envar>PATH_TRANSLATED</envar>-Informationen korrekt auswertet,
     muss die Konfigurationsdirektive
     <link linkend="ini.cgi.discard-path">cgi.discard_path</link> aktiviert
     werden.
    </para>
   </sect1>

  </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->