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

Recientemente tuve un problema en el que no pude instalar el complemento WP Smush Pro porque no tengo disponibles las opciones de Instalación manual o Instalación con un clic.

Me encontré con esta publicación que sugería ajustar la configuración 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 es lo que debería preocupaciones reales en torno He establecer FS_METHODa direct? ¿Hay alguna otra alternativa para instalar el complemento?

Esto es lo que dice la documentación oficial:

FS_METHOD fuerza el método del sistema de archivos. Solo debe ser "directo", "ssh2", "ftpext" o "ftpsockets". En general, solo debe cambiar esto si tiene problemas de actualización. Si lo cambia y no ayuda, cámbielo / elimínelo. En la mayoría de las circunstancias, establecerlo en 'ftpsockets' funcionará si el método elegido automáticamente no lo hace.

(Preferencia primaria) "directo" lo obliga a usar solicitudes directas de E / S de archivos desde PHP, esto está plagado de problemas de seguridad en hosts mal configurados. Esto se elige automáticamente cuando es apropiado.

Así es como entendí la idea de la API de archivos de WordPress . Si está mal, favor de votar :)

Bueno. Si carga un archivo, este archivo tiene un propietario. Si carga su archivo con FTP, inicia sesión y el archivo será propiedad del usuario FTP. Como tiene las credenciales, puede modificar estos archivos a través de FTP. El propietario generalmente 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 que solo usted sea el usuario, que está ejecutando PHP en su sistema.

Supongamos que está 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 en este host compartido tiene malas intenciones. Él ve tu página y descubre el camino a tu 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 chico se ha puesto FS_METHODa directescribir 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 cargado a través de PHP y, de este modo, adjuntó al usuario PHP como propietario.

Tu sitio está pirateado.

O, como dice en 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 conducir a 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 apachepara discusión). Esta configuración es sorprendentemente común.

Si está en dicho host y usa WordPress para instalar el complemento mediante el acceso directo a archivos, todos sus archivos de complemento pertenecerán apache. Un usuario legítimo en el mismo servidor podría atacarte escribiendo un script PHP que inyecte código malvado en tus archivos de complemento. Suben su script a su propio sitio web y solicitan su URL. Su código se ve comprometido con éxito porque su script se ejecuta como apacheel mismo que posee sus archivos de complemento.

¿Qué 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 lo define FS_METHOD, elegirá un valor predeterminado para usted; de lo contrario, usará su selección siempre que tenga sentido.

El comportamiento predeterminado intentará detectar si se encuentra en un entorno de riesgo como el que describí anteriormente, y si cree que está seguro, usará el 'direct'método. En este caso, WordPress creará los archivos directamente a través de PHP, haciendo que pertenezcan al apacheusuario (en este ejemplo). De lo contrario, recurrirá a un método más seguro, como solicitarle credenciales SFTP y crear los archivos a medida que lo haga.

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

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

Desafortunadamente, la lógica de WordPress para detectar un entorno de riesgo es defectuosa y produce falsos positivos y falsos negativos. Whoops La prueba implica crear 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 esa cuenta. Si son diferentes, WordPress supone que PHP se está ejecutando como una cuenta compartida y que no es seguro instalar complementos como esa cuenta. Desafortunadamente, ambos supuestos son suposiciones educadas que con frecuencia estarán equivocadas.

Usaría define('FS_METHOD', 'direct' );en un escenario falso positivo como este: usted es parte de un equipo confiable cuyos miembros cargan todos los archivos a través de su propia cuenta. PHP se ejecuta como su propio usuario separado. WordPress asumirá que este es un entorno de riesgo y no pasará al 'direct'modo predeterminado . En realidad, solo se comparte con usuarios de confianza y, como tal, el 'direct'modo es seguro. En este caso, debe usar define('FS_METHOD', 'direct' );para obligar a WordPress a escribir archivos directamente.

Hay una situación 'bien configurada' donde 'directo' conducirá a problemas.

También es posible configurar el alojamiento compartido de WP con usuarios de ejecución de PHP no compartidos, diferentes de los usuarios propietarios de archivos / directorios. Entonces terminas con los archivos propiedad del usuario1 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, según los permisos) directorios de otros usuarios; (b) no puede escribir esto los archivos de usuario y, por lo tanto, no puede agregar código troyano al núcleo o al código del complemento.

Entonces, si el alojamiento está configurado de esa manera, DEBE usar FTP para las actualizaciones y 'directo' no funcionará.

Si configura 'directo' en wp-config.php y el usuario de ejecución de PHP no tiene permiso de escritura, obtendrá mensajes de Error de actualización y no aparecerá ninguna ventana emergente que le solicite credenciales FTP.