| Мои закладки |
|
|
|
Безопасная настройка PHP и MySQL.
Итак, начнем с настройки: Вопрос настройки PHP и MySQL, а особенно PHP, хотя и не представляет никакой сложности, довольно часто вызывает определенные проблемы у неподготовленного (или ленивого) человека. Более того, до сих пор встречаются платные (!) хостинг-провайдеры, которые неправильной настройкой PHP ставят под угрозу не только ресурсы своих клиентов, но и собственный бизнес. Причина такого отношения к этому простому вопросу нам не понятна. Однако перейдем к настройке. Большинство интересующих нас настроек PHP расположены в файле php.ini (основной файл конфигурации). Для win-систем искомый файл, как правило, расположен в c:\windows\. Для *nix-систем расположение php.ini может варьироваться в зависимости от установленного дистрибутива и других настроек (довольно часто /etc/php.ini). В конфигурации PHP нас интересуют следующие установки, категорически влияющие на уровень безопасности. Все они подробно описаны в соответствующей литературе, но мы рассмотрим их с точки зрения наших интересов: safe_mode = On | Off Безопасный режим PHP. Если он включен (On), интерпретатор не под каким предлогом не будет выполнять системные команды, не сможет обратиться к удаленному хосту, большинство функций работы с файлами будут ограничены . Казалось бы, что это довольно неплохое, хоть и частичное, решение проблемы безопасности. Однако, все те ограничения, которые накладывает включенный безопасный режим, не позволяют реализовать большинство функций, необходимых для практически любого серьезного ресурса. А если нам нужна работа с удаленными хостами, upload или полноценная работа с файлами? Получается, что у нас нет выбора, и придется не использовать безопасный режим в большинстве случаев. По этой причине мы опускаем остальные параметры safe_mode_*. open_basedir =[путь к директории] Установка каталога, выше которого PHP-скрипт не имеет доступа. В зависимости от условий размещения и конфигурации сервера, параметр может быть полезен. Напомним, что ограничения, указанные в .htaccess Apache, не распространяются на PHP. Следовательно, open_basedir может пригодиться для изоляции области файловой активности PHP-скриптов в необходимых нам пределах. Наиболее актуально на выделенных серверах, так как на виртуальных все уже сделано до нас :) disable_functions =[функция 1], [функция 2], : , [функция n] Запрещает выполнение в скриптах перечисленных функций. Довольно важный параметр. Единственный совет, который можно дать: проанализируйте код Вашего ресурса и отключите данным параметром все критические функции, которые не используются. disable_classes =[класс 1], [класс 2], : , [класс n] Запрещает перечисленные классы. Уровень риска чуть меньше, чем в случае disable_functions, но рекомендации аналогичны. max_execution_time = [время в секундах] Максимальное время, которое может выполняться скрипт с момента запуска. Опять-таки важно знать для чего будет использоваться сервер. Если задач, вроде обработки/шифрования/вывода больших объемов данных или огромных баз не предвидеться, достаточно 15-30 сек. max_input_time = [время в секундах] Максимальное время, которое скрипт может 'принимать' данные из вне (например POST или GET запросы). Если не собираемся аплоадить на сервер большие файлы и принимать другие объемные данные, достаточно 30-90 сек. memory_limit = [объем в байтах] Размер памяти, выделяемый для каждого запущенного скрипта. По умолчанию установлен в 8Mb. Как правило, для большинства задач вполне хватает 8-16 Mb. При наличии сложного или высокопосещаемого ресурса подбирается методом проб и ошибок :) error_reporting = E_ALL | E_ERROR | E_WARNING | : Уровень сообщений об ошибках. Описание значений есть в самом php.ini Собственно, каждый разработчик ставит как ему удобно. Главное, чтобы следующий параметр ВСЕГДА был выключен при реальной работе приложения. display_errors = On | Off Отображение возникающей ошибки прямо в вывод скрипта. Это означает, что конечный пользователь увидит сообщение об ошибке прямо в собственном браузере. Такой подарок не пропустит не один злоумышленник. Вывод: при отладке, скорее всего On, при реальной работе ВСЕГДА OFF. Ресурсов, где при подаче корявого GET или POST запроса на 'вход' скрипту, он рассказывает в сообщении об ошибке столько данных, что дух захватывает, больше, чем нормально работающих. register_globals = On | Off Многострадальный параметр, который был включен в ранних версиях PHP по умолчанию. Начиная с PHP 4.2.0 register_globals по умолчанию выключен. И он должен быть выключен ВСЕГДА, если речь идет о реальной работе, а не отладке. При включенном параметре все переменные, переданные скрипту в запросах, автоматически регистрируются под своими именами. Это означает, что при запросе вроде test.php?Var='123', на момент запуска скрипта test.php в нем будет уже задана переменная $Var = '123'. Если эта переменная используется в коде, и, по каким-то причинам, не обнулена, кто угодно может нарушить работу программы. В случае, если register_globals=Off, все входящие данные будут расположены с соответствующих массивах и не пересекутся с переменными самого кода, пока этого не захочет сам разработчик. Безусловно, 'вытаскивать' входящие переменные из массивов несколько неудобно, но это более чем сносная плата за отсутствие такой дыры. post_max_size = [объем в байтах] Максимальный размер POST-запроса. Как правило, устанавливается равным максимальному объему предполагаемого к аплоаду файла. Если файлы загружать на сервер нет необходимости, вполне подойдет размер около 1Mb или даже меньше. magic_quotes_gpc = On | Off magic_quotes_runtime = On | Off Эти два параметра определяют статус автоматического экранирования специальных символов во внешних запросах и внутренних данных, соответственно. Очень важные, с точки зрения обеспечения безопасности, параметры. Так, если magic_quotes_gpc=Off, при запросе test.php?Var='Test'Crack'' переменная (как мы помним, обязательно взятая из $HTTP_GET_VARS['Var'], так, как register_globals у нас отключен) будет передана как есть. К чему приведет попытка в скрипте выборки в базе данных по составленной определенным образом переменной, содержащей специальные символы, объяснять смысла нет. Если же magic_quotes_gpc=On, все спец. символы будут экранированы обратным слешем. Наша переменная будет иметь вид 'Test\`Crack\`', что не представляет опасности для атак типа MySQL-Injection. Безусловно, существует масса способов проверить входящие данные перед использованием, и мы обязательно о них поговорим, но перестраховка, в данном случае не помешает. Вывод: если есть возможность включить magic_quotes_gpc, обязательно включаем. allow_url_fopen = On | Off Довольно весомый параметр. Позволяет использовать в качестве имени файла URL-адрес. Если ваш ресурс не испытывает необходимости в работе с удаленными файлами, отключаем. Если работа из скрипта необходима, можно воспользоваться специальными функциями PHP для работы с требуемыми протоколами или включить allow_url_fopen, что автоматически повысит требования к проверке внешних данных. Вот, собственно, мы и поговорили о тех настройках PHP, которые достаточно ощутимо влияют на общую безопасность выполнения скриптов. Надеемся, что помогли разработчикам освежить в памяти базовые параметры настройки PHP с прицелом на безопасность. С уважением, и наилучшими пожеланиями, Группа разработки WebDev Systems. http://www.webdevsystems.ru |
|
 Каталог | Мои закладки | О проекте | Правила | Регистрация | Карта каталога | Контакты |
|
