在wp-config中将FS_METHOD设置为“ direct”时，应该有什么安全方面的考虑？

这就是我对 WordPress File API 的想法的理解.如果不对,请投票:)

好的.如果您上传文件,则该文件具有所有者.如果使用FTP上传文件,则登录后,该文件将归FTP用户所有.由于您具有凭据,因此可以通过FTP更改这些文件.所有者通常可以执行,删除,更改等文件.当然,您可以通过更改文件权限来更改此设置.

如果使用PHP上传文件,则执行PHP的Linux用户将拥有该文件.现在,该用户可以编辑,删除,执行等文件.只要您是在系统上执行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上传了文件,并且该用户附加了所有者,则他可以更改/删除/执行系统上的文件.

您的网站已被黑客入侵.

或者,如法典中所述:

许多托管系统的网络服务器都以其他用户身份运行 超过WordPress文件的所有者.在这种情况下, 从网络服务器用户写入文件的过程将产生 网络服务器用户帐户拥有的文件,而不是实际的 用户的帐户.这可能导致共享主机中的安全性问题 多个用户共享同一个Web服务器的情况 不同的站点.

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.

在"配置合理"的情况下,"直接"会导致问题.

还可以为非共享的PHP执行用户配置共享的WP托管,与文件/目录所有权用户不同. 因此,您最终得到了user1拥有的文件,并且PHP代码以php-user1的身份执行.

在这种情况下,被黑的插件或核心代码(a)无法写入(甚至根据权限从其读取)其他用户的目录；(b)无法写入此用户的文件,因此无法将木马代码添加到内核或插件代码中.

因此,如果托管服务器是这样设置的,则必须使用FTP进行更新,否则"直接"将无法工作.

如果在wp-config.php中设置" direct",并且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.