Главная > Программирование > РНР: настольная книга программиста
<< Предыдущий параграф
Следующий параграф >>
<< Предыдущий параграф Следующий параграф >>
Макеты страниц

Глава 6. Проблемы безопасности

РНР — мощный язык и интерпретатор. Независимо оттого, включен он в Web-сервер как модуль или выполняется как разделение исполняемых файлов CGI, он может иметь доступ к файлам, выполнять команды и открывать сетевые соединения на сервере. Эти свойства дают возможность выполнять что-либо небезопасное на Web-сервере.

РНР разработан специально для того, чтобы быть более безопасным языком при написании программ CGI, чем Perl или С. При правильном выборе compile-time и runtime-опций конфигурации ондаеткакраз ту комбинацию свободы и безопасности, которая вам нужна.

Существует много разных путей использования РНР, есть также и большой выбор конфигураций, управляющих поведением РНР. Это гарантирует, что вы можете использовать РНР для многих целей, но означает также, что есть комбинации этих опций и конфигураций сервера, которые заканчиваются небезопасной установкой. Эта глава объясняет различные комбинации опций конфигурации и ситуации, в которых они могут быть удачно

В этой главе мы рассмотрим:

• использование РНР как бинарного CGI;

• установка модуля Apache;

• безопасность файловой системы;

• создание VirtualHost с разумными ограничениями безопасности РНР.

6.1. Использование РНР как бинарного CGI

Использование РНР как исполняемых файлов CGI является выбором установок, которые по некоторой причине не хотят внедрить РНР как модуль в программное обеспечение сервера (подобно Apache). Также РНР используют с другими типами оболочек CGI, чтобы создать надежное окружение chroot и setuid для сценариев. В таком случае обычно включается установка выполняемого РНР в каталог cgi-bin HaWeb-сервере. Правила хорошего тона рекомендуют, кроме того, устанавливать любые интерпретаторы в cgi-bin. Исполнимый РНР может быть использован в качестве автономного интерпретатора, но разработан для того, чтобы предохранить от атаки, которую эта установка делает возможной, — доступ к системным файлам: http://my.host/cgi-bin/php?/.../passwd.

Информация запроса в URLпосле знака вопроса (?) проходит как аргументы командной строки интерпретаторучерез интерфейс CGI. Обычно интерпретаторы открывают и выполняют файл, указанный какпервый аргументв командной строке.


ВНИМАНИЕ

Вызванный как исполняемый CGI-файл РНР отказывается интерпретировать командные аргументы строки.


Также установка выполняемого РНР может вызвать доступ клюбым Web-документам на сервере: http://my.host/cgi-bin/php/secret/doc.html. Часть URLc информацией о пути, стоящая после имени PHP-файла (/secret/doc.html), обычно используется, чтобы определить имя файла, который должен открываться и интерпретироваться CGI-программой. Некоторые директивы конфигурации Web-сервера (Apache: Action) используются, чтобы перенаправить запросы к документам подобно http://my.host/secret/script.php на PHP-интерпретатор. С такой установкой Web-сервер сначала проверяет разрешение доступа в каталоге /secret и потом создает запрос перенаправления http://my.host/cgi-bin/php/secret/scrigihp. Если запрос не дается изначально в этой форме, Web-сервер не проверяет доступ кфайлу/secret/script. php, нотолькодля файла /cgi-bin/php. Таким образом, любой пользователь, имеющий доступ к /cgi-bin/php, получает доступ к любым защищенным документам на сервере.


СОВЕТ

В РНР опция compile-time конфигурации enable-force-cgi-redirect и директивы runtime-конфигурации doc_root и user_dir может использоваться для того,

чтобы отразить эту атаку, если дерево документов сервера имеет любые директории с ограничениями доступа. Ниже приведены полные описания других комбинаций.


Если сервер не имеет информации, которая ограничивается паролем или управлением доступа на основе IP, нет потребности в этих опциях конфигурации. Если Web-сервер не позволяет производить перенаправление или не имеет пути, чтобы связаться с исполнимым РНР, который запрашивает успешно перенаправленный запрос, можно указать опцию disable-orce-cgi-redirect для конфигурирования сценария.

Однако нужно убедиться, что ваши сценарии РНР не ссылаются ни на адрес http://my.host/cgi-bin/php/dir/script.php, ни на адрес http://my.host/dir/ script.php.

Перенаправление может быть например в директивами AddHandler и Action (см. ниже).

Использование -enable-force-cgi-redirect

Эта compile-time опция предохраняет от вызова РНР напрямую с URL подобно http: //my.host/cgi-bin/php/secretdir/script.php. Вместо того чтобы выполнить запрос, РНР производит только грамматический разбор в этом способе, если выполнено правило перенаправления Web-сервера. Обычно переадресация в конфигурации Apache сделана со следующими директивами:

Action php-script /cgi-bin/php AddHandler php-script.php

Эта опция была протестирована только с Web-сервером Apache и пользуется поддержкой Apache, чтобы установить нестандартную внешнюю CGI REDIRECT_STATUS для перенаправленных запросов. Если ваш Web-сервер не может сообщать, что запрос прямой или перенаправленный, вы не можете использовать эту опцию и должны использовать один из других путей запуска версии

Установка doc_root или user_dir

Размещение активного содержания, такого как скрипты и модули, в каталогах документов Web-сервера иногда является небезопасным. Если при некоторой ошибке конфигурации сценарии не выполняются, они отображаются как обычные HTML-документы, что может закончиться утечкой интеллектуальной собственности или информации безопасности, например, паролей. Поэтому многие системные администраторы предпочитают устанавливать другие каталоги для сценариев, которые будутдоступны только через РНР CGI и, следовательно, всегда проинтерпретированы.

Если недоступен метод перенаправления неуверенных запросов, как описано выше, также необходимо установить корневой каталог сценариев (doc_root), который отличается от корневого каталога Web-документов.

Вы можете определить корневой каталог для скриптов директивой конфигурации doc_root в файле php.ini или установить переменную окружения php_document_root. В таких случаях CGI-версия РНР всегда будет добавлять doc_root и путь к файлу в запросах, так что вы всегда будете уверены, что за пределами этого каталога скрипты выполняться не будут (кроме user_dir, см. ниже).

Другая используемая опция — user_dir. Когда она не установлена, открытием файлауправляеттолько doc_root. Открытие URL, подобно http://my.host/~user/doc.php, недаст результата при открытии файла из каталога пользователя, но вызывает файл ~user/doc.php из каталога doc_root (имя каталога начинается с тильды [~]).

Если user_dir установлена, например, как public_php, запрос, подобный http://my.host/~user/doc.php, откроет файл doc.php в каталоге public_php домашнего каталога пользователя. Если это /home/user, то выполняется /home/user/public_php/doc.php.

Опция user_dir задается независимо от doc_root, так что вы можете контролировать доступ к document root и user directory отдельно.

Синтаксический анализатор РНР

Безопасная опция должна установить синтаксический анализатор РНР вне корневого каталога, например в /usr/local/bin. Отрицательная сторона этой опции заключается в том, что вы должны вставлять в первую строку любого документа, содержащего PHP-теги, строку подобно:

#!/usr/local/bin/php

Кроме того, вы должны сделать файлы выполнимыми. Точно также, как вы поступаете с любым другим сценарием CGI, писанным на Perl или Shell или любом другом языке, который использует #! shell-escape механизм для самозапуска.

Чтобы РНР получил возможность корректно работать с PATH_INFO и PATH_TRANSLATED при такой установке, PHP-анализатор должен быть скомпилирован с опцией конфигурации — enable-discard-path.

<< Предыдущий параграф Следующий параграф >>
Оглавление