¿Qué preocupaciones de seguridad debo tener al configurar FS_METHOD como "direct" en wp-config?

¿Cuál es el riesgo?

En un hosting compartido mal configurado, el PHP de cada cliente se ejecutará como el mismo usuario (digamos apache para este ejemplo). Esta configuración es sorprendentemente común.

Si estás en un host así y usas WordPress para instalar plugins mediante acceso directo a archivos, todos tus archivos de plugins pertenecerán a apache. Un usuario legítimo en el mismo servidor podría atacarte escribiendo un script PHP que inyecte código malicioso en tus archivos de plugins. Subirían su script a su propio sitio web y solicitarían su URL. Tu código se vería comprometido porque su script se ejecuta como apache, el mismo usuario que posee tus archivos de plugins.

¿Qué tiene que ver FS_METHOD 'direct' con esto?

Cuando WordPress necesita instalar archivos (como un plugin) usa la función get_filesystem_method() para determinar cómo acceder al sistema de archivos. Si no defines FS_METHOD, elegirá un método por defecto; de lo contrario usará tu selección siempre que tenga sentido.

El comportamiento predeterminado intentará detectar si estás en un entorno de riesgo como el descrito anteriormente. Si considera que es seguro, usará el método 'direct'. En este caso WordPress creará los archivos directamente mediante PHP, haciendo que pertenezcan al usuario apache (en este ejemplo). De lo contrario, recurrirá a un método más seguro, como pedirte credenciales SFTP y crear los archivos como tú.

FS_METHOD = 'direct' le pide a WordPress que omita esa detección de riesgo y siempre cree archivos usando el método 'direct'.

Entonces, ¿por qué usar FS_METHOD = 'direct'?

Desafortunadamente, la lógica de WordPress para detectar entornos de riesgo es defectuosa y produce tanto falsos positivos como falsos negativos. La prueba implica crear un archivo y verificar que pertenezca al mismo propietario que el directorio donde reside. La suposición es que si los usuarios son los mismos, PHP se ejecuta como tu propia cuenta y es seguro instalar plugins como ese usuario. Si son diferentes, WordPress asume que PHP se ejecuta como una cuenta compartida y no es seguro instalar plugins como esa cuenta. Lamentablemente, ambas suposiciones son conjeturas que frecuentemente serán incorrectas.

Usarías define('FS_METHOD', 'direct' ); en un escenario de falso positivo como este: formas parte de un equipo confiable cuyos miembros suben archivos a través de sus propias cuentas. PHP se ejecuta como un usuario separado. WordPress asumirá que es un entorno de riesgo y no usará el modo 'direct' por defecto. En realidad solo se comparte con usuarios de confianza, por lo que el modo 'direct' es seguro. En este caso deberías usar define('FS_METHOD', 'direct' ); para forzar a WordPress a escribir archivos directamente.

Existe una situación 'bien configurada' donde el método 'directo' causará problemas.

También es posible configurar un alojamiento WordPress compartido con usuarios de ejecución PHP no compartidos, diferentes a los usuarios propietarios de archivos/directorios. Así terminas con archivos propiedad de usuario1 y el código PHP se ejecuta como php-usuario1.

En esa situación, plugins hackeados o código del núcleo (a) no pueden escribir (o incluso leer, dependiendo de permisos) en directorios de otros usuarios; (b) no pueden escribir los archivos de este usuario y por lo tanto no pueden añadir código troyano al núcleo o plugins.

Así que si el hosting está configurado así, DEBES usar FTP para actualizaciones y el método 'directo' no funcionará.

Si configuras 'direct' en wp-config.php y el usuario de ejecución PHP no tiene permisos de escritura, recibirás mensajes de "Actualización fallida" sin que aparezca un pop-up solicitando credenciales FTP.