Archivo de la etiqueta: asp .net

No utilices debug=”true” en ambientes productivos en websites ASP.NET- Don’t use debug=”true” in production environments on ASP.NET websites


Prohibido utilizar debug=”true” en ambientes productivos

Not use debug=”true” in production environments

Por qué no hacerlo?

  1.  La compilación de las páginas lleva mucho más tiempo, ya que se deshabilitan algunas optimizaciones.
  2. El código se ejecuta más lentamente ya que algunas ejecuciones en debug, ejecutan más código.
  3. Todo lo descargado por WebResources.axd no se almacena en el caché del navegador, lo que ocasiona más solicitudes entre cliente y servidor.
  4. Se cargan símbolos de depuración.
  5. Puede permitir algunas vías de ataques y la capacidad de detectarse de forma remota.
  6. Se generan más archivos temporales de ASP.NET y la compilación por lotes se desactivará, incluso si el atributo de lote es verdadero en el elemento .
  7. El System.Diagnostics.DebuggableAttribute se agrega a todo el código generado que hace que el rendimiento se degrade. El DebuggableAttribute se agrega a todo el código generado.
  8. Se utiliza dentro de la aplicación en tiempo de ejecución mucha más memoria.

 

Why don’t do it?

  1. The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled).
  2. Code can execute slower (since some additional debug paths are enabled).
  3. Scripts and images downloaded from the WebResources.axd handler are not cached by the browser, resulting in more requests between client and server.
  4. Compiled with debug symbols are loaded.
  5. Debug mode may open some pathways to other exploits based on the performance overhead it places on the app and the ability to remotely detect it.
  6. You will see a lot more files in Temporary ASP.NET files folder
    Batch compilation will be disabled even if the batch attribute is true in the element.
  7. The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation.Basically, when you have debug=true, the DebuggableAttribute gets added to all generated code.
  8. Much more memory is used within the application at runtime.
Anuncios

Deja un comentario

Archivado bajo Buenas Prácticas, Uncategorized

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

Deja un comentario

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

ASP .Net Routing MVC


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

Las aplicaciones ASP .NET MVC son aplicaciones centradas en logica y no en contenidos como en ASP .NET. Esto se debe a que los requests estan mapeados a acciones de los controladores y no a paginas como en ASP .NET.

Este mapeo a acciones de los controladores se denomina Routing. El routing utiliza una tabla de ruteo para mapear las acciones. Esta tabla se crea cada vez que se inicia la aplicacion. La definicion de la tabla se crea en el archivo Global.asax al momento de ejecutarse el metodo Application_Start(). El metodo MapRoute() del objeto RouteTable agrega una ruta a la tabla de ruteos. Por default una aplicacion MVC ejecuta el metodo de la siguiente forma:

RouteTable.MapRoute(“Default”,”{controller}/{action}/{id}”,new { controller = “Home”, action = “Index”, id = “” });

Esto significa que la ruta por default de la aplicacion (Default) sera igual a: domain/Home/. Esta ruta esta controlada por el controller Home y ejecutara el metodo Index con el parametro id igual a “”.

El routing debe configurarse, por default cuando creamos una aplicacion MVC se configura automaticamente.

Deja un comentario

Archivado bajo Teoría