2011-11-13 17 views
14

¿Es posible que los hackers (u otros) carguen/escriban un archivo php en una carpeta de mi sitio que tenga chmod 777?¿Pueden las personas escribir un archivo .php en mi carpeta chmod 777

Ejemplo:

tengo una carpeta que se chmod 777. Esa carpeta contiene imágenes. Uso .htaccess para bloquear la indexación de la carpeta.

Pregunta reformada: ¿Pueden las personas escribir un archivo .php en mi carpeta que tenga chmod 777 utilizando un script PHP en su sitio web? Por ejemplo, para enumerar todas las imágenes en esa carpeta

(estoy familiarizado con la derecha chmod para subir la carpeta etc .., simplemente pidiendo que hypotheticaly)

+0

¿qué se edita Aurelio? –

+0

[Las etiquetas] (http://stackoverflow.com/posts/8115159/revisions) – SLaks

+0

Ahaaa, no sabía nada de que THX "herramienta de revisión"! :) –

Respuesta

16

Es muy probable que cualquier usuario legítimo de esa máquina pueda escribir .php archivos, o cualquier otra cosa que deseen, en ese directorio completamente abierto. Un directorio 777 casi no tiene lugar en un host compartido. (/tmp puede ser a veces 1777, para establecer el bit pegajoso en el directorio -. Que permite que sólo un archivo propietario para borrar un archivo en el directorio Normalmente, 777 significa que cualquiera puede borrar cualquier archivo desde el directorio Pero /tmp tiene definitivamente. caído en desgracia en entornos de alojamiento compartido porque es inherentemente inseguro.)

Entonces: ¿Es usted el único usuario en la máquina? ¿O esta máquina se comparte con alguien más? ¿Esta máquina ejecuta otros servicios además del servidor web? Si es así, esos otros servicios también podrían representar un posible vector de ataque.

Además, si sus permisos están establecidos en 777 en su directorio, me pregunto cuán seguros son los archivos PHP que está ejecutando: he visto muchos casos de personas ejecutando scripts PHP inseguros que permiten a un atacante modificar cada Archivo HTML en todo el servidor web, para infectar a las personas que navegan por el sitio. (Sí. Muchos. Más que un puñado por mucho)

Es por eso que cualquiera de las cuentas de usuario que ejecuta su servidor web no debe poseer ninguno de los archivos del sitio, tanto páginas estáticas como dinámicas. El servidor web solo debe tener suficientes privilegios de escritura para escribir sus access.log, error.log y hablar con un servidor de base de datos. Cualquier additional privileges beyond this hace que sea muy fácil para un error benigno en uno de sus scripts convertirse en una vulnerabilidad explotable que permite que su sitio sea utilizado para atacar a otros.

777 es una mala idea. Arregla eso. Asegúrese de que su servidor web no tenga permiso de escritura para el contenido web. Asegúrese de que ningún otro servicio en el servidor tenga permiso de escritura para su contenido web. Asegúrese de que ningún otro usuario en el servidor tenga permiso de escritura para su contenido web.

actualización

Esto es más fácil de lo que parece. Cree un nuevo usuario webcontent. Si su servidor web ya tiene un grupo propio, vamos a usarlo y llamarlo webgroup. Si aún no lo hace, cree un nuevo webgroup también. (adduser(8) y addgroup(8) si su VPS no tiene su propio mecanismo.) A continuación, establecer el dueño de todo su contenido web:

chown -R webcontent:webgroup /path/to/web/content 

permisos fijos:

find /path/to/web/content -type d -print0 | xargs -0 chmod 750 
find /path/to/web/content -type f -print0 | xargs -0 chmod 640 

continuación, asegúrese de que su servidor web es utilizando la directiva Group webgroup para asegurarse de que aún pueda leer todos los archivos que necesita.

Esto le permitirá a su servidor web tener leer acceder a todos sus scripts y configuración, pero si el servidor web en sí está hackeado, no puede modificar nada de eso.

+0

Digamos que estoy en un VPS. Entonces soy el único usuario en la máquina (virtual). –

+0

¿El servidor web es el único servicio en el VPS? ¿Cuánto confías en tus guiones? – sarnold

+0

¿Estoy pensando correctamente que la ejecución de su último párrafo no es tan fácil como parece? –

7

Si el código está en un servidor compartido o una servidor con otros servicios en él, sería posible que los otros usuarios locales escriban en su directorio (si los otros usuarios pueden descender a los directorios padre).

Necesitará algo más que un directorio que todos puedan leer y escribir (777) para ser pirateado. El uso de permisos 777 generalmente indica una mala comprensión de las características de seguridad (o pereza cuando el código necesita ser redistribuido y el autor no quiere hacerlo demasiado difícil al explicar los permisos de archivo al usuario del script).

12

Hay (al menos) tres maneras alguien puede escribir en el directorio:

  • Si tienen el control local sobre el servidor (por ejemplo, a través de un terminal)
  • Si los soportes de servidor web y permite la PUT método HTTP
  • Si usted tiene un script que permite a sus usuarios subir archivos a ese directorio

mientras no exponer públicamente la carpeta en un wa grabable y, nadie puede modificar el contenido de la carpeta de forma remota. Esto es independientemente de los permisos locales. Los permisos locales que ha establecido permiten que cualquier usuario local del servidor lea, escriba y ejecute en esta carpeta, pero esto no significa que un atacante remoto pueda hacerlo.

Habiendo dicho eso, evite 777 permisos a menos que absolutamente sea necesario/seguro.

+0

ahora no recibo por completo esta parte: "Mientras no exponer públicamente la carpeta de una forma de escritura, nadie puede modificar el contenido de la carpeta remota" –

Cuestiones relacionadas