безопасность — Использование встроенного сервера PHP в производстве
Недавно мне было интересно узнать о встроенном веб-сервере в PHP 5.4. На первый взгляд кажется, что, хотя и довольно скромно, при достаточной работе можно было бы распространять приложения PHP, которые традиционно зависят от отдельного веб-сервера, такого как WordPress, в виде автономных сценариев, с которыми можно просто работать php -S localhost:80 app.php (или, более вероятно, './wordpress.sh'). Они могут даже поставляться со своим собственным интерпретатором PHP, который обладает всеми функциями, необходимыми приложению, что избавит от необходимости ориентироваться на множество различных версий языка.
Он несколько изобретает колесо, но, несомненно, увеличит портативность и снизит сложность для конечного пользователя.
Тем не менее, я видел следующее на страница документации:
Этот веб-сервер был разработан, чтобы помочь разработке приложений. Это также может быть полезно для целей тестирования или для демонстрации приложений, которые запускаются в контролируемых средах. Он не предназначен для полнофункционального веб-сервера. Он не должен использоваться в публичной сети.
Это, очевидно, относится к таким вопросам, как правильная защита файловой системы и обслуживание правильных заголовков HTTP, которые можно решить. Однако есть ли что-то еще? Существуют ли присущие безопасности проблемы и / или технические ограничения при использовании встроенного веб-сервера PHP в производственной среде, с которым невозможно обойтись? Если так, то кто они?
Решение
Я могу думать о множестве операционных проблем, почему вы не хотите делать это:
- логирование
- Перезапись
- Дроссельный
- Эффективность (не проверено, но я предполагаю, что Nginx намного быстрее, чем встроенный неоптимизированный сервер PHP)
- Интеграция со всем, что у вас есть, которое расширяет Nginx, Apache и IIS (например, New Relic)
Тем не менее, есть решение, в котором вы получаете большую часть преимуществ от использования PHP со встроенным веб-сервером, в то же время получая большую часть преимуществ от запуска веб-сервера. То есть вы можете использовать сервер, такой как Nginx, в качестве обратного прокси-сервера для встроенного веб-сервера PHP. В этой ситуации HTTP становится заменой FastCGI, аналогично обычному использованию встроенного HTTP-сервера в приложениях Node.js.
Теперь я не могу говорить со спецификой предупреждения в документации, так как я не являюсь одним из авторов PHP. Если бы это был я, я бы не запускал PHP один по вышеуказанным причинам, но я может быть рассмотрите возможность запуска его на реальном веб-сервере, таком как Nginx. Для меня, однако, настройка PHP с PHP-FPM и то, что не так уж сложно, и я возьму на себя предположение о мореходности встроенного сервера, который, как задокументировано, предназначен только для тестирования.
Другие решения
Проблема со встроенным веб-сервером PHP в том, что он однопоточный!
Это влияет на производительность и безопасность. Очевидно, что производительность влияет на то, что одновременно может обслуживаться только один пользователь (пока не закончится один запрос, другой не сможет запуститься).
Безопасность подразумевает, что DOS-сервер довольно легко использовать с помощью простого открытого сокета, который отправляет крошечные объемы данных (аналогично Slow Loris).
Это полезно для простых одностраничных неинтерактивных приложений, в которых нет риска отказа в обслуживании.
Встроенный сервер PHP поддерживает только HTTP / 1.0, что означает, что клиенты должны создавать новое соединение TCP / IP для каждого запроса. Это очень медленно.
Он не предназначен для производственного использования и не может корректно обрабатывать сбои и утечки памяти, что вызывает проблемы со стабильностью. Что еще более важно, сам PHP предупреждает об этом явно:
Предупреждение Этот веб-сервер был разработан, чтобы помочь разработке приложений. Это также может быть полезно для целей тестирования или для демонстрации приложений, которые запускаются в контролируемых средах. Он не предназначен для полнофункционального веб-сервера. Он не должен использоваться в публичной сети.