<?xml version="1.0" encoding="utf-8"?> <!-- $Revision$ --> <!-- splitted from ./index.xml, last change in rev 1.66 --> <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 chroot and setuid environments for scripts. This setup usually involves installing executable PHP binary to the web server cgi-bin directory. CERT advisory <link xlink:href="&url.cert;">CA-96.11</link> 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: </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 (?) 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, PHP 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: Action) 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 specify the option <link linkend="configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link> 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 <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 AddHandler and Action 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 PHP 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. PHP older than 4.2.0 used <literal>--enable-force-cgi-redirect</literal> compile time option for this. </simpara> <simpara> Usually the redirection in the Apache configuration is done with the following directives: </simpara> <programlisting role="apache-conf"> <![CDATA[ Action php-script /cgi-bin/php AddHandler php-script .php ]]> </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 doc_root 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 user_dir 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 doc_root (yes, a directory name starting with a tilde [<literal>~</literal>]). </simpara> <simpara> If user_dir 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> <![CDATA[ #!/usr/local/bin/php ]]> </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 PHP parser should be compiled with the <link linkend="configure.enable-discard-path">--enable-discard-path</link> configure option. </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 -->