2010-01-19 9 views
21

Estoy intentando ayudar a un amigo a mover un sitio web de un hotel web a otro. El antiguo lugar ya está cerrado, solo tengo un archivo tar plano de lo que contenía.¿Qué permisos tienen los scripts/directorios de PHP?

El sitio web contenía documentos HTML y uno podía descargar una pequeña aplicación Java (para ser cargada en un teléfono móvil) para enviar datos al sitio web.

La aplicación móvil de Java envió una cadena a URL=<HOST>/php/register.php. Esta secuencia de comandos php incluía otra secuencia de comandos php (../inc/db_login.php), que se conectaba a una base de datos SQL usando $link=mysql_connect(). Otro archivo, register.php, hizo la inserción de SQL para poner los nuevos datos enviados en la base de datos.

Mi pregunta es básicamente, ¿dónde debería poner estos 2 archivos PHP en el nuevo sitio web y qué permisos deberían tener los directorios y archivos?

El viejo servidor web obviamente tenía un directorio /php y /inc. Ninguno de estos existe en el nuevo servidor web. ¿Debería crearlos? ¿Qué permiso deberían tener? Supongo que la razón para tener la contraseña en un archivo PHP separado era la seguridad. El directorio /php y /inc probablemente tenía permisos diferentes.

El nuevo servidor tiene directorios:

  • /httpdos
  • /httpsdos
  • /cgi-bin
  • /conf (y algunos otros probablemente irrelevante)

mis preguntas

  1. ¿La extensión de archivo (.php) significa algo para el servidor: como scripts PHP están "incluidos" en el código HTML (entre <?...?>, el servidor no tiene que mirar el sufijo de archivo o es irrelevante? (Entiendo que el servidor reacciona en el <?...?>, por supuesto)

  2. caso de que el archivo público (register.php en mi caso) se incluirán en el directorio httpdocs/ o hace el servidor (Apache creo) reacciona con algo y obtiene lo en otro directorio?

  3. caso de que el script PHP tiene permiso R-X (lectura y ejecución), --X (ejecución) o R-- (leer)? Desde una perspectiva del sistema operativo, supongo que apache solo está leyendo estos archivos, lo que significa que deberían ser R--, pero esto significaría que si el servicio PHP se "detiene", el cliente obtendría todo el código PHP en su navegador (?). Preferiría que fuera --X pero como esto no es ni un binario ni tiene un #!, supongo que debe ser --R?

  4. Si el script PHP público puede ser colocado en otro directorio (por ejemplo /php en lugar de /httpdocs) lo que debería /php (y el guión) tienen permiso ?. Supongo que el servidor tiene que saber sobre este directorio /php (¿o hay valores predeterminados usuales?)

  5. El script PHP incluido (../inc/db_login.php, que contiene la contraseña de SQL) no debería estar bajo /httpdocs supongo. Esto significa que mi register.php incluye un archivo que no está bajo el subárbol /httpdocs. ¿Esto funciona? ¿El servidor necesita saber?

Entiendo que es posible que necesite conocer la configuración del servidor. Solo asume el valor predeterminado en tu respuesta (y puedes decir dónde se cambia si lo está).

Respuesta

46

Los directorios deben tener permisos de ejecución para poder ser utilizados. Usualmente esto es 0755. Los scripts PHP ejecutados a través de mod_php no se ejecutan sino que se leen; 0644 será suficiente para esto. Los directorios que deben escribirse necesitan ser propiedad del usuario con el que se ejecuta el servidor web. Puede haber preocupaciones adicionales con respecto a los permisos, p. SELinux, pero lo anterior lo guiará a través de lo básico.

Los documentos a los que no deben acceder otros usuarios o clientes externos deben ser 0600, propiedad del usuario del servidor web y ubicados fuera de DocumentRoot. Tenga en cuenta que la ejecución de mod_php en modo seguro evitará que los scripts incluyan algo fuera de DocumentRoot; un defecto lamentable.

+0

Gracias por la respuesta. Pondré register.php en httpdocs/php. Ahora traté de crear/inc e incluir ../../inc/db_login.php, pero la creación de/inc fue rechazada ... ¿debería db_login.php colocarse en cgi-bin entonces ?. Y si apache está en modo seguro, entonces db_login debe estar en el árbol httpdocs ... ¿no es un riesgo de seguridad? –

+0

Nada más que scripts CGI deben estar en 'cgi-bin'. Sí, tener archivos de configuración en DocumentRoot es un riesgo de seguridad potencial; PHP podría resolver esto teniendo una opción de configuración que especifique un directorio adicional que se pueda incluir explícitamente. Pero no es así –

+0

Pero si tanto register.php como db_login.php están bajo la raíz html doc y sus permisos son los mismos, ¿cuál es la ganancia (en cuanto a la seguridad) para tenerlos en 2 archivos diferentes? Pensé que la idea era tener "más seguridad" alrededor de las contraseñas incluidas en db_login ...? ¿No es un riesgo que el código llegue al cliente si PHP falla? Una vez más, muchas muchas gracias por su tiempo./C –

1

He codificado una función para hacer frente a los problemas de permisos en ambos PHP/SuPHP y similares:

function realChmod($path, $chmod = null) 
{ 
    if (file_exists($path) === true) 
    { 
     if (is_null($chmod) === true) 
     { 
      $chmod = (is_file($path) === true) ? 644 : 755; 

      if (in_array(get_current_user(), array('apache', 'httpd', 'nobody', 'system', 'webdaemon', 'www', 'www-data')) === true) 
      { 
       $chmod += 22; 
      } 
     } 

     return chmod($path, octdec(intval($chmod))); 
    } 

    return false; 
} 

Tal vez sea útil para usted.

+0

Debería considerar el uso de literales octal en lugar de ocuparse de ese octdec() cruft, y usar '| =' en lugar de '+ ='. –

+1

¿Está utilizando un script PHP para corregir permisos en un script PHP? Si los permisos del servidor están fuera de control y no permiten que se ejecuten los scripts PHP, este script tampoco se ejecutará. Sin embargo, si corrige manualmente el permiso de este script, puede usarlo para hacer una restauración por lotes de los otros. Sin embargo, podría ser más rápido usar 'chmod -R' de la línea de comando. – MidnightLightning

+0

@MidnightLightning: Todavía es posible ejecutar scripts PHP a través de CLI, incluso si no funciona correctamente en el servidor web, suponiendo que tenga acceso al shell, por supuesto. Además, 'chmod -R' puede ser peligroso, mejor usar un' encontrar' correctamente diseñado. –

1

1) Los archivos que terminan con una extensión .php se entregan al compilador de PHP por Apache. Si la configuración adecuada no está configurada para hacerlo, el servidor sirve los archivos PHP como archivos de texto. La línea de configuración de Apache "AddHandler php5-script php" en el archivo httpd.conf es el método PHP5 para configurar esto.

2) register.php necesita ser accesible al http://www.example.com/php/register.php, como la aplicación java lo está buscando, entonces en la carpeta Apache htdocs, tiene que haber una carpeta "php" con el archivo register.php en ella.

3) Los archivos PHP necesitan acceso de lectura por parte del usuario que ejecuta el servicio Apache. El uso de PHP como módulo de Apache no tiene un 'servicio' del que hablar para PHP. En cambio, el servicio Apache, cuando recibe una solicitud de un archivo PHP, realiza una llamada de shell al binario de PHP para analizar el archivo y entregar el servicio de Apache, que sirve al cliente. Solo si usa PHP desde la línea de comando (configuración CLI) los scripts necesitarán permiso de ejecución y comenzarán con una línea #!/path/to/php-bin.

4) El archivo solicitado (register.php) debe estar en htdocs para ser servido por Apache. Si PHP se ejecuta con "Modo seguro" deshabilitado, register.php podría incluir un archivo que estaba fuera de la carpeta htdocs.

5) El camino "../inc/db_login.php" es relativo al script PHP que se recogió originalmente (register.php), por lo que, desde register.php está en htdocs/php/register.php, que pondría en db_login.php htdocs/inc/db_login.php.

+0

Punto 3: las configuraciones CLI y CGI necesitan permisos de ejecución. –

0

Todos los archivos PHP que están destinados a ser direccionados directamente a través de URL pueden residir felizmente en los mismos directorios que el contenido estático (esta es la práctica habitual).

Es una buena práctica tener al menos un directorio fuera de los visibles desde el servidor web para contener archivos de inclusión, pero la ruta de inclusión de PHP debe incluir '.'.

que recomiendo no poner un montón de directorios no estándar en su sistema de ficheros raíz - la web raíz predeterminado varía según la distribución, pero yo suelo ir con algo como:

/var/www/htdocs - como el documento root /usr/local/php - para incluir archivos

Obviamente, si tiene la intención de ejecutar su servidor web chrrot, estos se deben mapear en consecuencia.

Todos los archivos deben ser legibles por el uid bajo el cual se ejecuta el servidor web, sin embargo, si puede restringir lo que puede escribir este uid tanto como sea posible, cierre un posible vector de ataque.

Normalmente voy con la configuración de mis directorios como drwxrwSr-x propiedad de un miembro de un grupo webdev con la propiedad del grupo como equipo webdev, (el httpd uid no está en el grupo webdev) y los archivos son por lo tanto -rw -rw-r-- Entonces cualquiera en el grupo webdex puede cambiar archivos, y el uid httpd solo puede leer archivos.

1) hace lo archivos de extensión (.php) significa algo para el servidor:

Sí - ve a leer la guía de instalación de PHP.

C.

9

archivos Conjunto php a 640

Para de máxima seguridad debe establecer permisos mínimos, que es .

  • El propietario sería la posibilidad de subir los archivos.
  • El grupo 4 sería el que está sirviendo el archivo. Haga de apache un miembro del grupo.
  • nobody 0 significa que ningún otro usuario puede leer este archivo. Es importante ya que los scripts php a veces tienen contraseñas y otros datos confidenciales.

Nunca permita que los scripts de php sean leídos por todos.

comandos útiles:

chmod 640 file.php 
chown user:group file.php 
usermod -a -G group apache 

Lo que estos comandos están haciendo:

  1. cambiar la propiedad de archivo.php lo que el usuario puede leer y escribir, leer grupo.
  2. Cambie la propiedad de file.php, al nombre de usuario y grupo elegidos.
  3. Agregue apache al grupo, para que apache pueda servir el archivo. De lo contrario, 640 no funcionará.
Cuestiones relacionadas