Безопасность PHP - мощный язык и интерпретатор, независимо от того, включен ли он в веб-сервер как модуль или выполняется как разделение исполнимых файлов(binary) CGI, он может иметь доступ к файлам, выполнять команды и открывать сетевые соединения на сервере. Эти свойства дают возможность выполнять что-нибудь на веб-сервере небезопасное по умолчанию. PHP разработан специально для того чтобы быть более безопасным языком для написания программ CGI, чем Perl или C. С правильным выбором compile-time и runtime опций конфигурации он дает вам как раз ту комбинацию свободы и безопасности, которая вам нужна. Как есть много разных путей использования PHP, есть и большой выбор конфигураций, управляющих поведением PHP. Большой выбор опций гарантирует, что вы можете использовать PHP для многих целей, но это также означает что есть комбинации этих опций и, также, конфигураций сервера, которые заканчиваются небезопасной установкой. Эта глава объясняет различные комбинации опций конфигурации и ситуации, в которых они могут быть удачно использованы. Возможные атаки Использование PHP как исполнимых файлов CGI - выбор для установок, которые по некоторой причине не хотят внедрить PHP как модуль в программное обеспечение сервера (подобно Apache), или PHP будет использоваться с другими типами оболочек CGI, чтобы создать надежное окружение chroot и setuid для сценариев. Эта установка обычно включает установку выполняемого(binary) PHP в каталог cgi-bin на веб-сервере. Бюллетень CERT CA-96.11 рекомендует кроме того, устанавливать любые интерпретаторы в cgi-bin. Даже если исполнимый PHP может быть использован в качестве автономного интерпретатора, PHP разработан для того чтобы предохранить от атаки, которую эта установка делает возможной: Доступ к системным файлам: http://my.host/cgi-bin/php?/etc/passwd Информация запроса в url после знака вопроса (?) проходит как аргументы командной строки интерпретатору через интерфейс CGI. Обычно переводчики открывают и выполняют файл указанный как первый аргумент в командной строке. Вызванный как исполняемый CGI-файл, PHP отказывается интерпретировать командные аргументы строки. Доступ к любым веб-документам на сервере: http://my.host/cgi-bin/php/secret/doc.html Часть URL с информацией о пути, стоящая после имени PHP-файла, /secret/doc.html обычно используется, чтобы определить имя файла, который должен открываться и интерпретироваться CGI программой. Обычно некоторые директивы конфигурации веб-сервера(Apache: Action) используются, чтобы перенаправить запросы к документам подобно http://my.host/secret/script.php3 на PHP интерпретатор. С такой установкой веб-сервер сначала проверяет разрешения доступа в каталоге /secret , и потом создает запрос перенаправления http://my.host/cgi-bin/php/secret/script.php3 . К несчастью, если запрос не дается изначально в этой форме, веб-сервер не проверяет доступ к файлу /secret/script.php3 , но только для файла /cgi-bin/php . Таким образом любой пользователь, имеющий доступ к /cgi-bin/php , получает доступ к любым защищенным документам на сервере. В PHP, опция compile-time конфигурации --enable-force-cgi-redirect и директивы runtime-конфигурации doc_root и user_dir может использоваться для того чтобы отразить эту атаку, если дерево документов сервера имеет любые директории с ограничениями доступа. Смотрите ниже для полного объяснения других комбинаций. Вариант 1: обслуживаются только общие(public) файлы Если ваш сервер не имеет какой-либо информации, которая не ограничивается паролем или управлением доступом на основе ip, нет потребности в этих опциях конфигурации. Если ваш веб-сервер не позволяет вам производить перенаправление, или сервер не имеет пути, чтобы связаться с исполнимым PHP, который запрашивает благополучно перенаправленный запрос, вы можете указать опцию --disable-force-cgi-redirect для конфигурирования сценария. Вы все еще должны убедиться, что ваши сценарии PHP не полагаются на этот или другой путь вызова сценария, ни непосредственно http://my.host/cgi-bin/php/dir/script.php3, ни переадресацией http://my.host/dir/script.php3. Перенаправление может быть сконфигурировано, например в Apache, директивами AddHandler и Action (см. ниже). Вариант 2: использование --enable-force-cgi-redirect Эта compile-time опция предохраняет от вызова PHP напрямую с URL подобно http://my.host/cgi-bin/php/secretdir/script.php3. Вместо того чтобы выполнить запрос, PHP выполняет только грамматический разбор в этом способе если он выполнил правила перенаправления вебсервера. Обычно переадресация в конфигурации Apache сделана со следующими директивами: Action php3-script /cgi-bin/php AddHandler php3-script .php3 Эта опция была протестирована только с веб-сервером Apache, и полагается на Apache чтобы установить не-стандартную внешнюю переменную CGI REDIRECT_STATUS для перенаправленных запросов. Если ваш сервер паутины не поддерживает какого-либо способа сообщать что запрос прямой или перенаправленный, Вы не можете использовать эту опцию и Вы должны использовать один из других путей запуска версии CGI, документированной здесь. Вариант 3: установка doc_root или user_dir Размещение активного содержания, такого как скрипты и модули, в каталогах документов веб-сервера иногда является небезопасной практикой. Если при некоторой ошибке конфигурации сценарии не выполняются, они отображаются как обычные HTML документы, что может закончиться утечкой интеллектуальной собственности или информации безопасности подобно паролям. Поэтому многие сисадмины предпочитают устанавливать другие каталоги для сценариев, которые будут доступны только через PHP CGI и, следовательно, всегда проинтерпретированы и не отображены как таковые. Также, если недоступен метод перенаправления неуверенных запросов, как описано в предыдущем разделе, необходимо установить корневой каталог(doc_root) сценариев, который отличается от корневого каталога веб-документов. Вы можете установить корневой каталог для скриптов директивой конфигурации doc_root в файле php3.ini , или вы можете установить переменную окружения PHP_DOCUMENT_ROOT. Если это установлено, CGI-версия PHP всегда будет добавлять doc_root и путь к файлу в запросах, так что вы всегда будете уверенны что за пределами этого каталога скрипты выполняться не будут (кроме user_dir //см.ниже). Другая используемая опция - user_dir. Когда user_dir - не установлена, открытием файла управляет только doc_root. Открытие URL подобно http://my.host/~user/doc.php3 не даст результата при открытии файла из каталога пользователя, но вызывается файл ~user/doc.php3 из каталога doc_root (да,имя каталога начинается с тильды [~]). Если user_dir установлена, например как public_php, запрос, подобный http://my.host/~user/doc.php3 откроет файл doc.php3 в каталоге public_php домашнего каталога пользователя. Если это /home/user, то выполняется /home/user/public_php/doc.php3. user_dir задается независимо от doc_root, так что вы можете контролировать доступ к document root и user directory отдельно. Вариант 4: PHP синтаксический анализатор вне дерева web Очень безопасная опция должна установить синтаксический анализатор PHP где-нибудь вне дерева файлов web. В /usr/local/bin, например. Обратная сторона этой опции заключается в том что вы должны вставлять строку подобно: #!/usr/local/bin/php в первую строку любого документа, содержащего PHP тэги. Кроме того, вы должны сделать файлы выполнимыми. Точно так же, как Вы поступаете с любым другим сценарием CGI записанным в Perl или sh или любом другом языке, который использует #! shell-escape механизм для самозапуска. Чтобы PHP получил возможность корректно оперировать с PATH_INFO и PATH_TRANSLATEDпри такой установке, php анализатордолжен быть скомпилирован с опцией конфигурации --enable-discard-path <<<  Назад  1  2  3  4  5   8  Комментарии к статье  8 8  Обсудить в чате

8  В тему Введение в PHP3 Возможности PHP3 Установка Синтаксис и грамматика Элементы языка Выражения Справочник функций