Работа на Drupal и PHP - HookAny.com

Чем вредны PHP сниппеты в CMF/CMS

В комментариях к моей статье Vue.js - реактивный фронтенд фреймворк для людей завязалась бурная дискуссия по поводу моего высказывания о безопасности одного из подходов ModX. Я решил перевести обсуждение проблемы в отдельный пост, чтобы не смущать фронтенд разработчиков дискуссиями о бекенде.

Хочу поблагодарить Дениса Ефремова, который заинтересовал меня в дальнейшем обсуждении и изучении данной темы. У Дениса гораздо больше опыта работы с ModX, поэтому, я надеюсь, он поправит меня при необходимости.

Я могу понять ModX разработчиков, которым могло быть неприятно читать такой мой комментарий:

Редактирование PHP кода через админку - это огромное поле для багов и уязвимостей. Вот это меня и отворачивает от ModX.

Я извиняюсь, если мог кого-то задеть, но это мое личное мнение и оно осознанное.

Сама возможность загрузки исполняемого PHP кода (через сниппеты или иным способом) потенциально опасна. В сниппет можно положить много чего неприятного, например загрузку эксплойта (как в этом видео) или выполнение потенциально опасной команды, например через system().

Давайте немного поразмышляем о том, насколько любой сайт (не только ModX) с такой фичей безопасен:

1) Да, мы исходим из того, что пользователь с правами на заливку сниппетов компетентен. Но после того, как разработчик сделал сайт и ушел, администрировать сайт остаются контент-менеджеры или люди без глубоких технических знаний. Они ищут PHP сниппеты для той или иной задачи в сети и пробуют их прямо на рабочем сайте, авось сработает. Разве способны они сами оценить безопасность портянки кода длинной в 40-50 строк?

2) Да, мы исходим из того, что сайт всегда получает последние обновления безопасности. Но разве можем мы это гарантировать?

3) Да, мы можем ограничить юзера на PHP уровне, запретив выполнение таких функции, как system(), exec() или eval() через PHP конфиг. Но все ли разработчики/администраторы это делают?

4) Да, мы привыкли полагать, что злоумышленник никогда не получит прав на создание сниппетов, ведь ядро системы хорошо протестировано и защищено. А если вдруг один из сторонних компонентов даст сбой и через уязвимость в нем откроет путь в админку, то доступ к PHP коду через менеджер поставит под угрозу не только один сайт, а все сайты на сервере.

У меня, к сожалению, нет коммерческого опыта работы с ModX, но я достаточно долго работал с Drupal и с некоторыми другими фреймворками. Так вот и для Drupal есть модули, которые позволяют сохранить произвольный PHP код в базу данных и выполнить его, например views_php. Но такой подход считается плохой практикой, и из ядра его убрали.

Я приведу цитату из официальной документации, которая подытожить мои мысли:

Through the PHP filter, users with the proper permission may include custom PHP code within a page of the site. While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user. Even a trusted user may accidentally compromise the site by entering malformed or incorrect PHP code. Only the most trusted users should be granted permission to use the PHP filter, and all PHP code added through the PHP filter should be carefully examined before use.

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

В заключении, хочется призвать русскоязычное PHP сообщество к взаимному уважению и эмпатии. Хочется, чтобы мы с вами стали друг к другу немного добрее и снисходительнее. Неконструктивные холивары только лишь съедают время, которое мы могли бы потратить на улучшение наших любимых инструментов.

Evan You quote about tools