Каковы недостатки использования кода PHP Filter в блоках, узлах, представлениях-аргументах и ​​т. Д.?

Я видел много раз людей, говорящих о том, чтобы не использовать собственный PHP /PHP-фильтр (из пользовательского интерфейса Drupal) в блоках, узлах, представлениях-аргументах, правилах и т. д. Я немного искал и не нашел многого, похоже, что это лучшая практика Drupal, которую все «просто знают».

Я понимаю, что это создает потенциальный риск для безопасности, особенно в руках конечных пользователей или людей, знакомых с Drupal или PHP, но как разработчик /сайт-строитель, каковы реальные причины не использовать пользовательский PHP из пользовательского интерфейса Drupal?

97 голосов | спросил Laxman13 19 PMpTue, 19 Apr 2011 20:08:48 +040008Tuesday 2011, 20:08:48

6 ответов


129

Некоторые причины:

  • Код в вашей базе данных не может контролироваться версией, а также сложнее найти в дальнейшем позже.
  • Код Eval () 'd much медленнее, чем что-то жестко закодированное в файле.
  • Если в этом коде есть ошибка, вы получите очень бесполезное сообщение об ошибке (ошибка в коде eval () 'd в строке 3), и вы даже можете вручную просмотреть свою базу данных, чтобы найти и исправить ошибку , Если он находится внутри блока, который отображается на всех страницах и приводит к фатальной ошибке все время, например.
  • Вышеупомянутое также верно при обновлении с Drupal с 6 по 7 и любых используемых вами API. Таким образом, вам придется переносить свой код во время миграции. Если код находится в модуле, вы можете его перенести заранее, протестировать и развернуть только на новом сайте. Внутри узла или блока он будет работать только с Drupal 6 или 7.
  • Написание и поддержка этого кода также сложнее, потому что вы работаете в текстовом поле внутри вашего браузера. Наличие в модуле позволяет использовать редактор /IDE с подсветкой синтаксиса, автозаполнением и т. Д.
  • Всегда существует вероятность неправильной настройки, которая дает людям доступ к текстовому формату /блоку /независимо от того, что включено при выполнении php. Если php.module (в D7, D6 не является настолько строгим, например, для правил доступа к блокам) даже не включен, этот риск намного ниже.
  • Если ваша CMS позволяет выполнять PHP, то злоумышленник, который обнаруживает уязвимость безопасности XSS или эскалацию привилегий, теперь может использовать ваш сервер для чрезвычайно вредоносных действий (как часть DDOS, отправки спама, размещения вредоносных программ, взлома на другие сайты /базы данных на сервере, взломать другие серверы в сети, которые могут находиться за брандмауэрами). В дополнение к тому, что небольшие уязвимости становятся более болезненными, это делает сайт более вероятным объектом атаки, если известно, что его можно использовать для выполнения php.

Там может быть больше причин, но этого должно быть достаточно:)

ответил Berdir 19 PMpTue, 19 Apr 2011 20:22:23 +040022Tuesday 2011, 20:22:23
17

Этот код трудно отлаживать и поддерживать. Я не знаю, как использовать контроль версий для такого рода php-кода.

И это действительно потенциальный риск для безопасности для людей, знакомых с Drupal или PHP,

ответил ya.teck 19 PMpTue, 19 Apr 2011 20:23:38 +040023Tuesday 2011, 20:23:38
14

Учитывая случай использования фильтра PHP, используемого в узле, причина не в том, что вы ограничиваете пользователей, которые могут редактировать этот узел, если вы не хотите разрешать всем пользователям использовать фильтр PHP.
Вместо использования фильтра PHP лучше использовать настраиваемый модуль, который заменяет определенный текст в содержимом узла результатом выполнения кода (без использования eval()) или который добавляет его собственный текст для содержимого тела узлов. В этом случае любой пользователь мог бы отредактировать узел, не имея права на добавление произвольного PHP-кода, который затем запускается фильтром PHP.

Как правило, лучше избегать eval(), потому что это уменьшает читабельность кода, способность предсказать путь кода (и возможные последствия для безопасности этого) до выполнения, и следовательно, возможность отладки кода.

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

Фильтр PHP был удален из Drupal 8. Теперь он сторонний модуль , которые не рассматриваются в политике безопасности . Вероятно, это причина для того, чтобы не использовать его на производственных серверах (если уже приведенные причины не убедили вас).

ответил kiamlaluno 19 PMpTue, 19 Apr 2011 20:38:19 +040038Tuesday 2011, 20:38:19
11

Как работа для различных проблем, указанных выше - сложность обслуживания кода, контроль версий, обнаружение ошибок, у вас есть эта небольшая возможность «klugey»:

Создайте функции (назовите их тщательно, в соответствии с тем, что они делают) в некотором файле, который всегда включен - если у вас есть настраиваемый модуль, который вы пишете для сайта, это отличное место для размещения этих функций. Php, который вы вводите тогда, просто: return my_specialfunc($somevar); - $somevar здесь потенциально будет работать объект узла или какие-либо другие переменные здесь.

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

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

ответил James 19 PMpTue, 19 Apr 2011 21:27:10 +040027Tuesday 2011, 21:27:10
11

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

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Взлом учетных данных Drupal db

ответил lolcode 5 +04002012-10-05T05:13:22+04:00312012bEurope/MoscowFri, 05 Oct 2012 05:13:22 +0400 2012, 05:13:22
7

Вместо того, чтобы делать что-то вроде return functionname($object), было бы лучше использовать систему токенов /фильтров, насколько это возможно. Существуют такие модули, как Insert View и Embed Node, которые могут помочь с общими обстоятельствами, в которых люди захотят встраивать PHP в узловые или блокирующие тела.

ответил Evan Donovan 10 SatEurope/Moscow2011-12-10T04:02:11+04:00Europe/Moscow12bEurope/MoscowSat, 10 Dec 2011 04:02:11 +0400 2011, 04:02:11

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132