it-swarm-es.com

¿Existe un riesgo de seguridad al ejecutar aplicaciones web en debug = "true"?

Esta es una copia de la pregunta original sobre Stack Overflow que no recibió mucho amor y probablemente sea más relevante aquí:

Hay muchas razones de rendimiento por las que las aplicaciones no deberían ejecutarse en modo debug = "true" ( buen resumen de Scott G ), pero ¿hay algún vector de ataque expuesto por esta práctica? No es una cuestión de "debería o no debería", eso está claro, es una cuestión de si introduce vulnerabilidades específicas.

Me inclino a pensar que la capacidad de detectarlo de forma remota combinada con los problemas de rendimiento conocidos podría conducir a una vulnerabilidad contra la disponibilidad del servicio, pero me gustaría algo un poco más definido. ¿Alguien sabe de un ataque específico que se pueda orquestar contra una aplicación que ejecuta debug = "true"?

18
Troy Hunt

He tenido algunos comentarios interesantes sobre esta pregunta aquí y en Stack Overflow . Ha habido muchas respuestas relacionadas con los seguimientos de pila (un problema de errores personalizados, no un problema de depuración) y el rendimiento (no [directamente] un problema de seguridad).

La respuesta más convincente es que las constantes de compilación condicional (#if DEPURACIÓN ...) pueden causar un comportamiento inesperado, pero esto es más un riesgo de funcionalidad (código involuntario que se ejecuta en un entorno en vivo), que un riesgo de seguridad.

Sospecho que el modo de depuración puede abrir algunas vías a otras vulnerabilidades en función de la sobrecarga de rendimiento que coloca en la aplicación y la capacidad de detectarlo de forma remota (tal vez el riesgo de continuidad del servicio). He escrito mis conclusiones como parte de OWASP Top 10 para desarrolladores de .NET parte 6: Configuración incorrecta de seguridad .

Por lo tanto, en aras de la exhaustividad, la respuesta parece ser que no existe un riesgo de seguridad claro al ejecutarse en modo de depuración, pero ciertamente no es una buena idea para las aplicaciones de producción dados los factores mencionados anteriormente.

12
Troy Hunt

Al permitir a los atacantes potenciales el acceso potencial al código fuente, los rastros de la pila, etc., ciertamente les permite enfocar/limitar un ataque al sistema.

También supongo (aunque no lo he probado) que dado que debug = true causa el error de compilación en lugar del error esperado del cliente del sitio, podría estar expuesto al error criptográfico .net customerror.

http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

5
iivel

Lo más importante a tener en cuenta cuando debug = true es que los símbolos están ahí. La aplicación se puede precompilar con debug = true, pero esto es parte del proceso de implementación. P.ej. lo construye el servidor de compilación o en su máquina local y transfiere los ensamblajes. (todo el mundo está precompilando sus aplicaciones antes de la implementación de producción, ¿verdad?! :)) La depuración también tiene ciertas optimizaciones de tiempo de ejecución desactivadas. Un ataque obvio sería un DoS. Si los errores personalizados están desactivados, también puede encontrar más información sobre la pila de llamadas, más que si los errores personalizados están desactivados y los símbolos no están allí.

3
Steve

Creo que si customErrors = off y debug = true, se enviaría aún más información a un atacante.

Es más seguro decir customErrors = on o customErrors = RemoteOnly. De esa manera, un usuario remoto siempre obtendrá la página genérica de error ASP.NET. Más información sobre MSDN

3
goodguys_activate

Esto depende casi por completo del lenguaje/marco/entorno de implementación.

Para python/Django, es muy explícito el caso de que DEBUG = True es un problema de seguridad. Ver p. las notas sobre no mostrar las variables de configuración para 'SECRETO', 'CONTRASEÑA', 'PROFANIDADES' o 'FIRMA' - vea http://docs.djangoproject.com/en/dev/ref/settings/#debug

2
nealmcb

Es malo desde el punto de vista de la fuga de información, no es necesario repetir eso. Además, en el modo de depuración, el tiempo de espera de ejecución de la solicitud es de aproximadamente 5 horas, por lo que puede depurar su aplicación sin obtener tiempos de espera. (El valor de tiempo de espera normal es de 110 segundos de forma predeterminada). Por lo tanto, si los atacantes encuentran un código que demora demasiado en ejecutarse, este ataque puede convertirse en una denegación de servicio.

2
Nathan B.