Які проблеми з безпекою я повинен мати при встановленні FS_METHOD на "direct" у wp-config?

Нещодавно у мене виникла проблема, коли мені не вдалося встановити плагін WP Smush Pro, оскільки у мене відсутні параметри встановлення вручну або встановлення одним клацанням.

Я наткнувся на цю публікацію, яка запропонувала змінити налаштування в wp-config.php. Я додав запропоновані налаштування, однак той, який видається найважливішим:

define('FS_METHOD', 'direct');

Те , що я хотів би знати, які реальні проблеми повинні я навколо установки FS_METHODдля direct? Чи є інші альтернативи встановлення плагіна?

Ось що має говорити в офіційній документації:

FS_METHOD примушує метод файлової системи. Він повинен бути лише "прямим", "ssh2", "ftpext" або "ftpsockets". Як правило, ви повинні змінити це, лише якщо у вас виникли проблеми з оновленням. Якщо ви зміните його, і це не допоможе, змініть його назад / видаліть. За більшості обставин встановлення цього параметра "ftpsockets" буде працювати, якщо автоматично обраний метод не робить.

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

Це якраз те, як я зрозумів ідею файлу API WordPress . Якщо це неправильно, будь ласка, скажіть :)

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

Якщо ви завантажуєте файл за допомогою PHP, користувач linux, який виконує PHP, є його власником. Цей користувач тепер може редагувати, видаляти, виконувати і т.д. файл. Це добре, поки тільки ви є користувачем, який виконує PHP у вашій системі.

Припустимо, ви перебуваєте на "погано" налаштованому спільному хості. Дуже багато людей управляють своїми PHP-сайтами в цій системі. Скажімо, лише один користувач Linux виконує PHP для всіх цих людей. Один з веб-майстрів цього спільного хоста має погані наміри. Він бачить вашу сторінку і визначає шлях до вашої установки WordPress. Наприклад, для WP_DEBUG встановлено значення true та є повідомлення про помилку

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1

"Га!" каже поганий хлопчик. Давайте подивимося, якщо цей хлопець поставив FS_METHODна directі він пише сценарій , як

<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>

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

Ваш сайт зламаний.

Або, як сказано в Кодексі:

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

Який ризик?

На погано налаштованому спільному хості PHP кожного клієнта буде виконуватися як той самий користувач (скажімо, apacheдля обговорення). Ця установка напрочуд поширена.

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

Що це FS_METHOD 'direct'стосується?

Коли WordPress потребує встановлення файлів (таких як плагін), він використовує функцію get_filesystem_method () для визначення способу доступу до файлової системи. Якщо ви не визначитеся, FS_METHODвін обратиме для вас за замовчуванням, інакше він буде використовувати ваш вибір, поки це має сенс.

Поведінка за замовчуванням намагатиметься виявити, чи перебуваєте ви в небезпечному середовищі, як те, що я описав вище, і якщо він вважає, що ви безпечні, він використовуватиме 'direct'метод. У цьому випадку WordPress створюватиме файли безпосередньо через PHP, приводячи їх до належності apacheкористувачеві (у цьому прикладі). В іншому випадку вона повернеться до більш безпечного методу, такого як запрошення на отримання облікових даних SFTP та створення файлів як ви.

FS_METHOD = 'direct'просить WordPress обходити виявлення ризику та завжди створювати файли за допомогою 'direct'методу.

Тоді навіщо використовувати FS_METHOD = 'direct'?

На жаль, логіка WordPress для виявлення середовища ризику є хибною і створює як помилкові позитиви, так і помилкові негативи. Уопс. Тест передбачає створення файлу та переконайтеся, що він належить тому ж власнику, що і каталог, в якому він живе. Припущення полягає в тому, що якщо користувачі однакові, PHP працює як ваш власний обліковий запис, і безпечно встановити додатки як цей обліковий запис. Якщо вони відрізняються, WordPress передбачає, що PHP працює як спільний обліковий запис, і не безпечно встановлювати плагіни як цей обліковий запис. На жаль, обидва ці припущення є освіченими здогадами, які часто будуть помилятися.

Ви б використовували define('FS_METHOD', 'direct' );помилковий позитивний сценарій, такий як цей: ви - частина надійної команди, учасники якої завантажують файли через власний обліковий запис. PHP працює як власний окремий користувач. WordPress буде припускати, що це середовище ризику і не буде за замовчуванням для 'direct'режиму. Насправді він ділиться лише з користувачами, яким довіряєш, і тому такий 'direct'режим є безпечним. У цьому випадку вам слід використовувати, define('FS_METHOD', 'direct' );щоб змусити WordPress писати файли безпосередньо.

Існує "добре налаштована" ситуація, коли "прямий" призведе до проблем.

Можливо також налаштувати спільний WP-хостинг з не спільними користувачами виконання PHP, відмінними від користувачів власності файлів / каталогів. Таким чином, ви закінчуєте файли, що належать user1, і PHP-код виконується як php-user1.

У цій ситуації злому плагінів або основного коду (а) не можуть писати (або навіть читати з них, залежно від дозволів) директорій інших користувачів; (b) не може писати файли цього користувача, тому не може додавати троянський код до ядра або коду плагіна.

Отже, якщо хостинг налаштований так, ви ОБОВ'ЯЗКОВО використовувати FTP для оновлень, а "прямий" не працюватиме.

Якщо ви встановите "direct" у wp-config.php, а користувач, що виконує PHP, не має дозволу на запис, ви отримаєте повідомлення "Отримати помилки" і не буде з'являтися спливаючих запитів для FTP-облікових даних.