Los 10 errores de seguridad más comunes en ASP .NET

A continuación les enumeraré los 10 errores más comunes que se cometen cuando desplegamos una aplicación ASP.NET, les explico la razón por la que esos errores pueden ser peligrosos y les indico la manera más adecuada de corregirlos. Espero que les sea de utilidad:

1. Custom Errors deshabilitado. En el archivo Web.config de nuestras aplicaciones ASP.NET la etiqueta custom Errors se encuentra comentada por defecto cuando creamos una nueva aplicación, esto deja el valor RemoteOnly por defecto. Sin embargo muchas veces cuando estamos probando el software en un servidor remoto hay ocasiones en las que por comodidad dejamos el valor en Off, esto permite a todos los usuarios que ingresan a las páginas de la aplicación enterarse de los errores que suceden en la aplicación, al momento de depurar. Sin embargo esto no es bueno al momento de desplegar, puesto que cualquiera puede también ver pedazos de código cuando hay alguna falla. Lo más adecuado es prender la opción, lo cual puedes aprovechar para mostrar errores más amigables al usuario, esto incluso te sirve para optimizar para buscadores ;-). Un ejemplo de cómo prender esta opción es el siguiente:
   <customErrors mode="On">
<error statusCode="404" redirect="default.aspx" />
</customErrors>
2. Dejar habilitado el seguimiento de la página. El seguimiento de página (tracing) normalmente se encuentra apagado, sin embargo también por cuestiones de depuración puede encenderse, la forma más sencilla es hacerlo en el archivo que estemos trabaando utilizando la etiqueta Trace en la declaración de página del formulario en el que estamos trabajando, sin embargo una buena práctica es hacerlo de modo sólo local (por si necesitamos que el seguimiento esté de todos modos encendido) desde el archivo Web.config y luego apagarlo al desplegar, hacerlo de esta manera encenderá el seguimiento en todos los formularios del proyecto y evitará que se nos olvide apagarlo, lo haces con la etiqueta trace de la siguiente manera:
   <trace enabled="true" traceMode="SortByTime" localOnly="true" />
3. Depuración habilitada. Tener esta opción habilitada, afecta al rendimiento de la aplicación, muestra errores más detallados y sólo debe encenderse mientras estamos desarrollando precisamente para el proceso de depuración, la forma correcta de desplegar es dejando en el archivo Web.config la opción de depuración apagada, otra buena práctica en el caso de las aplicaciones ASP.NET creadas con Visual Basic es dejar las opciones explicit y strict encendidas, de este modo hacemos código mejor construído (léase 100 veces: no garantiza que perfectamente construído, pero ayuda). La forma de configurar esto es de la siguiente manera:
   <compilation debug="true" strict="true" explicit="true"/>
4. Cookies suplantables. Los hackers pueden realizar ataques de XSS (Cross Site Scripting) cuando las cookies son accesibles del lado del cliente, intentan este tipo de ataques cuando se encuentran por ejemplo con saludos del tipo Hola ChicoDotNet en las páginas en la que se inicia sesión agregando su propio código del lado del cliente. Esto puedes dificultarlo fácilmente -valga la redundancia- cuando enciendes las cookies HttpOnly, esto se hace de la siguiente forma:
   <httpCookies httpOnlyCookies="true" />
5. Sesión sin cookies. Para hacer disponible una aplicación a los clientes que no aceptan cookies se tiene la opción de colocar la sesión en la URL, muchos las utilizan por defecto para no complicarse asignando a la etiqueta sessionState el atributo cookieless con el valor UseUri, sin embargo esto abre la posibilidad de suplantar a un usuario determinado visitando la dirección que contiene la sesión, esto puedes evitarlo almacenando la sesión en una cookie que expire pronto, pero queda el problema de los clientes que no aceptan cookies, para ellos necesitas enviar la sesión en la URL, ¿Cómo resolver eso?, enciende la autodetección, eso hará que los clientes que las acepten las usen y los que no las reciban en la URL, se hace con el siguiente código en Web.config:
   <sessionState cookieless="AutoDetect" />
6. No emitir cookies seguras. Las cookies seguras se emiten utilizando SSL, esto hace que la transmisión se realice en forma encriptada, para configurar SSL en IIS puedes ver el artículo en MSDN que te indica como hacerlo en IIS 6.0, en el caso de IIS 7.0 es mucho más sencillo como ya había mencionado anteriormente. Para la configuración de la transmisión de las cookies por medio de SSL utiliza el siguiente código:
   <authentication mode="Forms">
<forms requireSSL="true" />
</authentication>
7. Sesiones alargables. Para alargar el tiempo de expiración de una sesión se utiliza el atributo slidingExpiration de la etiqueta forms, esto da mayor tiempo a los hackers para suplantar a un usuario determinado, la recomendación es dejarlo como se indica a continuación:
<forms slidingExpiration="true" />.
8. Uso de cookies de autenticación por defecto. El nombre por defecto de una cookie de autenticación es .ASPXAUTH, una buena práctica es nombrar estas de manera distinta, por ejemplo utilizando un GUID, de esta manera evitamos que alguien que se firme en una aplicación del servidor y pueda modificar la cookie para firmarse en otra utilizando la primera cookie obtenida. Este valor se pondría en el lugar que indico a continuación:
   <authentication mode="Forms">
<forms name="{80aae8ec-cee2-46bc-ba57-eb89cd3db488}" requireSSL="true" />
</authentication>
9. Paso de variables por URL. El uso de Request.Querystring("variable") para operaciones de negocios debe ser evitado, sobre todo si se trata de información sensible, se debe preferir el uso de variables de sesión o de ViewState, de otro modo cualqueir persona con algo de conocimientos de programación podría hacer ataques de XSS o de SQL injection.
10. Credenciales o cadenas de conexión en Web.config. Esto es lo más común de la lista, debe evitarse a toda costa el guardar usuarios y contraseñas en etiquetas credentials y cadenas de conexión o configuraciones de aplicación en Web.config sin antes cifrarlas adecuadamente. O. K., IIS evita la descarga de estos archivos de forma remota, pero ¿Qué me dicen de los del hosting? Hay que tener mucho cuidado con esto.

Etiquetas: .NET Básico, Aplicaciones Web », Arquitectura de software », Buenas prácticas, Fiabilidad y manejabilidad », Hacking, Pruebas de software », Seguridad Informática, VB

Escrito por Alfonso Lara Ramos @ 06:25

| | | | | | | | | | | |

Contenidos relacionados: Google, Live Search, Tafiti, Yahoo