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

Именно так я понял идею 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. В этом случае процесс записи файлов от пользователя веб-сервера будет иметь в результате файлы,принадлежащие учетной записи пользователя веб-сервера,вместо фактического аккаунт пользователя. Это может привести к проблемам с безопасностью виртуального хостинга. ситуации,когда несколько пользователей используют один и тот же веб-сервер для разные сайты.

This is just, how I understood the idea of the WordPress File API. If it is wrong, please downvote :)

Okay. If you upload a file, this file has an owner. If you upload your file with FTP, you login and the file will be owned by the FTP user. Since you have the credentials, you can alter these files through FTP. The owner can usually execute, delete, alter etc. the file. Of course, you can change this by changing the file permissions.

If you upload a file using PHP, the linux user, which is executing PHP is owning the file. This user can now edit, delete, execute etc. the file. This is okay as long as only you are the user, who is executing PHP on your system.

Lets assume, you are on a "poorly" configured shared host. A lot of people run their PHP websites on this system. Lets say only one linux user is executing PHP for all these people. One of the webmasters on this shared host has bad intentions. He sees your page and he figures out the path to your WordPress installation. For example, WP_DEBUG is set to true and there is an error message like

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

"Ha!" the bad boy says. Lets see, if this guy has set FS_METHOD to direct and he writes a script like

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

Since only one user is running PHP and this user is also used by the bad boy he can alter/delete/execute the files on your system if you have uploaded them via PHP and by this attached the PHP user as the owner.

Your site is hacked.

Or, as it says in the Codex:

Many hosting systems have the webserver running as a different user than the owner of the WordPress files. When this is the case, a process writing files from the webserver user will have the resulting files owned by the webserver's user account instead of the actual user's account. This can lead to a security problem in shared hosting situations, where multiple users are sharing the same webserver for different sites.

В чем риск?

На плохо настроенном общем хосте 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 писать файлы напрямую.

What's the risk?

On a poorly configured shared host, every customer's PHP will execute as the same user (let's say apache for discussion). This setup is surprisingly common.

If you're on such a host and use WordPress to install the plugin using direct file access, all of your plugin files will belong to apache. A legitimate user on the same server would be able to attack you by writing a PHP script that injects evil code into your plugin files. They upload their script to their own website and request its URL. Your code is successfully compromised because their script runs as apache, the same one that owns your plugin files.

What does FS_METHOD 'direct' have to do with it?

When WordPress needs to install files (such as a plugin) it uses the get_filesystem_method() function to determine how to access the filesystem. If you don't define FS_METHOD it will choose a default for you, otherwise it will use your selection as long as it makes sense.

The default behavior will try to detect whether you're in an at-risk environment like the one I described above, and if it thinks you're safe it will use the 'direct' method. In this case WordPress will create the files directly through PHP, causing them to belong to the apache user (in this example). Otherwise it'll fall back to a safer method, such as prompting you for SFTP credentials and creating the files as you.

FS_METHOD = 'direct' asks WordPress to bypass that at-risk detection and always create files using the 'direct' method.

Then why use FS_METHOD = 'direct'?

Unfortunately, WordPress' logic for detecting an at-risk environment is flawed and produces both false-positives and false-negatives. Whoops. The test involves creating a file and making sure it belongs to the same owner as the directory it lives in. The assumption is that if the users are the same, PHP is running as your own account and it's safe to install plugins as that account. If they're different, WordPress assumes that PHP is running as a shared account and it's not safe to install plugins as that account. Unfortunately both of these assumptions are educated guesses that will frequently be wrong.

You would use define('FS_METHOD', 'direct' ); in a false positive scenario such as this one: you are part of a trusted team whose members all upload files through their own account. PHP runs as its own separate user. WordPress will assume that this is an at-risk environment and will not default to 'direct' mode. In reality it's only shared with users you trust and as such 'direct' mode is safe. In this case you should use define('FS_METHOD', 'direct' ); to force WordPress to write files directly.

Существует «хорошо настроенная» ситуация,когда «прямой» вызовет проблемы.

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

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

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

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

There is a 'well-configured' situation where 'direct' will lead to problems.

It is also possible to configure shared WP hosting with non-shared PHP execution users, different from the file/directory ownership users. So you end up with the files owned by user1 and the PHP code is executed as php-user1.

In that situation, hacked plugins or core code (a) can't write to (or even read from, depending on permissions) other users' directoriess; (b) can't write this user's files and so can't add trojan code to the core or plugin code.

So if the hosting is set up like that, you MUST use FTP for updates and 'direct' will not work.

If you set 'direct' in wp-config.php and the PHP execution user does not have write permission, you'll get Update Failed messages and have no pop-up asking for FTP credentials.