Які недоліки використання коду фільтра PHP у блоках, вузлах, аргументах перегляду тощо?


96

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

Наскільки я розумію, це створює потенційний ризик для безпеки, особливо в руках кінцевих користувачів або людей, які не знайомі з Drupal або PHP, але як розробник / розробник сайтів, які реальні причини не використовувати користувальницький PHP від ​​інтерфейсу Drupal?


1
Як завжди, це залежить від ситуації! Якщо вам просто потрібен основний блок $ print у нижній частині сторінки "Views" ("Footer Views"), може бути ідеально просто зробити це через gui порівняно з написанням цілого цілого файлу tpl саме для цієї мети. Це, звичайно, також залежить від ролі сайту та інших факторів. Сайт спільноти користувачів? Або просто інформаційний сайт? Це життєво важливо для ділових операцій? тощо ... залежить.
Патоші パ ト シ

Відповіді:


129

Деякі причини:

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

Причин може бути більше, але цього має бути достатньо :)


3
Хороший список :), сподіваємось, буде ресурсом для інших
Laxman13,

3
@ Laxman13: "іншим" ... і для тебе теж! : D @Berdir: +1, дуже хороші аспекти. До речі, не потрібно писати весь код у текстове поле, оскільки ви також можете туди включити файл. Наприклад, ви можете помістити лише один рядок у текстове поле: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';а решту коду записати у свій редактор IDE / текст. Іноді це непроста робота або знадобиться дуже багато часу, щоб створити власний модуль навіть як хороший PHP-розробник. Один короткий приклад: умовні дії Ubercart. Але це правда, що не дуже добре тримати наш код у db.
Sk8erPeter

Я маю на увазі, наприклад, модуль UC Conditional Actions має дуже чудовий графічний інтерфейс, який економить багато часу від необхідності писати наші власні довгі коди. Ви можете створити дійсно складну дію за лічені хвилини методом "наступний-наступний фініш" на графічному інтерфейсі. Але, можливо, ви хочете розширити свою функціональність деякими власними кодами - у багатьох випадках розробляти модуль для цієї мети просто не варто.
Sk8erPeter

1
+1000 - Я так бачив, так багато проектів спалили майже кожну кулю в цьому списку. В моєму житті був один раз, що використання модуля PHP було єдиним способом зробити щось розумним, і це було лише через проблему з D6, яка була виправлена ​​в D7.
geerlingguy

Дякуємо за вашу детальну відповідь на це питання. Під час роботи в Drupal я виявив, що коли нам потрібно додати посилання у текстовому редакторі, нам потрібно використовувати php-код у текстовому фільтрі, інакше він не працюватиме, як очікувалося.
Jayendra Kainthola

17

Цей код важко налагоджувати та підтримувати. Я не знаю жодного способу використання управління версіями для такого роду php-коду.

І це справді потенційний ризик для безпеки для людей, які є новими в Drupal чи PHP,


1
Добре, якщо конфігурація блоку, експортованого до коду з модулями функцій, це не проблема поставити фрагменти php під контроль версій.
ya.teck

14

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

Як правило, цього краще уникати, eval()оскільки це зменшує читабельність коду, можливість передбачити шлях коду (і можливі наслідки для цього) перед виконанням, а отже, і можливість налагодження коду.

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

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


11

Як вирішення різних проблем, зазначених вище - складність обслуговування коду, контроль версій, пошук помилок, у вас є така дещо "клуге" можливість:

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

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

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


11

Ось причина вразливості безпеки, щоб уникнути надання цього дозволу своїм користувачам, якщо ви не хочете, щоб ваші користувачі, які не є адміністратором, змінювали db безпосередньо.

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

Злом облікових даних Drupal db


7

Замість того, щоб робити щось подібне return functionname($object), краще використовувати систему жетонів / фільтрів, наскільки це можливо. Є такі модулі, як "Вставити перегляд" та "Вбудувати вузол", які можуть допомогти у загальних обставинах, за яких люди хочуть вбудувати PHP у вузли чи блоки блоків.


0

Вам слід подбати про переносимість своїх даних. Що робити, якщо ви переміщуєте свої вузли з drupal 7 до drupal 8, а текст тіла якогось вузла є <?php whatever_function_that_does_not_exist_anymore(); ?>в ньому?

Не думайте про свій проект протягом 5 місяців, але протягом 5 років. Оновлення, передовий досвід та портативність - це, на мою думку, важливі аспекти будь-якого хорошого ІТ-проекту.

Використання якомога менших модулів також є одним із аспектів цього.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.