Source of: /manual/en/security.cgi-bin.attacks.php
<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/security.cgi-bin.inc";
$setup = array (
'home' =>
array (
0 => 'index.php',
1 => 'PHP Manual',
),
'head' =>
array (
0 => 'UTF-8',
1 => 'en',
),
'this' =>
array (
0 => 'security.cgi-bin.attacks.php',
1 => 'Possible attacks',
),
'up' =>
array (
0 => 'security.cgi-bin.php',
1 => 'Installed as CGI binary',
),
'prev' =>
array (
0 => 'security.cgi-bin.php',
1 => 'Installed as CGI binary',
),
'next' =>
array (
0 => 'security.cgi-bin.default.php',
1 => 'Case 1: only public files served',
),
);
$setup["toc"] = $TOC;
$setup["parents"] = $PARENTS;
manual_setup($setup);
manual_header();
?>
<div id="security.cgi-bin.attacks" class="sect1">
<h2 class="title">Possible attacks</h2>
<p class="simpara">
Using PHP as a <acronym title="Common Gateway Interface">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 title="Common Gateway Interface">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 <a href="http://www.cert.org/advisories/CA-1996-11.html" class="link external">» 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>
<ul class="itemizedlist">
<li class="listitem">
<span class="simpara">
Accessing system files: <var class="filename">http://my.host/cgi-bin/php?/etc/passwd</var>
</span>
<span class="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.
</span>
<span class="simpara">
When invoked as a CGI binary, PHP refuses to interpret the
command line arguments.
</span>
</li>
<li class="listitem">
<span class="simpara">
Accessing any web document on server: <var class="filename">http://my.host/cgi-bin/php/secret/doc.html</var>
</span>
<span class="simpara">
The path information part of the URL after the PHP binary name,
<var class="filename">/secret/doc.html</var> is
conventionally used to specify the name of the file to be
opened and interpreted by the <acronym title="Common Gateway Interface">CGI</acronym> program.
Usually some web server configuration directives (Apache:
Action) are used to redirect requests to documents like
<var class="filename">http://my.host/secret/script.php</var> to the
PHP interpreter. With this setup, the web server first checks
the access permissions to the directory <var class="filename">/secret</var>, and after that creates the
redirected request <var class="filename">http://my.host/cgi-bin/php/secret/script.php</var>.
Unfortunately, if the request is originally given in this form,
no access checks are made by web server for file <var class="filename">/secret/script.php</var>, but only for the
<var class="filename">/cgi-bin/php</var> file. This way
any user able to access <var class="filename">/cgi-bin/php</var> is able to access any
protected document on the web server.
</span>
<span class="simpara">
In PHP, runtime configuration directives <a href="ini.core.php#ini.cgi.force-redirect" class="link">cgi.force_redirect</a>, <a href="ini.core.php#ini.doc-root" class="link">doc_root</a> and <a href="ini.core.php#ini.user-dir" class="link">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.
</span>
</li>
</ul>
</div><?php manual_footer(); ?>
