<?xml version="1.0" encoding="utf-8"?>

<chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">

<title>Installed as CGI binary</title>

<sect1 xml:id="security.cgi-bin.attacks">

<title>Possible attacks</title>

<simpara>

Using PHP as a <acronym>CGI</acronym> 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 <acronym>CGI</acronym> wrappers to create safe

<command>chroot</command> and <command>setuid</command>

environments for scripts. This setup usually involves installing

executable <command>php</command> binary to the web server <filename class="directory">cgi-bin</filename> directory.

CERT advisory <link xlink:href="&url.cert;">CA-96.11</link> recommends

against placing any interpreters into <filename class="directory">cgi-bin</filename>.

Even if the <command>php</command> binary can be used as a standalone interpreter,

PHP is designed to prevent the attacks this setup makes possible:

</simpara>

<itemizedlist>

<listitem>

<simpara>

Accessing system files: <filename

role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>

</simpara>

<simpara>

The query information in a URL after the question mark (<literal>?</literal>) 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.

</simpara>

<simpara>

When invoked as a CGI binary, <command>php</command> refuses to interpret the

command line arguments.

</simpara>

</listitem>

<listitem>

<simpara>

Accessing any web document on server: <filename

role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>

</simpara>

<simpara>

The path information part of the URL after the PHP binary name,

<filename role="uri">/secret/doc.html</filename> is

conventionally used to specify the name of the file to be

opened and interpreted by the <acronym>CGI</acronym> program.

Usually some web server configuration directives (Apache:

<literal>Action</literal>) are used to redirect requests to documents like

<filename

role="url">http://my.host/secret/script.php</filename> to the

PHP interpreter. With this setup, the web server first checks

the access permissions to the directory <filename

role="uri">/secret</filename>, and after that creates the

redirected request <filename

role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.

Unfortunately, if the request is originally given in this form,

no access checks are made by web server for file <filename

role="uri">/secret/script.php</filename>, but only for the

<filename role="uri">/cgi-bin/php</filename> file. This way

any user able to access <filename

role="uri">/cgi-bin/php</filename> is able to access any

protected document on the web server.

</simpara>

<simpara>

In PHP, runtime configuration directives <link

linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link

linkend="ini.doc-root">doc_root</link> and <link

linkend="ini.user-dir">user_dir</link> 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.

</simpara>

</listitem>

</itemizedlist>

</sect1>

<sect1 xml:id="security.cgi-bin.default">

<title>Case 1: only public files served</title>

<simpara>

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 enable the

<link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>

ini directive. You still have to make sure your PHP

scripts do not rely on one or another way of calling the script,

neither by directly <filename

role="php">http://my.host/cgi-bin/php/dir/script.php</filename>

nor by redirection <filename

role="php">http://my.host/dir/script.php</filename>.

</simpara>

<simpara>

Redirection can be configured in Apache by using <literal>AddHandler</literal> and

<literal>Action</literal> directives (see below).

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.force-redirect">

<title>Case 2: using <literal>cgi.force_redirect</literal></title>

<simpara>

The configuration directive <link

linkend="ini.cgi.force-redirect">cgi.force_redirect</link>

prevents anyone from calling <command>php</command>

directly with a URL like <filename

role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>.

Instead, PHP will only parse in this mode if it has gone through

a web server redirect rule.

</simpara>

<simpara>

Usually the redirection in the Apache configuration is done with

the following directives:

</simpara>

<programlisting role="apache-conf">

</programlisting>

<simpara>

This option has only been tested with the Apache web server, and

relies on Apache to set the non-standard CGI environment variable

<envar>REDIRECT_STATUS</envar> 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.

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.doc-root">

<title>Case 3: setting doc_root or user_dir</title>

<simpara>

To include active content, like scripts and executables, in the

web server document directories is sometimes considered 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.

</simpara>

<simpara>

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 <link linkend="ini.doc-root">doc_root</link> that is

different from web document root.

</simpara>

<simpara>

You can set the PHP script document root by the configuration

directive <link linkend="ini.doc-root">doc_root</link> in the

<link linkend="configuration.file">configuration file</link>, or

you can set the environment variable

<envar>PHP_DOCUMENT_ROOT</envar>. If it is set, the <acronym>CGI</acronym>

version of PHP will always construct the file name to open with this

<parameter>doc_root</parameter> and the path information in the

request, so you can be sure no script is executed outside this

directory (except for <parameter>user_dir</parameter>

below).

</simpara>

<simpara>

Another option usable here is <link

linkend="ini.user-dir">user_dir</link>. When <parameter>user_dir</parameter> is

unset, only thing controlling the opened file name is

<parameter>doc_root</parameter>. Opening a URL like <filename

role="url">http://my.host/~user/doc.php</filename> does not

result in opening a file under users home directory, but a file

called <filename role="uri">~user/doc.php</filename> under

<parameter>doc_root</parameter> (yes, a directory name starting with a tilde

[<literal>~</literal>]).

</simpara>

<simpara>

If <parameter>user_dir</parameter> is set to for example <filename

role="dir">public_php</filename>, a request like <filename

role="url">http://my.host/~user/doc.php</filename> will open a

file called <filename>doc.php</filename> under the directory

named <filename role="dir">public_php</filename> under the home

directory of the user. If the home of the user is <filename

role="dir">/home/user</filename>, the file executed is

<filename>/home/user/public_php/doc.php</filename>.

</simpara>

<simpara>

<parameter>user_dir</parameter> expansion happens regardless of

the <parameter>doc_root</parameter> setting, so you can control

the document root and user directory access

separately.

</simpara>

</sect1>

<sect1 xml:id="security.cgi-bin.shell">

<title>Case 4: PHP parser outside of web tree</title>

<para>

A very secure option is to put the PHP parser binary somewhere

outside of the web tree of files. In <filename

role="dir">/usr/local/bin</filename>, for example. The only real

downside to this option is that you will now have to put a line

similar to:

<informalexample>

<programlisting>

</programlisting>

</informalexample>

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

<literal>#!</literal> shell-escape mechanism for launching

itself.

</para>

<para>

To get PHP to handle <envar>PATH_INFO</envar> and

<envar>PATH_TRANSLATED</envar> information correctly with this

setup, the <link linkend="ini.cgi.discard-path">cgi.discard_path</link>

ini directive has to be enabled.

</para>

</sect1>

</chapter>