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

He recibido algunos comentarios interesantes sobre esta pregunta tanto aquí como en Stack Overflow . Ha habido muchas respuestas relacionadas con los seguimientos de la 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 condicionales (#if DEBUG ...) podrían causar un comportamiento inesperado, pero esto es más un riesgo de funcionalidad (código no intencional que se ejecuta en un entorno real), 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 impone en la aplicación y la capacidad de detectarla de forma remota (riesgo de continuidad del servicio, tal vez). He escrito mis conclusiones como parte de OWASP Arriba 10 para los desarrolladores de .NET parte 6: Configuración errónea de seguridad .

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

Al permitir que los posibles atacantes accedan al código fuente, a los seguimientos de la pila, etc., ciertamente les permite enfocar / limitar un ataque al sistema.

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

enlace

Lo más importante que se debe tener en cuenta cuando debug = true es que los símbolos están ahí. La aplicación puede precompilarse con debug = true, pero esto es parte del proceso de implementación. P.ej. lo obtiene construido por el servidor de compilación o en su máquina local y transfiere los ensamblajes. (todos están precompilando sus aplicaciones antes de la implementación de producción, ¿no?! :)) 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 en la pila de llamadas, más que si los errores personalizados están desactivados y los símbolos no están allí.

Pensaría que si customErrors = off y debug = true, se enviaría 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 de error genérica de ASP.NET. Más información sobre MSDN

Esto depende casi completamente del idioma / entorno / entorno de implementación.

Para python / django, es muy explícito que DEBUG = True es un problema de seguridad. Ver por ejemplo las notas sobre no mostrar las variables de configuración para 'SECRET', 'PASSWORD', 'PROFANITIES' o 'SIGNATURE' - consulte enlace

Es malo desde el punto de vista de la fuga de información, no hay necesidad de 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) Entonces, si los atacantes encuentran un código que demora demasiado en ejecutar este ataque, puede convertirse en una denegación de servicio.