Sophie: php-manual-en-4.3.0-2mdk noarch

php-manual-en-4.3.0-2mdk.noarch.rpm

<HTML
><HEAD
><TITLE
>Installed as CGI binary</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="PHP Manual"
HREF="index.html"><LINK
REL="UP"
TITLE="Security"
HREF="security.html"><LINK
REL="PREVIOUS"
TITLE="Security"
HREF="security.html"><LINK
REL="NEXT"
TITLE="Installed as an Apache module"
HREF="security.apache.html"><META
HTTP-EQUIV="Content-type"
CONTENT="text/html; charset=ISO-8859-1"></HEAD
><BODY
CLASS="sect1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PHP Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="security.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 5. Security</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="security.apache.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="security.cgi-bin"
></A
>Installed as CGI binary</H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="security.cgi-bin.attacks"
></A
>Possible attacks</H2
><P
>&#13;     Using PHP as a <SPAN
CLASS="acronym"
>CGI</SPAN
> binary is an option for
     setups that for some reason do not wish to integrate PHP as a
     module into server software (like Apache), or will use PHP with
     different kinds of CGI wrappers to create safe chroot and setuid
     environments for scripts.  This setup usually involves installing
     executable PHP binary to the web server cgi-bin directory.  CERT
     advisory <A
HREF="http://www.cert.org/advisories/CA-96.11.interpreters_in_cgi_bin_dir.html"
TARGET="_top"
>CA-96.11</A
> recommends
     against placing any interpreters into cgi-bin.  Even if the PHP
     binary can be used as a standalone interpreter, PHP is designed
     to prevent the attacks this setup makes possible:
    </P
><P
></P
><UL
><LI
><P
>&#13;       Accessing system files: <TT
CLASS="filename"
>http://my.host/cgi-bin/php?/etc/passwd</TT
>
      </P
><P
>&#13;       The query information in a url after the question mark (?)  is
       passed as command line arguments to the interpreter by the CGI
       interface.  Usually interpreters open and execute the file
       specified as the first argument on the command line.
      </P
><P
>&#13;       When invoked as a CGI binary, PHP refuses to interpret the
       command line arguments.
      </P
></LI
><LI
><P
>&#13;       Accessing any web document on server: <TT
CLASS="filename"
>http://my.host/cgi-bin/php/secret/doc.html</TT
>
      </P
><P
>&#13;       The path information part of the url after the PHP binary name,
       <TT
CLASS="filename"
>/secret/doc.html</TT
> is
       conventionally used to specify the name of the file to be
       opened and interpreted by the <SPAN
CLASS="acronym"
>CGI</SPAN
> program.
       Usually some web server configuration directives (Apache:
       Action) are used to redirect requests to documents like
       <TT
CLASS="filename"
>http://my.host/secret/script.php</TT
> to the
       PHP interpreter.  With this setup, the web server first checks
       the access permissions to the directory <TT
CLASS="filename"
>/secret</TT
>, and after that creates the
       redirected request <TT
CLASS="filename"
>http://my.host/cgi-bin/php/secret/script.php</TT
>.
       Unfortunately, if the request is originally given in this form,
       no access checks are made by web server for file <TT
CLASS="filename"
>/secret/script.php</TT
>, but only for the
       <TT
CLASS="filename"
>/cgi-bin/php</TT
> file.  This way
       any user able to access <TT
CLASS="filename"
>/cgi-bin/php</TT
> is able to access any
       protected document on the web server.
      </P
><P
>&#13;       In PHP, compile-time configuration option <A
HREF="install.configure.html#install.configure.enable-force-cgi-redirect"
>--enable-force-cgi-redirect</A
>
       and runtime configuration directives <A
HREF="configuration.directives.html#ini.doc-root"
>doc_root</A
> and <A
HREF="configuration.directives.html#ini.user-dir"
>user_dir</A
> can be used to prevent
       this attack, if the server document tree has any directories
       with access restrictions.  See below for full the explanation
       of the different combinations.
      </P
></LI
></UL
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="security.cgi-bin.default"
></A
>Case 1: only public files served</H2
><P
>&#13;     If your server does not have any content that is not restricted
     by password or ip based access control, there is no need for
     these configuration options.  If your web server does not allow
     you to do redirects, or the server does not have a way to
     communicate to the PHP binary that the request is a safely
     redirected request, you can specify the option <A
HREF="install.configure.html#install.configure.enable-force-cgi-redirect"
>--enable-force-cgi-redirect</A
>
     to the configure script.  You still have to make sure your PHP
     scripts do not rely on one or another way of calling the script,
     neither by directly <TT
CLASS="filename"
>http://my.host/cgi-bin/php/dir/script.php</TT
>
     nor by redirection <TT
CLASS="filename"
>http://my.host/dir/script.php</TT
>.
    </P
><P
>&#13;     Redirection can be configured in Apache by using AddHandler and
     Action directives (see below).
    </P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="security.cgi-bin.force-redirect"
></A
>Case 2: using --enable-force-cgi-redirect</H2
><P
>&#13;     This compile-time option prevents anyone from calling PHP
     directly with a url like <TT
CLASS="filename"
>http://my.host/cgi-bin/php/secretdir/script.php</TT
>.
     Instead, PHP will only parse in this mode if it has gone through
     a web server redirect rule.
    </P
><P
>&#13;     Usually the redirection in the Apache configuration is done with
     the following directives:
    </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
CELLPADDING="5"
><TR
><TD
><PRE
CLASS="apache-conf"
>Action php-script /cgi-bin/php
AddHandler php-script .php</PRE
></TD
></TR
></TABLE
><P
>&#13;     This option has only been tested with the Apache web server, and
     relies on Apache to set the non-standard CGI environment variable
     <TT
CLASS="envar"
>REDIRECT_STATUS</TT
> on redirected requests.  If your
     web server does not support any way of telling if the request is
     direct or redirected, you cannot use this option and you must use
     one of the other ways of running the CGI version documented
     here.
    </P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="security.cgi-bin.doc-root"
></A
>Case 3: setting doc_root or user_dir</H2
><P
>&#13;     To include active content, like scripts and executables, in the
     web server document directories is sometimes consider an insecure
     practice.  If, because of some configuration mistake, the scripts
     are not executed but displayed as regular HTML documents, this
     may result in leakage of intellectual property or security
     information like passwords.  Therefore many sysadmins will prefer
     setting up another directory structure for scripts that are
     accessible only through the PHP CGI, and therefore always
     interpreted and not displayed as such.
    </P
><P
>&#13;     Also if the method for making sure the requests are not
     redirected, as described in the previous section, is not
     available, it is necessary to set up a script doc_root that is
     different from web document root.
    </P
><P
>&#13;     You can set the PHP script document root by the configuration
     directive <A
HREF="configuration.directives.html#ini.doc-root"
>doc_root</A
> in the
     <A
HREF="configuration.html#configuration.file"
>configuration file</A
>, or
     you can set the environment variable
     <TT
CLASS="envar"
>PHP_DOCUMENT_ROOT</TT
>.  If it is set, the CGI version
     of PHP will always construct the file name to open with this
     <TT
CLASS="parameter"
><I
>doc_root</I
></TT
> and the path information in the
     request, so you can be sure no script is executed outside this
     directory (except for <TT
CLASS="parameter"
><I
>user_dir</I
></TT
>
     below).
    </P
><P
>&#13;     Another option usable here is <A
HREF="configuration.directives.html#ini.user-dir"
>user_dir</A
>.  When user_dir is unset,
     only thing controlling the opened file name is
     <TT
CLASS="parameter"
><I
>doc_root</I
></TT
>.  Opening an url like <TT
CLASS="filename"
>http://my.host/~user/doc.php</TT
> does not
     result in opening a file under users home directory, but a file
     called <TT
CLASS="filename"
>~user/doc.php</TT
> under
     doc_root (yes, a directory name starting with a tilde
     [<TT
CLASS="literal"
>~</TT
>]).
    </P
><P
>&#13;     If user_dir is set to for example <TT
CLASS="filename"
>public_php</TT
>, a request like <TT
CLASS="filename"
>http://my.host/~user/doc.php</TT
> will open a
     file called <TT
CLASS="filename"
>doc.php</TT
> under the directory
     named <TT
CLASS="filename"
>public_php</TT
> under the home
     directory of the user.  If the home of the user is <TT
CLASS="filename"
>/home/user</TT
>, the file executed is
     <TT
CLASS="filename"
>/home/user/public_php/doc.php</TT
>.
    </P
><P
>&#13;     <TT
CLASS="parameter"
><I
>user_dir</I
></TT
> expansion happens regardless of
     the <TT
CLASS="parameter"
><I
>doc_root</I
></TT
> setting, so you can control
     the document root and user directory access
     separately.
    </P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="security.cgi-bin.shell"
></A
>Case 4: PHP parser outside of web tree</H2
><P
>&#13;     A very secure option is to put the PHP parser binary somewhere
     outside of the web tree of files.  In <TT
CLASS="filename"
>/usr/local/bin</TT
>, for example.  The only real
     downside to this option is that you will now have to put a line
     similar to:
     <DIV
CLASS="informalexample"
><A
NAME="AEN2881"
></A
><P
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
CELLPADDING="5"
><TR
><TD
><PRE
CLASS="programlisting"
>#!/usr/local/bin/php</PRE
></TD
></TR
></TABLE
><P
></P
></DIV
>
     as the first line of any file containing PHP tags.  You will also
     need to make the file executable.  That is, treat it exactly as
     you would treat any other CGI script written in Perl or sh or any
     other common scripting language which uses the
     <TT
CLASS="literal"
>#!</TT
> shell-escape mechanism for launching
     itself.
    </P
><P
>&#13;     To get PHP to handle <TT
CLASS="envar"
>PATH_INFO</TT
> and
     <TT
CLASS="envar"
>PATH_TRANSLATED</TT
> information correctly with this
     setup, the php parser should be compiled with the <A
HREF="install.configure.html#install.configure.enable-discard-path"
>--enable-discard-path</A
>
     configure option.
    </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="security.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="security.apache.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Security</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="security.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Installed as an Apache module</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>