Solución:
Así es como entendí la idea de la API de archivos de WordPress. Si está mal, vota hacia abajo 🙂
Bueno. Si carga un archivo, este archivo tiene un propietario. Si carga su archivo con FTP, inicie sesión y el archivo será propiedad del usuario de FTP. Dado que tiene las credenciales, puede modificar estos archivos a través de FTP. El propietario normalmente puede ejecutar, eliminar, alterar, etc. el archivo. Por supuesto, puede cambiar esto cambiando los permisos del archivo.
Si carga un archivo usando PHP, el usuario de Linux, que está ejecutando PHP, es el propietario del archivo. Este usuario ahora puede editar, eliminar, ejecutar, etc. el archivo. Esto está bien siempre y cuando solo usted sea el usuario, que está ejecutando PHP en su sistema.
Supongamos que se encuentra en un host compartido “mal” configurado. Mucha gente ejecuta sus sitios web PHP en este sistema. Digamos que solo un usuario de Linux está ejecutando PHP para todas estas personas. Uno de los webmasters de este host compartido tiene malas intenciones. Él ve su página y descubre la ruta a su instalación de WordPress. Por ejemplo, WP_DEBUG se establece en verdadero y hay un mensaje de error como
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1
“¡Decir ah!” dice el chico malo. Veamos, si este tipo se ha puesto FS_METHOD para direct y escribe un guión como
<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>
Dado que solo un usuario está ejecutando PHP y este usuario también es utilizado por el chico malo, puede alterar / eliminar / ejecutar los archivos en su sistema si los ha subido a través de PHP y adjuntando al usuario de PHP como propietario.
Su sitio ha sido pirateado.
O, como dice el Codex:
Muchos sistemas de alojamiento tienen el servidor web ejecutándose como un usuario diferente al propietario de los archivos de WordPress. Cuando este es el caso, un proceso que escribe archivos del usuario del servidor web tendrá los archivos resultantes propiedad de la cuenta de usuario del servidor web en lugar de la cuenta del usuario real. Esto puede generar un problema de seguridad en situaciones de alojamiento compartido, donde varios usuarios comparten el mismo servidor web para diferentes sitios.
¿Cuál es el riesgo?
En un host compartido mal configurado, el PHP de cada cliente se ejecutará como el mismo usuario (digamos apache Para discusión). Esta configuración es sorprendentemente común.
Si está en un host de este tipo y usa WordPress para instalar el complemento mediante el acceso directo a archivos, todos los archivos de su complemento pertenecerán a apache. Un usuario legítimo en el mismo servidor podría atacarte escribiendo un script PHP que inyecta código maligno en tus archivos de complementos. Suben su script a su propio sitio web y solicitan su URL. Su código está comprometido con éxito porque su secuencia de comandos se ejecuta como apache, el mismo que posee sus archivos de complemento.
Que hace FS_METHOD 'direct' tiene que ver con eso?
Cuando WordPress necesita instalar archivos (como un complemento), utiliza la función get_filesystem_method () para determinar cómo acceder al sistema de archivos. Si no defines FS_METHOD elegirá un valor predeterminado para usted; de lo contrario, usará su selección siempre que tenga sentido.
El comportamiento predeterminado tratar para detectar si se encuentra en un entorno de riesgo como el que describí anteriormente, y si cree que está seguro, utilizará el 'direct' método. En este caso WordPress creará los archivos directamente a través de PHP, haciendo que pertenezcan al apache usuario (en este ejemplo). De lo contrario, recurrirá a un método más seguro, como solicitarle las credenciales SFTP y crear los archivos como usted.
FS_METHOD = 'direct' pide a WordPress que omita esa detección de riesgo y siempre crear archivos usando el 'direct' método.
Entonces, ¿por qué usar FS_METHOD = 'direct'?
Desafortunadamente, la lógica de WordPress para detectar un entorno en riesgo es defectuosa y produce tanto falsos positivos como falsos negativos. ¡Ups! La prueba implica crear un archivo y asegurarse de que pertenece al mismo propietario que el directorio en el que vive. Se supone que si los usuarios son los mismos, PHP se ejecuta como su propia cuenta y es seguro instalar complementos como esa cuenta. Si son diferentes, WordPress asume que PHP se está ejecutando como una cuenta compartida y no es seguro instalar complementos como esa cuenta. Desafortunadamente, ambos supuestos son conjeturas fundamentadas que con frecuencia estarán equivocadas.
Usarías define('FS_METHOD', 'direct' ); en un escenario de falso positivo como este: eres parte de un equipo de confianza cuyos miembros cargan archivos a través de su propia cuenta. PHP se ejecuta como su propio usuario independiente. WordPress asumirá que este es un entorno en riesgo y no lo hará por defecto. 'direct' modo. En realidad, solo se comparte con usuarios en los que confía y, como tal, 'direct' el modo es seguro. En este caso debes usar define('FS_METHOD', 'direct' ); para obligar a WordPress a escribir archivos directamente.