¿Por qué los servidores web están configurados de manera ubicua mediante la inclusión de la lista negra de archivos inaccesibles en lugar de la lista blanca de los accesibles?

3

Toma un sitio PHP al azar. Básicamente, se garantiza que su servidor web está configurado de la siguiente manera: sirve cualquier archivo desde la raíz del documento, excepto ciertos archivos o rutas que están en la lista negra. Los scripts también se ejecutan utilizando un modelo similar: todos los archivos .php son ejecutables por el servidor web, excepto los de la lista negra.

ASP.NET se configura de la misma forma en IIS: los archivos * .aspx son, de manera predeterminada, ejecutables desde cualquier directorio, y se supone que uno debe incluir en una lista negra de directorios como una ubicación pública de "cargas" para evitar vulnerabilidades.

No sé sobre otros servidores web, pero en IIS es totalmente posible cambiar esto, eliminando todas las asignaciones de controladores y luego enlistando archivos / rutas muy específicos. Dada una base de código bien estructurada, uno puede tener solo dos asignaciones de este tipo: una asignación única para un "/ public /" para ser atendida por StaticFileHandler, y otra asignación que asigna "/index.php" - y nada else - al FastCgiModule. Para ASP.NET, es un poco más de trabajo, pero si esto fuera un objetivo , las herramientas podrían escribirse en los archivos .aspx de la lista blanca durante la implementación, de modo que no se podrían ejecutar otros archivos .aspx, sin importar donde están ubicados.

Permitir todo y luego tratar de tapar los orificios es seguramente uno de los "no-no" de seguridad 101. ¿Por qué es tan omnipresente en las configuraciones de servidores web?

    
pregunta RomanSt 24.09.2014 - 21:06
fuente

2 respuestas

4

Debido a que el contenido del servidor web cambia con frecuencia y sería molesto tener que agregar constantemente nuevos archivos a una lista blanca.

  

Para ASP.NET, es un poco más de trabajo, pero si esto fuera un objetivo, las herramientas podrían escribirse en los archivos .aspx de la lista blanca durante la implementación, de modo que no se puedan ejecutar otros archivos .aspx, sin importar dónde se encuentren. .

Pero normalmente no implementas archivos .aspx, .php a través de una herramienta. Simplemente colóquelos en el directorio. Requeriría un gran cambio en cómo funcionan los lenguajes de scripting. Dejarían de ser lenguajes de script y se volverían más como lenguajes compilados.

  

Permitir todo y luego tratar de tapar los orificios es seguramente uno de los "no-no" de seguridad 101. ¿Por qué es tan omnipresente en las configuraciones de servidores web?

Ir al revés se basaría en la suposición de que permitir las cargas de usuarios es un caso de uso normal para todos los que instalen el servidor web. No es muy probable que la mayoría de las instancias de servidor web permitan las subidas de usuarios, ya que la mayoría son intranets corporativos o sitios no interactivos que simplemente publican material para el usuario.

    
respondido por el developerwjk 24.09.2014 - 22:40
fuente
1

tl; dr: es caro

funciona si tienes

  • un waf que permite la inclusión en listas blancas + modo de aprendizaje
  • generación automatizada de listas blancas
  • ciclos de implementación automatizados y un completo entorno de pruebas / control de calidad: un entorno que prueba CUALQUIER función y función nuevas
  • buena prueba de regresión
  • ...
respondido por el that guy from over there 25.09.2014 - 02:50
fuente

Lea otras preguntas en las etiquetas