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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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