Archivo de la etiqueta: request

BASM – Broken Authentication and Session Management -Evitarla en ASP.NET Webforms


Normalmente se cree que una sesión de usuario de una aplicación ASP.NET en webforms con IIS, no puede “quebrarse” o ser interceptada por otro cliente, pero esto no es realmente así. Solución

Hace unos años me pidieron que solucione este problema en una aplicación que estaba siendo vulnerada.

La aplicación estaba programada de la siguiente manera (no pondré los nombres reales, utilizaré ejemplos):

Web.Config:

Evento de logout:

Membership.DeleteUser(Membership.GetUser(true).UserName, true);
MembershipProvider.SignOut(MembershipLogoutMethods.CloseButton);
FormsAuthentication.SignOut();
Session.Abandon();
Response.Cookies[“ASP.NET_SessionId”].Expires = DateTime.Now.AddSeconds(-30);
Response.Cookies.Add(new HttpCookie(“ASP.NET_SessionId”,””));

Los programadores cuando hacian las pruebas, no detectaban ninguna falencia y probaban agregar distintas alternativas o lineas de código similares para “matar” y cerrar la sesión, pero seguían con el problema.

Inmediatamente analicé la situación y comencé a probar, con algunas herramientas, intercepté los request desde mi navegador y cambiaba los parametros. Efectivamente podía ingresar a la aplicación y “quebrar” su seguridad, hasta podía utilizar distintos usuarios.

Entonces, cuál era el problema?

Muy pocos saben que las sesiones de ASP.NET tienen un tiempo de vida “extra” en el IIS.
Por lo qué pude ver alguna vez decompilando las librerias de .NET, el IIS, da un tiempo más de vida a las sesiones en el servidor para evitar (por lo que supongo al ver el código) que tenga problemas de performance el servidor. Pero lo que claramente se puede observarse es que no “mata” la sesión. Entonces uno puede enviar la cookie de autenticación desde otro cliente y sigue “logueado” a la aplicación.

Cuál es la solución?

Siempre hay que crear una variable de sesión que se inicialice en el login y se elimine en el logout.

En el global.asax, para cada request que ingrese a la aplicación, hay que verificar que esa variable siga vigente (con valor o con un valor particular, cómo por ejemplo, el ID de usuario), en caso contrario, el request es cancelado.

También se podría para fortalecer esta práctica, crear además otra cookie de autenticación customizada y que se valide con la variable del servidor y verificar ambas en cada request.

También conviene realizar una rutina que “mate” todas las sesiones abiertas que no tengan request o actividad durante cierto tiempo, porque sino, si el usuario no hace logout, la vulnerabilidad sigue vigente hasta que el IIS “mate” la sesión, se reinicie la aplicación o se recicle el pool de aplicación.

Autor: Matías Creimerman

Matías Creimerman – Consultor IT – IT Consultant

Linkedin:

http://ar.linkedin.com/in/matiascreimerman

Microsoft ASP.Net Member:

http://forums.asp.net/members/matyvegan.aspx

Microsoft Virtual Academy Profile:

https://www.microsoftvirtualacademy.com/Profile.aspx?alias=824999

About Me:

https://about.me/matiascreimerman

GitHub Repository:

https://github.com/mcrei/

certifications

mcsdlogo weblogo

Matias Creimerman

Anuncios

Deja un comentario

Archivado bajo Buenas Prácticas, Código, Seguridad

Proceso de ejecución de una aplicación MVC en .NET


Fecha en que se escribió el post: 2009-05-10

Los request en una aplicacion basada en el framework ASP.NET MVC realizan acciones diferentes a las de una aplicacion ASP .NET.
Este es el orden de ejecución:

  1. Al primer Request desde el archivo Global.asax, los objetos Route (objetos que implentan RouteBase) son agregados al objeto RouteTable
  2. El modulo UrlRoutingModule (Un modulo HTTP) usa el primer objeto Route en el objeto RouteTable para crear un objeto RouteData el cual se usa para crear el objeto RequestContext (IHttpContext) e inicia el ruteo.
  3. Se crea un controlador de requests MVC. El objeto MvcRouteHandler crea una instancia de la clase MvcHandler y le pasa una instancia de RequestContext.
  4. El objeto MvcHandler usa la instancia del RequestContext para identificar el objeto IControllerFactory para crear el controlador.
  5. El MvcHandler llama al metodo Execute del controlador.
  6. El controlador determina a que metodo de que clase controladora debe llamar. Como la mayoria de todas las clases controladores heredan de la clase base Controller puede hacerlo determinandolo desde el ControllerActionInvoker. Así invoca al metodo correspondiente del request iniciado.
  7. El metodo invocado desde el controlador realiza su funcionalidad y retorna uno de estos tipos que se pueden retornar: ViewResult, RedirectToRouteResult, RedirectResult, ContentResult, JsonResult o EmptyResult.
  8. Si el request no coincide con ninguna ruta el UrlRoutingModule no hace nada y le pase el request al proceso habitual de ASP .NET o al procesamiento de solicitudes IIS.

Deja un comentario

Archivado bajo Teoría