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

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: 6a5b42e0d34c76890fd96be2b0b57516363b4c8a Maintainer: shein Status: ready -->
<!-- Reviewed: no -->
<chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
 <title>Если PHP установлен как CGI</title>

 <sect1 xml:id="security.cgi-bin.attacks">
  <title>Возможные атаки</title>
  <simpara>
   Использование PHP как бинарного <acronym>CGI</acronym>-приложения
   является одним из вариантов, когда по каким-либо причинам нежелательно
   интегрировать PHP в веб-сервер (например, Apache) в качестве модуля,
   либо предполагается использование различных <acronym>CGI</acronym>-обёрток
   и таких утилит, как chroot и setuid для организации безопасного
   окружения работы скриптов.
   Такая установка обычно сопровождается копированием исполняемого
   файла PHP в директорию cgi-bin веб-сервера.  CERT (организация,
   следящая за угрозами безопасности)
   <link xlink:href="&url.cert;">CA-96.11</link>  рекомендует не помещать
   какие-либо интерпретаторы в каталог cgi-bin. Даже если PHP используется
   как самостоятельный интерпретатор, он спроектирован так, чтобы предотвратить
   возможность следующих атак:
  </simpara>
  <itemizedlist>
   <listitem>
    <simpara>
     Доступ к системным файлам: <filename
     role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
    </simpara>
    <simpara>
     Данные, введённые в строке запроса (URL) после вопросительного знака,
     передаются интерпретатору как аргументы командной строки с помощью
     интерфейса CGI. Обычно интерпретаторы открывают
     и исполняют файл, указанный в качестве первого аргумента.
    </simpara>
    <simpara>
     В случае использования PHP в качестве CGI-приложения он не
     станет интерпретировать аргументы командной строки.
    </simpara>
   </listitem>
   <listitem>
    <simpara>
     Доступ к произвольному документу на сервере:
     <filename
     role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>
    </simpara>
    <simpara>
     Согласно общепринятому соглашению, часть пути в запрошенной
     странице, которая расположена после имени выполняемого модуля
     PHP, <filename role="uri">/secret/doc.html</filename>,
     используется для указания файла, который будет интерпретирован
     <acronym>CGI</acronym>-программой. Обычно, некоторые конфигурационные
     опции веб-сервера (например, Action для сервера Apache) используются
     для перенаправления документа, к примеру, для перенаправления запросов
     вида <filename
     role="url">http://my.host/secret/script.php</filename> интерпретатору PHP.
     В таком случае веб-сервер сначала проверяет права доступа к
     директории <filename role="uri">/secret</filename>, и после этого
     создаёт перенаправленный запрос <filename
     role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
     К сожалению, если запрос изначально задан в полном виде,
     проверка на наличие прав для файла <filename
     role="uri">/secret/script.php</filename> не выполняется, она
     происходит только для файла <filename role="uri">/cgi-bin/php</filename>.
     Таким образом, пользователь имеет возможность обратиться к
     <filename role="uri">/cgi-bin/php</filename>,
     и, как следствие, к любому защищённому документу на сервере.
    </simpara>
    <simpara>
     Если в PHP указать во время исполнения скрипта опции <link
     linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link
     linkend="ini.doc-root">doc_root</link> и <link
     linkend="ini.user-dir">user_dir</link>, то можно предотвратить
     подобные атаки для директорий с ограниченным доступом.
     Более детально приведённые опции, а также их комбинации будут рассмотрены ниже.
    </simpara>
   </listitem>
  </itemizedlist>
 </sect1>

 <sect1 xml:id="security.cgi-bin.default">
  <title>Вариант 1: обслуживаются только общедоступные файлы</title>

  <simpara>
   В случае, если на вашем сервере отсутствуют файлы, доступ к
   которым ограничен паролем либо фильтром по IP-адресам, нет
   никакой необходимости использовать данные опции.
   Если ваш веб-сервер не разрешает выполнять перенаправления,
   либо не имеет возможности взаимодействовать с исполняемым
   PHP-модулем на необходимом уровне безопасности, вы можете
   включить ini-директиву <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>.
   Но при этом вы всё ещё должны убедиться, что
   альтернативные способы вызова скрипта, такие как непосредственный
   вызов <filename
   role="php">http://my.host/cgi-bin/php/dir/script.php</filename>
   либо с переадресацией <filename
   role="php">http://my.host/dir/script.php</filename>, недоступны.
  </simpara>
  <simpara>
   В веб-сервере Apache перенаправление может быть сконфигурировано
   при помощи директив AddHandler и Action (описано ниже).
  </simpara>
 </sect1>

 <sect1 xml:id="security.cgi-bin.force-redirect">
  <title>Вариант 2: использование <literal>cgi.force_redirect</literal></title>
  <simpara>
   Конфигурационная директива <link
   linkend="ini.cgi.force-redirect">cgi.force_redirect</link>
   предотвращает попытки непосредственного вызова PHP по адресу
   вида <filename
   role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>.
   Вместо этого PHP будет обрабатывать пришедший запрос только в том случае,
   если он был перенаправлен веб-сервером.
  </simpara>
  <simpara>
   Обычно перенаправление в конфигурации Apache настраивается при помощи
   следующих опций:
  </simpara>
  <programlisting role="apache-conf">
<![CDATA[
Action php-script /cgi-bin/php
AddHandler php-script .php
]]>
    </programlisting>
    <simpara>
     Эта опция проверена только с веб-сервером Apache, её работа основывается
     на установке в случае перенаправления нестандартной переменной
     <envar>REDIRECT_STATUS</envar>, находящейся в CGI-окружении.
     В случае, если ваш веб-сервер не предоставляет возможности
     однозначно идентифицировать, является ли данный запрос
     перенаправленным, вы не можете использовать описываемую в
     данном разделе опцию и должны воспользоваться любым другим
     методом работы с CGI-приложениями.
    </simpara>
   </sect1>

   <sect1 xml:id="security.cgi-bin.doc-root">
    <title>Вариант 3: использование опций doc_root или user_dir</title>
    <simpara>
     Размещение динамического контента, такого как скрипты или любых
     других исполняемых файлов, в директории веб-сервера делает его
     потенциально опасным. В случае, если в конфигурации сервера допущена
     ошибка, возможна ситуация, когда скрипты не выполняются, а отображаются
     в браузере, как обычные HTML-документы, что может привести к утечке конфиденциальной
     информации (например, паролей), либо информации, являющейся
     интеллектуальной собственностью. Исходя из таких соображений, многие
     системные администраторы предпочитают использовать для хранения скриптов
     отдельную директорию, работая со всеми размещёнными в ней файлами
     по CGI-интерфейсу.
    </simpara>
    <simpara>
     В случае, если невозможно гарантировать, что запросы не перенаправляются,
     как было показано в предыдущем разделе, необходимо указывать
     переменную doc_root, которая отличается от корневой директории веб-документов.
    </simpara>
    <simpara>
     Вы можете установить корневую директорию для PHP-скриптов, настроив
     параметр <link linkend="ini.doc-root">doc_root</link> в
     <link linkend="configuration.file">конфигурационном файле</link>,
     либо установив переменную окружения <envar>PHP_DOCUMENT_ROOT</envar>.
     В случае, если PHP используется посредством <acronym>CGI</acronym>,
     полный путь к открываемому файлу будет построен на основании
     значения переменной <parameter>doc_root</parameter> и указанного
     в запросе пути. Таким образом, вы можете быть уверены,
     что скрипты будут выполняться только внутри указанной вами директории
     (кроме директории <parameter>user_dir</parameter>, которая описана ниже).
    </simpara>
    <simpara>
     Ещё одна используемая при настройке безопасности опция -
     <link linkend="ini.user-dir">user_dir</link>. В случае, если
     переменная user_dir не установлена, путь к открываемому файлу
     строится относительно <parameter>doc_root</parameter>. Запрос
     вида <filename role="url">http://my.host/~user/doc.php</filename>
     приводит к выполнению скрипта, находящегося не в домашнем каталоге
     соответствующего пользователя, а находящегося в подкаталоге doc_root
     скрипта <filename role="uri">~user/doc.php</filename> (да, имя
     директории начинается с символа <literal>~</literal>).
    </simpara>
    <simpara>
     Но если user_dir установлена, например, в значение
     <filename role="dir">public_php</filename>, то запрос вида
     <filename role="url">http://my.host/~user/doc.php</filename>
     откроет файл <filename>doc.php</filename>, находящийся в
     домашнем каталоге пользователя, в директории <filename role="dir">public_php</filename>.
     Например, если домашний каталог пользователя <filename role="dir">/home/user</filename>,
     будет выполнен файл <filename>/home/user/public_php/doc.php</filename>.
    </simpara>
    <simpara>
     Установка опции <parameter>user_dir</parameter> происходит
     независимо от установки <parameter>doc_root</parameter>,
     таким образом вы можете контролировать корневую директорию веб-сервера
     и пользовательские директории независимо друг от друга.
    </simpara>
   </sect1>

   <sect1 xml:id="security.cgi-bin.shell">
    <title>Вариант 4: PHP вне дерева веб-документов</title>
    <para>
     Один из способов существенно повысить уровень безопасности - поместить
     исполняемый модуль PHP вне дерева веб-документов, например в <filename
     role="dir">/usr/local/bin</filename>. Единственным недостатком такого подхода
     является то, что первая строка каждого скрипта должна иметь вид:
     <informalexample>
      <programlisting>
<![CDATA[
#!/usr/local/bin/php
]]>
      </programlisting>
     </informalexample>
     Также необходимо сделать все файлы скриптов исполняемыми. Таким образом,
     скрипт будет рассматриваться так же, как и любое другое CGI-приложение,
     написанное на Perl, sh или любом другом скриптовом языке, который использует
     <literal>#!</literal> в начале файла для запуска самого себя.
    </para>
    <para>
     Для корректной обработки PHP переменных
     <envar>PATH_INFO</envar> и <envar>PATH_TRANSLATED</envar>
     директива ini <link linkend="ini.cgi.discard-path">cgi.discard_path</link> должна быть включена.
    </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
-->