Durante estos post, mostraré los 10 problemas o errores de configuración en el web.config que provocan grandes vulnerabilidades en las aplicaciones. Estos errores, en su mayoría vienen dados por desconocimiento a fondo del manejo de las secciones de configuración de nuestras aplicaciones.

En esta primera parte, veremos los primeros 5 de ellos.

1. El modo Custom Errors

Este es el primero de nuestra lista, ya que, será uno de los que casi siempre habilitemos cuando estamos desarrollando una aplicación web y que es de mucho cuidado.

Una etiqueta común y vulnerable de esta configuración sería

<configuration> 
  <system.web> 
    <customErrors mode="Off"> 
 

Una forma de corregir la vulnerabilidad que se expone a continuación sería cambiando la etiqueta por

<configuration>
  <system.web>
     <customErrors mode="RemoteOnly"> 

La configuración anterior se convierte en un problema por una sencilla razón, supongamos que un Hacker ingresa al sitio y ejecuta una acción, si el customErrors esta en off entonces se mostrará el error brindando detalles demasiado específicos como:

* La versión de Framework

* Versión de Asp.net

* E inclusive el tipo de excepción

Que está manejando el servidor. Esta información en manos de un hacker sería lo suficientemente buena como para lograr preparar un ataque contra nuestro sistema.

Por el contrario, si utilizamos la etiqueta customErrors en On o en RemoteOnly el error que se mostrará será un error no descriptivo cuando una excepción sea generada. Otra forma, sería redirigir al usuario a una página de errores predeterminada.

2. Dejando el Tracing Habilitado

La característica Trace que incluye asp.net es una de las mas apreciadas siendo utilizada para mejorar la seguridad de nuestras aplicaciones mientras las depuramos. Sin embargo, es también, una de las mejores armas que un Hacker puede utilizar para atacar nuestro sitio si es utilizada cuando este está en producción.

Una etiqueta común y vulnerable de esta configuración sería

<configuration> 
  <system.web> 
    <trace enabled="true" localOnly="false"> 

Una forma de corregir la vulnerabilidad que se expone a continuación sería cambiando la etiqueta por

<configuration> 
  <system.web> 
    <trace enabled="false" localOnly="true"> 

Si el elemento Trace está habilitado para los usuarios remotos y el atributo LocalOnly esta en false. Un usuario común vería una lista detallada de peticiones realizadas a la aplicación  simplemente accediendo a la página "trace.axd”

Si como mencionamos anteriormente el detalle de una excepción es un tesoro para un Hacker, entonces un log de peticiones es algo como “caído del cielo”.

La mejor manera de evitar que un hacker obtenga de los datos de seguimiento de las aplicaciones, es desactivar completamente el visor de seguimiento, colocando el atributo del elemento <trace> a "false". Si usted tiene que tener el visor de seguimiento activado, ya sea para la depuración o por el perfil de su aplicación, asegúrese de establecer el atributo "localOnly" del elemento <trace> a "true". Que permite a los usuarios acceder al visor de seguimiento sólo desde el servidor Web y desactiva la visualización desde cualquier equipo remoto, aumentando la seguridad de su aplicación.

3. Dejar el Modo Debug habilitado

Llevar a  producción un sitio que tenga el modo Debug habilitado es un error usual. Cuando se desarrolla, todas las aplicaciones requieren alguna forma de Debug, por ello, Visual Studio configura el archivo Web.Config para aceptar el Debug cuando se inicia una aplicación.

Como sabemos, pasar a producción un sitio web asp.net, podría ser tan sencillo como copiar todo el folder del sitio y llevarlo al IIS, pero que pasó con el modo debug? Lo hemos dejando habilitado comprometiendo la seguridad de nuestra aplicación.

Una etiqueta común y vulnerable de esta configuración sería

<configuration> 
 
<system.web>
 
<compilation debug="true"> 

Una forma de corregir la vulnerabilidad que se expone a continuación sería cambiando la etiqueta por

<configuration> 
  <system.web> 
    <compilation debug="false"> 

Dejar el Debug habilitado, nuevamente mostraría información detallada a los usuarios finales a la que no deberían tener acceso y que puede ser utilizada en muchos casos para atacar nuestras aplicaciones.

Por ejemplo, si el Debug está habilitado, entonces cualquier mensaje de error mostrado al usuario final incluyen no sólo la información del servidor, sino también un mensaje de excepción detallada y un seguimiento de pila, pero también el código fuente real de la página donde se produjo el error.
Por desgracia, esta configuración no es la única manera de que el código fuente puede ser mostrado al usuario

4. Cookies accesibles desde el lado del Cliente

Desde que se dio la aparición de IE 6  Microsoft añadió una nueva propiedad para las cookies denominada “HttpOnly”. Está propiedad puede ser configurada individual o globalmente.

Una etiqueta común y vulnerable de esta configuración sería

<configuration> 
  <system.web> 
    <httpCookies httpOnlyCookies="false"> 

Una forma de corregir la vulnerabilidad que se expone a continuación sería cambiando la etiqueta por

<configuration> 
  <system.web> 
    <httpCookies httpOnlyCookies="true"> 

Cualquier Cookie que sea marcada con este atributo será accesible únicamente desde el lado del servidor y no podrá ser accedida mediante ningún lenguaje de lado del cliente como Javascript o VBScript, lo cual nos ayuda a evitar los ataques Cross-Site. Una ataque Cross-Site se produce cuando un hacker intenta inyectar su propio código en la pagina para burlar la seguridad. Si una aplicación acepta el ingreso de datos por un usuario esta expuesta a un ataque de este tipo.

5. El modo Cookieless Session State Habilitado

En la versión inicial de Asp.net (1.0), no se tenía opción para trasmitir el Token de las Sesiones entre las peticiones cuando la aplicación necesitaba mantener el estado de sesión (session state), siempre se encontraba almacenado en una Cookie.

Luego de la aparición de asp.net 1.1, Microsoft agregó soporte para los token de sesión sin cookies (cookieless session tokens), mediante la utilización  del atributo “cookieless”.

Una etiqueta común y vulnerable de esta configuración sería

<configuration>
  <system.web>
    <sessionState cookieless="UseUri"> 

Una forma de corregir la vulnerabilidad que se expone a continuación sería cambiando la etiqueta por

<configuration> 
  <system.web> 
    <sessionState cookieless="UseCookies"> 

Las aplicaciones Web configuradas para utilizar el estado de sesión sin cookies almacenan el identificador de sesión en la URL de la página en lugar de usar una cookie. Por ejemplo, la URL de la página puede cambiar de http://myserver/MyApplication/default.aspx a http://myserver/MyApplication/ (123456789ABCDEFG) / default.aspx. En este caso, "123456789ABCDEFG" representa la sesión del usuario actual. Otro usuario que explora diferentes partes del sitio al mismo tiempo, reciben una sesión completamente diferente resultando en una dirección URL diferente, como http://myserver/MyApplication/ (ZYXWVU987654321) / default.aspx.

 

Las 5 vulnerabilidades de seguridad que se han comentado en este post, hacen referencia a todas las aplicaciones asp.net independientemente de la forma de autenticación que utilicen. En post posteriores veremos algunas vulnerabilidades aplicables solo al modo de autenticación Forms