Recientemente tuve un problema en el que no pude instalar el complemento WP Smush Pro porque no tengo la instalación manual o la instalación con un clic opciones disponibles.
Me encontré con esta publicación que sugería ajustar la configuración en wp-config.php. Agregué la configuración sugerida, sin embargo, la que parece ser la más importante es:
define("FS_METHOD", "direct");
Lo que me gustaría saber Cuáles son las verdaderas preocupaciones que debería tener acerca de la configuración de FS_METHOD en direct? ¿Existen otras alternativas para instalar el complemento?
Esto es lo que tiene que decir la documentación oficial:
FS_METHOD fuerza el método del sistema de archivos. Solo debería ser «directo», «ssh2″, » ftpext «o» ftpsockets «. Por lo general, solo debe cambiar esto si tiene problemas de actualización. Si lo cambia y no ayuda, cámbielo de nuevo / vuelva Muévelo. En la mayoría de las circunstancias, configurarlo en «ftpsockets» funcionará si el método elegido automáticamente no lo hace.
(Preferencia primaria) «directo» lo obliga a usar solicitudes de E / S de archivos directos desde PHP, esto es lleno de problemas de seguridad en hosts mal configurados. Esto se elige automáticamente cuando es apropiado.
Respuesta
Así es como entendí la idea de la API de archivos de WordPress . Si es incorrecto, vota hacia abajo 🙂
Está bien. 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. Como 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 de archivo .
Si carga un archivo usando PHP, el usuario de linux, que es ejecutar PHP es poseer el 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 «¡Ja!» dice el chico malo. Veamos, si este tipo ha configurado FS_METHOD en direct y escribe un script 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 PHP usuario 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 de escritura de 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.
Respuesta
¿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ás en un host de este tipo y usas WordPress para instalar el complemento usando acceso directo a archivos, todos sus archivos de 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 se vio comprometido correctamente porque su secuencia de comandos se ejecuta como apache, el mismo que posee los archivos de su complemento.
¿Qué hace FS_METHOD "direct" ¿tiene que ver con eso?
Cuando WordPress necesita instalar archivos (como un complemento), usa el get_filesystem_method () función para determinar cómo acceder al sistema de archivos. Si no define FS_METHOD, elegirá un valor predeterminado para usted; de lo contrario, usará su selección siempre que tenga sentido.
El comportamiento predeterminado intentará para detectar si se encuentra en un entorno de riesgo como el uno que describí anteriormente, y si cree que está seguro, usará el método "direct". En este caso, WordPress creará los archivos directamente a través de PHP, haciendo que pertenezcan al usuario apache (en este ejemplo). De lo contrario, recurrirá a un método más seguro, como solicitarle credenciales SFTP y crear los archivos como usted.
FS_METHOD = "direct" le pide a WordPress que lo omita en -detección de riesgos y siempre crea archivos usando el método "direct".
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 la creación de un archivo y asegurarse de que pertenece al mismo propietario que el directorio en el que vive. La suposición es que si los usuarios son los mismos, PHP se está ejecutando como su propia cuenta y es seguro instalar complementos como ese. 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, ambas suposiciones son conjeturas fundamentadas que con frecuencia serán incorrectas.
Usaría define("FS_METHOD", "direct" ); en un escenario de falso positivo como este: usted es parte de un equipo confiable cuyos miembros cargan archivos a través de su propia cuenta. PHP se ejecuta como su propio WordPress asumirá que este es un entorno en riesgo y no estará predeterminado en el modo "direct". En realidad, solo se comparte con usuarios de confianza y, como tal, "direct" es seguro. En este caso, debe usar define("FS_METHOD", "direct" ); para obligar a WordPress a escribir archivos directamente.
Comentarios
Respuesta
Hay un» bien configurado » situación en la que «directo» dará lugar a problemas.
También es posible configurar el alojamiento WP compartido con usuarios de ejecución PHP no compartidos, distintos de los usuarios de propiedad de archivos / directorios. Así que terminas con los archivos propiedad de user1 y el código PHP se ejecuta como php-user1.
En esa situación, los complementos pirateados o el código central (a) no pueden escribir (o incluso leer desde , dependiendo de los permisos) directorios de otros usuarios; (b) no puedo escribir archivos de este usuario y, por lo tanto, no puedo agregar código troyano al código del núcleo o del complemento.
Entonces, si el alojamiento está configurado así , DEBE usar FTP para las actualizaciones y «direct» no funcionará.
Si establece «direct» en wp-config.php y el usuario de ejecución de PHP no tiene permiso de escritura, «obtendrá Update Mensajes fallidos y ninguna ventana emergente que solicite las credenciales de FTP.
get_filesystem_method()a este: developer.wordpress.org/reference/functions/…