Вы знаете, что вы можете заставить сервер анализировать HTML-страницы как PHP (выполнить PHP-код в HTML-документе), используя .htaccess?
Ну, некоторые люди говорят, что это плохо. Зачем?
Некоторые люди также говорят, что это открывает уязвимость в вашем приложении. Как?
Исходный код все еще удаляется до того, как документ достигнет браузера, так что это не может быть случай несанкционированного доступа к исходному коду, правильно?
Позвольте мне начать с небольшой истории: назад, когда я был контакт с безопасностью у поставщика дистрибутива Linux, команда безопасности PHP попросила поставщиков Linux прекратить вызов интерпретаторов ошибок безопасности, даже когда интерпретатор PHP выполнялся внутри веб-сервера (скажем, mod_php на Apache). (В то время примерно одна ошибка переводчика была найдена в неделю.)
Для них потребовалось немного разговора, чтобы на самом деле убедить нас в том, что тот, кто поставил исполняемый PHP-код, полностью доверен, и любая попытка контролировать то, что скрипты могут сделать из интерпретатора, была ошибочной - и если кто-то выяснил, как вытащить интерпретатора, чтобы обойти ограничения, которые он пытался наложить (например, целая глуповатая безопасная куча дерьма), это не был недостаток безопасности, потому что безопасное выполнение сценариев не было целью интерпретатора PHP - он никогда не был и никогда не был бы.
На самом деле я доволен конечным результатом обсуждений - четко определены цели безопасности PHP: вы должны только разрешать выполнение PHP-кода, которому вы полностью доверяете 100%. Если вы не доверяете ему, вы его не запускаете. Это просто.
Независимо от того, доступны ли операционные ресурсы для интерпретатора для всех доступных и честных игр, независимо от того, использует ли script ошибку в интерпретаторе или просто делает что-то неожиданное.
Итак, не позволяйте случайному коду исполняться в контексте вашего веб-сервера, если это не то, что вы действительно хотите.
Используйте принцип наименьших привилегий, чтобы указать, какие ресурсы доступны для каждой программы.
Рассмотрите возможность использования средства обязательного контроля доступа, например AppArmor, SELinux, TOMOYO или SMACK, чтобы ограничить то, что ваши программы могут и чего не могут сделать. Я работаю над проектом AppArmor с 2001 года или около того, и довольно уверен, что с ежедневными усилиями большинство системных администраторов могут существенно улучшить безопасность своих сайтов с помощью AppArmor. Оцените несколько вариантов, так как различные инструменты разработаны вокруг разных моделей безопасности - тот или иной вариант лучше подходит.
Но что бы вы ни делали, пожалуйста, не запускайте свой сервер таким образом, что он бесполезно открывает его для атаки через дополнительные векторы.
Основная проблема заключается в том, что если вы когда-либо перемещаете свой код на другой сервер или позволяете кому-то работать с вашим кодом, настройками сервера или .htaccess, ваши html-страницы могут перестать анализироваться с помощью интерпретатора PHP.
В этом случае PHP-код будет обслуживаться до браузера.
Уязвимость существует из-за того, что если вы это делаете, файлы HTML действительно являются файлами PHP, поэтому их загрузка должна восприниматься так же серьезно, как и загрузка файлов PHP. Часто люди не видят, что загрузка HTML файлов является большой сделкой, именно потому, что они не ожидают, что они будут настроены на синтаксический анализ как PHP (так что другие в вашей компании могут непреднамеренно открыть дыру в безопасности). [PaulP.R.O. ответьте, что проблема безопасности также может возникнуть в обратном направлении - из-за того, что PHP ошибочно принимается за HTML позже, когда этот параметр ошибочно удаляется.]
Там также немного проблема с производительностью, поскольку каждый HTML файл затем должен запускаться через парсер PHP (даже если он не содержит PHP).
Анализ HTML как PHP является плохим (ish) для скорости и причин организации.
Что касается остальной части вашего комментария, я не уверен в аспекте безопасности, но я думаю, что смешивание вашего HTML и выхода PHP может привести к незаметным уязвимостям XSS? Не эксперт, когда дело доходит до этого.
Это плохо для скорости, и если PHP-интерпретатор не работает по какой-либо причине, PHP-код появится в источнике страницы. Если у вас есть, например, имя пользователя и пароль базы данных в коде PHP, любой может легко и легко подключиться к вашей базе данных.
И как сказал Зэд, это плохо по организационным причинам. Вместо обновления одного файла вам нужно будет обновить все файлы на вашем сайте, чтобы внести простые изменения.
Разрешая серверу анализировать HTML файлы, поскольку PHP показывает, что вы не используете шаблоны проектирования приложений. Это значит, что вы пылаете своим собственным путем, а не делаете что-то рекомендуемым способом. Существует причина, по которой существуют проекты, подобные MVC (которые разделяют проблемы).
Одной из проблем с возможностью прямого вызова произвольных документов является потеря "переднего контроллера" (обычно index.php), который помогает свести количество дверных проемов в ваше приложение.
В ваше приложение может быть много путей, но у вас есть еще много возможных маршрутов атаки, которые вы должны учитывать в своих проектах.