Del blog de Javier Romero
Los desarrolladores nos enfrascamos en crear y escribir código seguro, pero dejamos de lado las vulnerabilidades de los archivos de configuración (*.config). Un recorrido sobre los más comunes problemas de seguridad en estos archivos y cómo evitarlos.
En estos días la principal brecha de seguridad para la infraestructura de una compañía, llegan desde el sitio Web público. A diferencia de otros servicios internos como bases de datos, intranets, que pueden ser sellados mediante un firewall, el sitio Web está accesible para quien desee verlo. Como las redes ahora son mucho más seguras, las vulnerabilidades de los sitios Web son ahora los preferidos por los “hackers”.
Pues los más iluminados arquitectos de software y desarrolladores ya han sido educados en estos menesteres o al menos aprenden día a día de la problemática y tienen presente la seguridad desde el inicio del diseño de la solución y no solamente como parche al final de la misma. Pero si no tomamos en cuenta que aparte de los lenguages a utilizar VB.NET o C# un archivo de configuración mál configurado (valga la redundancia) se nos puede convertir en el verdadero Talón de Aquiles de nuestra estructura e inclusive más peligroso que un código inseguro.
Como problema adicional, los archivos Web.config fueron diseñados para ser cambiados en cualquier momento, de manera que un Administrador “bien intencionado” podría por omisión o error provocar un hueco de seguridad mientras el sitio ya está en producción; y por la manera jerárquica en que funcionan los Web.config este cambio afectaría al funcionamiento de todo el sitio.
Listaremos a continuación los problemas más “ofensivos” de configuraciones de seguridad y además indicaremos algunas opciones para evitar cometer estas situaciones.
1. Custom Errors Deshabilitados
Cuando deshabilitamos Custom Errors en el Web.Config, ASP.NET muestra un mensaje de error para mí demasiado descriptivo para cualquier cliente.
| Vulnerable: | Seguro: |
|
|
En sí el conocer el Stack Trace del error (el código fuente que lo generó), es muy delicado exponer toda esta información para que cualquier persona lo pueda ver. Al generar una excepción se podría conocer la versión del Framework que se ejecuta, o si el servidor utiliza SqlServer e inclusive datos sensibles si es que hubiera información importante que se muestre en la descripción del error.
Por lo tanto, podemos prevenir la situación modificando el atributo mode de el elemento ubicándolo en On o en RemoteOnly. El primero permite ubicar una página genérica de error mientras que el segundo muestra un error genérico.
2. Dejar el Trace Habilitado para un sitio en producción.
La característica de trace en ASP.NET es una de las herramientas más útiles que puedes utilizar para depurar y probar tus aplicaciones. Desafortunadamente, también puede ser una herramienta muy útil para un hacker que esté decidido a hacer daño.
| Vulnerable: | Seguro: |
|
|
Cuando el elemento
está habilitado para usuarios remotos (localOnly=”false”) cualquier usuario puede ver una detallada lista de los requerimientos recientes de la aplicación, simplemente por apuntar a la páginca trace.axd. Parece increíble!.Un hacker podría obviamente encontrar útil datos de la aplicación como valores de los campos, valores de las cookies, e inclusive números de tarjeta de crédito o números de cuenta de banco si es que la aplicación tiene flaquezas de seguridad.. Ojo!.
La mejor manera de prevenir que un hacker obtenga datos del trace es deshabilitar el visor de trace completamente ubicando el atributo enable del elemento
al valor false. Si aún así deseas mantener el trace habilitado por cuestiones de depuración, asegúrate que sólo se muestre en la máquina local y que nadie más lo pueda ver ubicanto el atributo localOnly del elemento al valor de true.
3. Dejar la Depuración Habilitada para el sitio Online.
Implantar una Aplicación Web en modo de depuración es un erro mucho más común de lo que se piensa. Virtalmente toda aplicacion Web requiere algún tipo de depuración. Y como el deploy de las aplicaciones ASP.NET es un hecho de simplemente copiar los archivos de un directorio a otro, es fácil que las configuraciones de desarrollo pasen al sitio de producción.
| Vulnerable: | Seguro: |
|
|
Como las anteriores vulnerabilidades, dejar habilitada la depuración es peligroso porque estas proveyendo información de “dentro de la aplicación” a los usuarios finales quienen no deberían ni siquiera conocer acerca de eso. Y es más en conjunto con la directiva de customErrors, no solo dará el error sino tambien el Stack trace, Descripción del error e inclusive la línea en que se generó la excepción…
Para desabilitar la depuración, ubica el valor del atributo debug del elemento a false. Este es el valor que deberías tener siempre en tu archivo de configuración.
4. Cookies accesibles a través de scripts del Lado del Servidor.
En IE 6.0, Microsoft introdujo una nueva propiedad de las cookies llamada HttpOnly. Además que esta propiedad pueda ser declarada programáticamente, también puede ser seteada de manera global en el archivo de configuración del sitio web.
| Vulnerable: | Seguro: |
|
|
Cualquier cookie marcada con esta propiedad será accesible somente desde codigo generado por el servidor, y no por algún script del lado del cliente como JavaScript o VBScript. Este pseudo-escudo de las cookies protege la aplicación de ataques de tipo cross-site. Es posible habilitar el HttpOnly para cualquier cookie individual generada del lado del servidor o puede ser seteada globalmente.
5. Cookieless Session State Habilitado.
En el release inicial 1.0 de ASP.NET, no había alternativa de cómo transmitir el token de sesión entre los requerimientos cuando la aplicación Web requería mantener el estado de la sesión, siempre se guardaba en una cookie. Desafortudamente, esto significaba que usuarios que no acepten cookies no podían usar la aplicación. Así que en ASP.NET 1.1, Microsoft agregó soporte para sessión sin cookies (cookieless).
| Vulnerable: | Seguro: |
|
|
Las aplicaciones Web configuradas para no usar cookies ahora almacentan el token de la sesión en los URLs de las páginas en vez de una cookie. Mientras esto mejora la usabilidad y accesibilidad de las aplicaciones tambien tiene su efecto al hacer estas aplicaciones mucho más sensibles a ataques de secuesto de sesión (hijacking attacks). Basicamente es una forma en la cual un hacker trata de tomar la identidad de un usuario legítimo. Podría usar un sniffer para escuchar el canal, obtener el dato del URL y hacerse pasar por un usuario.
La forma más efectiva de prevenir estos secuestros de sessión es usar siempre sesiones para guardar el token de sesión. Luego si se prefiere dar un moco más de accesbilidad a la aplicacion se puede cambiar la drectiva, configurando el atributo cookieless a AutoDetect, la aplicación guardará el token de sesión en una cookie cuando encuentre que el cliente puede aceptar la cookie, caso contrario generá el token y lo transmitirá por el URL.
[continuará]
