Какие проблемы безопасности следует учитывать при установке FS_METHOD в значение "direct" в wp-config?

Каков риск?

На плохо настроенном shared-хостинге PHP всех пользователей выполняется от одного и того же пользователя (например, apache для примера). Такая конфигурация удивительно распространена.

Если вы используете такой хостинг и устанавливаете плагины в WordPress через прямой доступ к файлам, все файлы ваших плагинов будут принадлежать пользователю apache. Другой пользователь на этом же сервере сможет атаковать ваш сайт, написав PHP-скрипт, который внедрит вредоносный код в ваши файлы плагинов. Он загрузит свой скрипт на свой сайт и запросит его URL. Ваш код будет успешно скомпрометирован, потому что его скрипт выполняется от имени apache — того же пользователя, которому принадлежат ваши файлы плагинов.

Какое отношение имеет FS_METHOD 'direct'?

Когда WordPress нужно установить файлы (например, плагин), он использует функцию get_filesystem_method(), чтобы определить, как получить доступ к файловой системе. Если вы не определили FS_METHOD, WordPress выберет метод по умолчанию, в противном случае он будет использовать ваш выбор, если это возможно.

По умолчанию WordPress попытается определить, находитесь ли вы в опасной среде, подобной описанной выше. Если он решит, что всё безопасно, то использует метод 'direct'. В этом случае WordPress создаст файлы напрямую через PHP, и они будут принадлежать пользователю apache (в нашем примере). В противном случае он переключится на более безопасный метод, например, запросит SFTP-данные и создаст файлы от вашего имени.

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

Зачем тогда использовать FS_METHOD = 'direct'?

К сожалению, логика WordPress для определения опасной среды несовершенна и может выдавать как ложные срабатывания, так и пропускать реальные угрозы. Упс. Проверка включает создание файла и сравнение его владельца с владельцем родительской директории. Предполагается, что если пользователи совпадают, PHP выполняется от вашего аккаунта, и установка плагинов от его имени безопасна. Если владельцы разные, WordPress считает, что PHP работает от общего аккаунта, и прямой метод небезопасен. К сожалению, оба предположения — всего лишь догадки, которые часто оказываются неверными.

Вы можете использовать define('FS_METHOD', 'direct' ); в случае ложного срабатывания, например, когда вы работаете в доверенной команде, где все участники загружают файлы через свои аккаунты, а PHP выполняется от отдельного пользователя. WordPress решит, что это опасная среда, и не станет использовать 'direct' режим. На самом деле сервер используется только доверенными пользователями, поэтому прямой метод безопасен. В таком случае стоит принудительно включить define('FS_METHOD', 'direct' );, чтобы WordPress записывал файлы напрямую.

Существует "правильно настроенная" ситуация, когда использование 'direct' приведёт к проблемам.

Также возможно настроить общий хостинг WordPress с разными пользователями для выполнения PHP и владения файлами/каталогами. В итоге файлы принадлежат пользователю user1, а PHP-код выполняется от имени php-user1.

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

Поэтому если хостинг настроен таким образом, вы ДОЛЖНЫ использовать FTP для обновлений, и метод 'direct' не будет работать.

Если вы установите 'direct' в wp-config.php, а пользователь, от имени которого выполняется PHP, не имеет прав на запись, вы получите сообщения "Update Failed" (Обновление не удалось) без всплывающего окна с запросом FTP-данных.