¿Dónde colocar los archivos PHP para la seguridad?

Coloque sus archivos públicos en una carpeta llamada pública y dirija su nombre de dominio a esta carpeta usando el host virtual de apache, otros archivos no públicos deben estar en carpetas sobre la carpeta pública y puede consultarlos por include_path , por ejemplo . Así es como se estructuran la mayoría de los marcos.

  

¿Dónde colocar los archivos PHP para seguridad?

Tenga en cuenta que no hay un mejor lugar para almacenar sus archivos de forma segura. La seguridad de sus archivos sensibles es solo el resultado de una combinación de buenas medidas, como la prevención de inyecciones de URL que pueden revelar sus archivos confidenciales, que puede tomar y analizar brevemente a continuación.

  

Mi pensamiento es que debe seguir el principio de privilegio mínimo, si   Esos archivos no necesitan ser públicos, entonces no deberían ser públicos. Por que es   ¿Este algo que no está bien al inicio de PHP de la manera correcta?

La misma pregunta que podría hacer acerca de por qué no se recomiendan los cortafuegos. Pero la respuesta es que el artículo que eligió está destinado a los desarrolladores. Los desarrolladores están más preocupados por cómo hacer que funcione que cómo hacerlo seguro . Mira las secciones discutidas a través de ese artículo:

Primeros pasos (configuración general, versiones de PHP a elegir ...), Guía de estilo de código (Paradigmas de programación, Espacios de nombres, Biblioteca PHP estándar, Xdebug ...), Gestión de dependencias, PEAR (instalación, etc.), Prácticas de codificación , Inyección de dependencia (un patrón de diseño de software), interacción con bases de datos, plantillas ...

Como puede adivinar, esto se dirige a los desarrolladores, no a los que están preocupados como usted por los aspectos de seguridad de una aplicación. La única sección que habla un poco acerca de la seguridad es la Seguridad, y dentro de ella puede que solo esté la subsección relacionada con el hashing de contraseñas, el filtrado de datos y el saneamiento son importantes pero aún están poco cubiertos.

  

¿Hay una forma estándar de manejar esto?

El artículo que ha vinculado a los estados: No hay una forma canónica de usar PHP. Lo mismo que podemos decir: No hay una forma canónica de usar PHP de forma segura . Dicho esto, el principio de privilegio mínimo que mencionó es un requisito y aún existen buenas prácticas de seguridad que debe seguir porque solo una conjunción de estos principios en conjunto le puede dar una mejor seguridad:

1. Defensa en profundidad : debe resolver su problema en términos de capas de seguridad: configuración segura de Apache, estilo de codificación seguro, firewall, efectivo .htaccess archivos ... Aunque algunos argumentan que este principio agrega complejidad a su aplicación y puede traer nuevos riesgos de seguridad, una aplicación inteligente de este principio puede hacer que su aplicación sea simple pero segura (por ejemplo: las claves de hashing que permiten el acceso a sus carpetas son buenas, pero es mejor agregarlas) además, es aún mejor).

2. Especifique carpetas y archivos lista blanca : en lugar de enumerar carpetas y archivos a los que no se puede acceder, necesita más bien, autorice el acceso a sus archivos / carpetas públicos y rechace todo lo demás, porque de esta manera no olvidará proteger algunos archivos sensibles.

3. Mínimo privilegio : sus permisos de recursos (archivos en su caso, pero puede considerar otros elementos) deben otorgarse a un nivel mínimo para usuarios de su sitio web
4. No confíe mucho en la seguridad a través de la oscuridad para ocultar sus archivos.
5. Minimice la superficie de ataque de su aplicación web
6. Detectar intrusiones : registre información relevante de seguridad para identificar los riesgos y proteger su aplicación
7. Algunos piensan que una empresa de hospedaje de renombre es suficiente como elemento para proteger su aplicación, pero aún así debe proteger su aplicación por separado e independientemente del entorno de hospedaje.
8. No confíe solo en actores de terceros para asegurar su aplicación

Básicamente, tiene razón: en un servidor de su propiedad no es necesario colocar los archivos PHP en el directorio raíz del documento. Solo se necesita algún punto de entrada como un archivo index.php o cualquier otro archivo seleccionado por sus reglas de reescritura. Una vez que el servidor web pasa el proceso de solicitud al intérprete de PHP, ya no está vinculado por el DocumentRoot , pero mediante el open_basedir ruta (que no está establecida de forma predeterminada, lo que permite al interpretador de PHP acceder a los archivos en cualquier parte de su sistema).

Sin embargo, este escenario requiere dos requisitos previos:

• Es dueño de su propio servidor: La mayoría de los entornos compartidos imponen cierta estructura de directorios y configuración de todo el sistema que puede no ser adecuada para este tipo de implementación. Por ejemplo, es posible que no tenga acceso a los directorios que se encuentran sobre el DocumentRoot afectado, o que se apliquen algunas restricciones en la configuración de PHP.

• La aplicación web que pretende utilizar lo admite: Esto a menudo puede simplemente redactarse de nuevo en " Utiliza su propia aplicación web ". De hecho, la mayoría de los proyectos se desarrollan de forma que sean compatibles con el mayor rango posible de usuarios y, por lo tanto, imponen la menor cantidad posible de requisitos previos.

  Por lo tanto, la mayoría de los proyectos solo consideran la aplicación web como un todo para colocarla en un solo directorio. Esto es más fácil de implementar y mantener (en el directorio a actualizar, sin riesgo de discrepancia en el nivel de actualización entre varias carpetas), y se adapta a cualquier situación, ya sea que esté utilizando su propio servidor o alquile un espacio de alojamiento compartido.

  Sin embargo, algunos proyectos podrían proponer la configuración que usted describe como una opción (usando algún tipo de parámetro de configuración include_path ), sin embargo, esto podría hacer que el proyecto sea más difícil de desarrollar y mantener desde una perspectiva de desarrollador (principalmente pienso aquí sobre la calificación pruebas que luego tendrían más situaciones a tener en cuenta) sin proporcionar ningún beneficio de seguridad significativo.

Como se dijo, dicha medida no aportaría ningún beneficio de seguridad significativo ya que, en un servidor bien configurado, el contenido de los archivos PHP nunca será revelado por el servidor web: dichos archivos serán ejecutados por el interpretador de PHP y nunca se enviarán como archivos de texto en bruto. . La principal amenaza es que alguien pueda ejecutar código en su servidor (por ejemplo, instalando un shell de PHP) permitiéndole recorrer su árbol de directorios, pero en este caso, tener archivos PHP fuera de su directorio DocumentRoot tampoco será de ayuda. .

Sin embargo, el principio de privilegio mínimo sigue siendo cierto, pero solo se referirá a la forma en que el servidor web, el intérprete de PHP y los archivos de script de PHP interactúan entre sí. Por ejemplo:

• Algunas implementaciones (un ejemplo clásico como Nginx + PHP-FPM, por ejemplo) le permitirán usar diferentes usuarios para el servidor web y para el interpretador de PHP, lo que le permitirá establecer libremente qué archivos y recursos deben compartirse entre estas cuentas o no.
• También puede querer asegurarse de que los archivos PHP solo sean legibles y no puedan ser escritos por el usuario que ejecuta el interpretador de PHP, el PHP parche de Suhosin incluso propone un parámetro ( suhosin.executor. include.allow_writable_files ) impidiendo la ejecución de cualquier archivo PHP que no cumpla con este criterio,
• PHP también ofrece la mencionada open_basedir que impide que PHP los scripts acceden a cualquier archivo ubicado fuera de algunos directorios.
• Etc., etc., etc .: puede haber muchas otras formas de implementar el principio de privilegios mínimos y asegurar su plataforma de aplicaciones web, algunas de ellas genéricas, otras más específicas para su plataforma y aplicación.