¿Se debe negar el acceso público a nombres y tipos de archivos específicos de manera preventiva?

2

Es una buena idea desactivar (público) el acceso preventivo a ciertos tipos de archivos (por extensión) y / o por nombres de archivos:

  1. en la configuración del servidor (en el caso de un servidor de alojamiento compartido) o,
  2. como una regla de reescritura para un sitio web o una aplicación web?

Por ejemplo, nombres de archivo como:

  1. readme
  2. registro de cambios
  3. depurar
  4. errores
  5. phpinfo

O las siguientes extensiones de archivo en combinación con los nombres de archivo anteriores: php , log , html , htm , txt , doc , docx , rtf y posiblemente más y without any extensión de archivo.

Y negando el acceso a extensiones de archivo específicas completamente como: svn , git , sh , bat , cmd , sql , ini , config , conf , bak , backup y old .

¿Es una buena idea hacerlo? Para evitar la fuga de información cuando esos archivos se mueven (accidentalmente) a una carpeta pública.

    
pregunta Bob Ortiz 21.06.2016 - 11:36
fuente

3 respuestas

1
  

¿Es una buena idea desactivar (público) el acceso preventivo a ciertos tipos de archivos (por extensión) y / o por nombres de archivos?

¡Absolutamente! De hecho, todo acceso debe ser denegado y solo permitir buenas solicitudes conocidas. Esto también se conoce como "Denegación predeterminada" o "Lista blanca".

Marcus Ranum tiene algunos puntos importantes en The Six Dumbest Ideas in Computer Security . Aunque estrechamente relacionados, los dos primeros se aplican directamente a su pregunta.

  • 1) Permiso predeterminado: este es su enfoque actual, ya que todas las solicitudes están permitidas, excepto los pocos nombres de archivo / extensiones / etc que se deniegan explícitamente. Es mucho más fácil y más seguro bloquear todo y solo permitir las solicitudes válidas conocidas. Hay muchas arañas de sitios web disponibles que rastrearán todos los enlaces disponibles. Una vez que se produce una lista de URL, puede revisarla y seleccionar aquellas a las que solo deben acceder los usuarios finales. Esta también es una oportunidad para garantizar que el sitio web no publique inadvertidamente páginas restringidas (es decir, solo administrador).

  • 2) Enumeración de errores: es mucho más fácil implementar una "Denegación predeterminada" y solo se permiten las solicitudes que se encuentran en buen estado para tener reglas para cada posible solicitud incorrecta. Si su sitio web ejecuta PHP, no desea administrar reglas para bloquear solicitudes de Ruby, Java, ASP, etc. No solo es un trabajo innecesario, administrar una lista tan grande es propensa a errores de configuración, especialmente errores tipográficos.

Un efecto secundario positivo es que probablemente verás un aumento en el rendimiento, ya que solo las solicitudes de bienes conocidos podrán atravesar toda la pila.

    
respondido por el user2320464 27.06.2016 - 00:10
fuente
3

En los servidores web que ejecuto, niego el acceso a cualquier tipo de archivos de registro del servidor y archivos confidenciales que contengan detalles de configuración de la aplicación web como archivo wp-config.php de WordPress

Sin embargo, si está ejecutando un sitio web, negar el acceso a PHP, HTML, CSS, además de algunos otros tipos de archivos, dejaría su sitio web inutilizable, ya que los navegadores necesitan acceder a esos archivos para mostrar su sitio web correctamente.

Además, vería configurar correctamente los permisos de archivo para sus archivos para garantizar que solo los usuarios adecuados tengan acceso para ver , edítalos y muévelos.

Finalmente, recomendaría tipos de archivo de listas blancas en lugar de incluirlos en la lista negra porque, en general, habrá menos margen de error y no ocupará mucho espacio en su archivo .htaccess o bloques de servidores.

Tipos de archivos de la lista blanca en Apache

Tipos de archivos de la lista blanca en Nginx

    
respondido por el Marc Woodyard 24.06.2016 - 02:09
fuente
1

Suponiendo que está utilizando un lenguaje decente & En el marco, las únicas URL accesibles son las rutas que definió. Todo lo demás debería obtener 404d de forma predeterminada, excepto quizás archivos estáticos no sensibles en un directorio específico.

Cualquier cosa sensible debe estar fuera del alcance del servidor web de todos modos y solo debe ser sustituida por la aplicación si así lo decide.

    
respondido por el André Borie 26.06.2016 - 03:25
fuente

Lea otras preguntas en las etiquetas