Назад | Перейти на главную страницу

Защита веб-серверов PHP

У приложений PHP есть репутация проблем с безопасностью выше среднего. Какие методы настройки вы используете для обеспечения максимальной безопасности приложения?

Я ищу такие идеи, как:

Обычно я использую Linux, но не стесняйтесь предлагать и решения для Windows.

  1. Используйте директиву open_basedir, чтобы ограничить ваши сценарии PHP их домашним каталогом и возможными дополнительными каталогами приложений. Это очень эффективно само по себе.

  2. Используйте усиленный php, потому что это ничего не стоит и может помочь.

  3. Использовать suPHP чтобы скрипты PHP выполнялись как владелец файла (один пользователь на веб-сайт) и избегали использования файлов с плохими разрешениями, такими как 777 ... suPHP также может позволить вам иметь php.ini на каждом веб-сайте, чтобы глупое требование одного сайта не не разрушить все.

  4. Mod_security - большой плюс, но его нужно правильно использовать и настраивать.

Другие параметры, которые следует изменить, чтобы укрепить PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Сохранять все ошибки PHP в файле /var/log/phperror.log:

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

По моему опыту, большинство уязвимостей на веб-сайтах на основе PHP является результатом плохого дизайна (сайта), а не недостатков самого PHP.

Несколько быстрых советов:

  • Универсально вход фильтра, выход escape. Clarificaiton: фильтр не означает побег, это означает, что «если я обнаружу что-то подозрительное в этом вводе пользователя, вызовет сбой отправки и скажет пользователю переформатировать».
  • Вместо использования escapeshellcmd () просто не разрешать выполнение любого пользовательского ввода в оболочке. Это опасно и, вероятно, никогда не понадобится.
  • Не надо вызывать такие функции, как phpinfo () на рабочем сайте (или, если да, см. ниже *).
  • При разработке веб-приложения всегда подумайте, "это возможный вектор атаки?" Скажем, SQL-инъекция. Если ответ «да», подключите его немедленно - не говорите «хорошо, я добавлю это позже в процессе разработки в качестве функции». Безопасность никогда не бывает особенной.
  • Никогда выводить пользователю необработанные ошибки; это означает установку display_errors = Off в php.ini, log_errors = On. Ловите ошибки времени выполнения и выводите что-нибудь красивое. Возьмем, к примеру, кита Twitter: он не предоставляет пользователю информацию на уровне отладки, он просто говорит: «Что-то сломалось, обновите, пожалуйста».

* Вы также можете взглянуть на небольшой пост, который я написал, под названием «Защита phpinfo (), вроде того», и обязательно прочтите комментарии http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Это была быстрая идея, и мне пришлось (отчасти) защитить phpinfo (), если я как-то забыл удалить ее на рабочем сайте.

В более общем плане некоторые разработчики пишут оболочки для чувствительных функций, которые проверяют, установлен ли флаг «производственный сайт», и отключают чувствительную функцию в производственной среде.

Рассмотрите возможность настройки open_basedir по принципу «на сайт». open_basedir - это параметр php.ini, который предотвратит доступ ваших скриптов к файлам за пределами определенного белого списка. Если на вашем сервере размещено несколько сайтов, это предотвратит чтение одним сайтом настроек базы данных с другого сайта. Это также предотвратит доступ / изменение основных системных файлов php-скриптом. Open basedir легко настроить, просто добавьте строку "php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list"каждому хосту Apache.

Также рассмотрите возможность отключения механизма сценариев PHP для всех сайтов / папок, которые не должны содержать сценарии PHP (например, для папки с загруженными изображениями). Опять же, это просто, добавьте «php_admin_value engine off» к любому виртуальному хосту Apache, не нуждающемуся в php. Чтобы отключить PHP в каталоге, поместите то же самое в тег Directory.

Максимально ограничьте права доступа к файлам, избегайте доступа на запись к сценариям PHP для пользователя Apache, это предотвращает изменение запущенного сценария или других сценариев на том же сайте / сервере. По возможности избегайте разрешений 777, выясните минимальные разрешения, необходимые для запуска приложения, и используйте их.

Если вы размещаете несколько сайтов, каждый со своей собственной базой данных, используйте отдельного пользователя MySQL / Postgres для каждого и установите разрешения для каждого пользователя, чтобы они имели доступ только к соответствующим базам данных. Опять же, это предотвратит несанкционированный доступ сценария к базе данных другого приложения.

Suosin, HardenedPHP, mod_security и подобные тоже полезны, но используйте их в дополнение к жестко заблокированной конфигурации, а не вместо.

Я добавил dotdeb репозитории в ваш /etc/apt/sources.list

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Поскольку они исправляют php / apache / mysql гораздо чаще, чем Debian.

Suhosin имеет довольно существенную стоимость производительности, поэтому комментарий «ничего не стоит» немного не так.

Вам нужны базовые предложения по брандмауэру / топологии? Мне нравится идея использовать такие вещи, как фунт для предотвращения прямого доступа к веб-серверу PHP из немытых интернет-сетей. Таким образом вы также можете отделить веб-сервер от других частей вашей сети.

Использование Suhosin / mod_security / SuPHP, безусловно, обезопасит ваш PHP-сервер. Отключение некоторых функций, таких как exec, passthru, system и escapeshellcmd, тоже очень поможет.