Archivo mensual: septiembre 2016

LINQ UNION-ADDRANGE DIFFERENCE – DIFERENCIA


Hoy me preguntaron si no era lo mismo hacer un AddRange en una colección que un Union de LINQ y claramente la respuesta es NO!.

Por qué no es lo mismo hacer un AddRange que hacer un Union y asignar a la misma colección?

Porque el AddRange repite información en cambio el Union no agrega datos repetidos (salvo que sean instancias distintas con colecciones de objetos).


Today a developer asked me if using AddRange over a collection was the same that using LINQ’s UNION, and as a matter of fact the answer was “NO!”.

Why is not the same to do AddRange or to do Union and assign to same collection?

Because the AddRange repeats information, on the other hand, UNION does not add repeated data (unless they are different instances with object collections).

Veamos código (Let’s check out code)…

class Program
{
static void Main(string[] args)
{
Console.WriteLine(“*******************************”);
Console.WriteLine(“Probando Union y AddRange”);
Console.WriteLine(“*******************************”);

Console.WriteLine(“Agrego a la lista nros del 1 al 10”);
List list = GetNewList(0, 10);

Console.WriteLine(“Creo otra lista de nros del 1 al 10”);
List list2 = GetNewList(0, 10);

Console.WriteLine(“Hago un Union y muestro”);
list = list.Union(list2).ToList();

foreach (var l in list)
{
Console.WriteLine(“Nro: {0}”, l);
}

Console.WriteLine(“Reinicio listas, hago AddRange y muestro”);
list = GetNewList(0, 10);
list.AddRange(list2);

foreach (var l in list)
{
Console.WriteLine(“Nro: {0}”, l);
}

Console.ReadKey();
}

static List GetNewList(int baseNumber, int length)
{
List rv = new List();
for (int i = baseNumber; i < length; i++)
{
rv.Add(i);
}
return rv;
}
}

unionaddrange

Anuncios

Deja un comentario

Archivado bajo Código

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.

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