Archivo de la etiqueta: Buenas Prácticas

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

.NET Buenas Prácticas – Clases, estructuras e interfaces


Las clases y estructuras deben usar nomenclatura Pascal y deben tener nombre de sustantivos o frases de sustantivos, por ejemplo: “Car” o “CarType”.
De esta forma se diferencian de los métodos que son frases verbales.

Las interfaces deben usar nombres de frases de adjetivo, o de vez en cuando con nombres o frases nominales. Sustantivos y compuestos deben ser utilizados en raras ocasiones ya que podrían indicar que el tipo debe ser una clase abstracta, y no una interfaz. Por ejemplo: “IFormatable”.

No usar prefijos en ningún caso. Solo las interfaces deben incluir el prefijo “I”, por ejemplo: “IComparable”

En la mayoría de las ocasiones se recomienda terminar el nombre con el de la base clase, por ejemplo: “ArgumentOutOfRangeException”. De esta forma se da claridad y relación, pero hay ocasiones en las cuales no debería usarse (la clase Button es de tipo Control, pero no por eso se la denomina ButtonControl). Queda a consideración de cada uno si lo incluye o no, pero en muchas ocasiones es mejor agregar la clase base al nombre.

Nomenclatura para tipos que heredan de tipos base

Atributos (System.Attribute): Agregar sufijo “Attribute”

Delegados (System.Delegate): Agregar sufijo “EventHandler” para los eventos y “Callback” para los que no son eventos. Nunca usar “Delegate”.

Argumentos de Eventos (System.EventArgs): Agregar sufijo “EventArgs”.

Enumeradores (System.Enum): Nunca usar prefijos ni sufijos como por ejemplo “Enum” o “Flag”.

Excepciones (System.Exception): Usar sufijo “Exception”.

Colecciones (IEnumerable, ICollection, IList, IEnumerable, ICollection, IList): Usar sufijo “Collection”.

Flujos (System.Stream): Usar sufijo “Stream”.

Permisos (CodeAccessPermission, IPermission): Usar sufijo “Permission”.

Enumeradores

Utilizar un nombre de tipo singular para una enumeración a menos que sus valores son campos de bits.

Utilizar un nombre de tipo plural para una enumeración con campos de bits como valores, o los denominados “banderas/flags”.

Nunca usar el sufijo ni prefijo “Enum” o “Flag”.

Nunca utilizar ningún tipo de prefijo.

1 comentario

Archivado bajo Buenas Prácticas, Código

.NET Buenas Prácticas


Hoy voy a comenzar una guía de buenas prácticas para .NET, desde las más básicas hasta las más complejas.

A medida que vaya sumando nuevos posts, ire ampliando la lista desde este.

 

 

Deja un comentario

Archivado bajo Buenas Prácticas, Código, Teoría

.NET Buenas Prácticas – Convenios para capitalización


Las buenas prácticas sobre convenios de capitalización ayudan a mejorar el entendimiento del código y la nomenclatura según los componentes del software.

Existen 3 definiciones de nomenclaturas:

 

Pascal: La primer letra de cada palabra concatenada de un nombre se indica en mayúscula.
Por ejemplo: TopBorderSize

Camel: La primer letra de toda la palabra se indica en minúscula y cada primer letra de cada palabra concatenada siguiente en mayúscula.
Por ejemplo: topBorderSize

Uppercase: Todas las letras en mayúsculas.
Por ejemplo: ID

 

En ningún caso usar separadores para las palabras concatenadas.

 

Reglas

 

Clases  –  Pascal
Tipo de enumerador – Pascal
Valor de enumerador – Pascal
Evento – Pascal
Excepción – Pascal
Campo estático de sólo lectura – Pascal
Intefaces – Pascal
Métodos  – Pascal
Namespaces – Pascal
Parámetros – Camel
Propiedades – Pascal
Acrónimos  – Uppercase

 

Excepciones a las reglas

 

Sólo los acrónimos tienen expceciones:
1. Todo parametro que posea un acrónimo se indica en Camel. EJ: xmlStream
2. Toda palabra con acrónimo de más de 2 letras, se indica en Pascal. EJ: XmlStream
3. Toda palabra con acrónimo de 2 letras, se indica en Uppercase. EJ: DBConnection

 

1 comentario

Archivado bajo Buenas Prácticas, Código, Teoría