CustomErrors en .NET: Cómo evitar fugas de información por los mensajes de error

 Para terminar este ciclo que he dedicado a los errores, o más concretamente a los mensajes de error, en aplicaciones .NET, es obligatorio terminar hablando de la posibilidad que permite el framework de personalizar, a nivel de servidor en el fichero Machine.Config o a nivel de aplicación en Web.Config, los mensajes de error que se van a mostrar. Ya hemos visto que los mensajes de error en modo Debug pueden generar un problema de seguridad grande al mostrarse el código fuente de la aplicación, pero los mismos mensajes de error .NET, aún no estando activado dicho modo, pueden seguir dando muchos detalles de la plataforma a los posibles atacantes. Esto se puede solucionar con una personalización robusta de los mensajes de error.

Figura 1: CustomErrors en aplicaciones .NET

La configuración de los mensajes de error permite que se personalice el entorno con cuatro posibilidades distintas, que deben ser tomadas en cuenta para cada necesidad. Esto se hace dentro de la sección de Machine.Config o Web.Config dedicado a System.Web, tal y como se ve a continuación:

<system.web>

<customErrors mode="On|Off|RemoteOnly" defaultRedirect="~/Error/Index" />

</ system.web>

CustomErrors mode OFF

Si el framework tiene configurado el valor de CustomErrors a OFF, eso quiere decir que se deben mostrar los errores .NET detallados, con la información concreta de qué excepción no controlada lo ha generado.

Figura 2: Error detallado que se obtiene con CustomErrors OFF

Un atacante podrá saber en todo momento qué es lo que está fallando en la aplicación .NET y le servirá para preparar una estrategia de ataque mucho más fácilmente.

CustomErrors mode ON

En este caso, cuando se genere un mensaje de error se mostrará una información genérica. Estos mensajes son los famosos Runtime Error que tantas veces aparecen en aplicaciones .NET. Esto indica que hay una excepción no controlada, pero el código del mensaje no da detalles sobre qué lo ha generado.

CustomErrors mode RemoteOnly

En este caso, el mensaje de error será también el genérico "Runtime Error" cuando se esté conectado el cliente desde una ubicación remota, y detallado cuando se genere desde la máquina local. En el siguiente ejemplo se puede ver como el mensaje indica que es genérico, pero que sería detallado si la conexión fuera local.

Figura 3: Error genérico que se obtiene con CustomErrors ON o
con CustomErrors RemoteOnly en una conexión remota

CustomErrors mode ON | RemoteOnly con DefaultRedirect

En el caso de que se haya decidido poner un modo de CustomErrors configurado a ON o a RemoteOnly, se puede configurar una página de error genérica. Esto haría que se diera solo la información corporativa que se desease. En el siguiente ejemplo el DefaultRedirect de Microsoft.com con los errores .NET.

Figura 4: Excepción controlada con CustomErrors y DefaultRedirect

Otros Errores de IIS y/o de Request Filtering

Hay que tener presente que, en un servidor IIS con una aplicación .NET hay otros mensajes de error que también hay que configurar. Ya vimos hace poco que los mensajes de error del módulo de Request Filtering son totalmente distintos, o los que se obtienen por cualquier excepción en el propio servidor IIS.

Figura 5: Mensaje de error 405 en un servidor IIS

Pero también serán distintos los errores del propio servidor IIS que tengan que ver con aplicaciones que no sean .NET, como en el caso de aplicaciones ASP normales, tal y como puede verse en la siguiente imagen.

Figura 6: Mensaje Error 404 en un servidor IIS con una aplicación ASP

Es decir, configurar CustomErrors en .NET ayuda a tener los errores del framework .NET controlados, pero debes controlar los mensajes de error de todos los frameworks, que puedes tener las fugas de información en cualquier sitio.

Saludos Malignos!

Fuente: http://www.elladodelmal.com/2015/06/customerrores-en-net-como-evitar-fugas.html