Archivo de la etiqueta: arquitectura

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

La parte más dificil de desarrollar un sistema, es decidir qué desarrollar


“La parte más dificil de desarrollar un sistema es decidir qué desarrollar… ninguna otra parte hace fallar tanto el sistema resultante si se hace mal. Ninguna otra parte es más difícl de rectificar después”.

La experiencia acumulada a lo largo de los años de ejecutar proyectos indica que los proyecto exitosos son aquellos que son administrados siguiendo una serie de procesos que permiten organizar y luego controlar al proyecto.

Es sin dudas un objetivo fundamental de los diseñadores de software alcanzar y mantener un nivel técnico en los sistemas, acorde con el desarrollo actual en la automatización de la información para la gestión y la dirección, y es conocida la importancia de la ingeniería de software para elevar la productividad y la calidad en diseños de sistemas automatizados a partir de un examen detallado de las metodologías existentes.

La rama de la metodología, dentro de la ingeniería de software, se encarga de elaborar estrategias de desarrollo de software que promuevan prácticas adaptativas en vez de predictivas; centradas en las personas o los equipos, orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que requieren implicación directa del cliente.

Muchos investigadores en sus estudios acerca del tema de las metodologías de desarrollo de software se han detenido a definir el concepto de metodología, algunas de estas definiciones se muestran a continuación.

En el trabajo “Una Metodología para el desarrollo de Base de Datos” se dice que una metodología es un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de un producto de software.

Una metodología define:

• Estados, etapas o fases de un desarrollo, junto con los criterios de transición entre ellos.

• Tareas, actividades, etc.

• Roles, con sus skills necesarios y las interacciones entre ellos.

• Artefactos o entregables.

• Herramientas de control, seguimiento, medición y perfeccionamiento.

• Principios, criterios para tomar decisiones, estrategias para manejar distintos tipos de situaciones, herramientas de manejo de riesgos, etc.

La dificultad propia del desarrollo de software, y su impacto en el negocio, han puesto de manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodología formal para llevar a cabo los proyectos de este tipo.

El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles, que permitan obtener un producto de alta calidad, que satisfaga las necesidades y expectativas del cliente. Atrás queda el modo de trabajar artesanal, que a menudo requiere grandes esfuerzos para obtener el resultado final, con los consecuentes desfases de fechas y coste, y es más que probable el desgaste personal del equipo de proyecto. Por lo que utilizar las metodologías implica mejoras en los procesos de desarrollo, en el producto y en la satisfacción del cliente.

Mejoras de los procesos de desarrollo

• Todos los integrantes del equipo del proyecto trabajan bajo un marco común.

• Estandarización de conceptos, actividades y nomenclatura.

• Actividades de desarrollo apoyadas por procedimientos y guías.

• Resultados de desarrollo predecibles.

• Uso de herramientas de ingeniería de software.

• Planificación de las actividades en base a un conjunto de tareas definidas y a la experiencia en otros proyectos.

• Recopilación de mejores prácticas para proyectos futuros.

Mejoras de los productos

• Se asegura que los productos cumplen con los objetivos de calidad propuestos.

• Detención temprana de errores.

• Se garantiza la trazabilidad de los productos a lo largo del proceso de desarrollo.

Mejoras en las relaciones con el cliente

• El cliente percibe el orden en los procesos.

• Facilita al cliente el seguimiento de evolución del proyecto.

• Se establecen mecanismos para asegurar que los productos desarrollados cumplan con las expectativas del cliente.

En ocasiones, el diseñador al escoger entre la variedad de lenguajes, técnicas, métodos y otros, prefiere hacer las cosas como mejor le convenga y sacar el diseño lo más pronto posible lo cual resulta ser una decisión nada acertada, que más que ayudar en tener un sistema lo más pronto posible funcionando resulta un sistema poco funcional donde abundará la generación posterior de errores.

Una mala práctica en el desarrollo de software, es comenzar a intentar desarrollar sin

realizar ningún tipo de análisis, tratando de partir del modelo de datos; esto generalmente

tiene drásticas consecuencias ya que no existe un orden para solucionar el problema. Surge la necesidad de seguir un proceso ordenado, esta es la Metodología.

La Metodología es definida como el conjunto de procedimientos basados en principios lógicos que son utilizados para alcanzar un objetivo. Seguir un proceso estructurado que se adapte a una situación específica al momento de desarrollar un software incrementa la probabilidad de éxito, ya que estas metodologías han sido probadas bajo ciertos factores en un contexto específico y han resultado exitosas, por lo que integrarla al proyecto consiste en identificar que metodología se acopla más a la situación y utilizarla.

Documentar el software es necesario independientemente de la estrategia de desarrollo que sigamos. Una buena documentación nos va a permitir mantener una visión completa del software, ayudándonos a comprender las características del sistema y a modificarlo en caso de que sea necesario. La documentación no se realiza para uno mismo, sino para los demás, ayudando a eliminar la dependencia de las personas.

Por lo tanto, documentar un software siempre será útil, aunque en un principio pueda no parecerlo. Tener una buena documentación, proporcional al tamaño del software desarrollado, puede ser tan importante como tener un buen software.

Uno de los grandes problemas que enfrenta el desarrollo de software, es la poca utilización de metodologías, la pequeña y mediana empresa creen que el uso de las metodologías es solo para las grandes, la postura de las empresas ante el mercado, es que se desea el producto completo lo más rápido posible, por lo que no consideran la necesidad de una metodología, como no miran el avance a corto plazo, lo siente una pérdida de tiempo y prefieren empezar a desarrollar lo antes posible sin dedicarle tiempo al análisis y diseño del software. La poca aceptación y la ignorancia es uno de los mayores retos hacia las metodologías ya que no se comprende la importancia fundamental en el desarrollo de software, al no ser utilizadas las consecuencias pueden ser catastróficas, el software en vez de ser una solución al problema, se convierte en otro problema que resolver. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.

Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en escala, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.

¿Contingencias? Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos.

Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis.

¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar.

Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él.

No se trata de hacer tabula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta.

Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.

Deja un comentario

Archivado bajo Teoría

Qué es la programación? (Parte 1)


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

Programar es la tarea de crear las instrucciones necesarias para generar funcionalidades que un dispositivo pueda interpretar. Por ejemplo, para que un televisor funcione, fue necesario “programarlo” para que pueda prestar las funcionalidades para las que fue creado. En la mayoría de los casos los dispositivos electronicos son programables. Pero la programación adquirió un significado más importante desde que existen las computadoras, ya que estos dispositivos fueron creados para realizar multiples tareas que las realizan según el “software” que tengan instalado. Y qué es el software? es el conjunto de todos los aplicativos y programas que tiene un computador. Cada programa y aplicativo es un conjunto de instrucciones que han sido programadas para dar distintas funcionalidades.
Cada instruccion indica que paso debe tomar el computador para llevar a cabo una determinada tarea. Para realizar una tarea particular que puede ser un paso de otra tarea mayor, se agrupan las instrucciones dentro de “funciones”. Por ejemplo, una tarea que realiza el hombre habitualmente es la de comer. Para comer, el hombre realiza pequeñas funciones que dan como resultado esta tarea (abir la boca, morder, masticar, salivar, mover la lengua, tragar, etc). Y por qué la programacion necesita identificar estas “funciones”? porque algunas son reiterativas y se realizan de la misma forma, con lo cual, identificarlas nos permite programarlas una sola vez y reutilizarlas (por ejemplo abrir la boca no solo se realiza en la tarea de comer, sino tambien en la de hablar y otras más).
De qué forma se programa? cada tarea y sus funciones, están constituidas de una forma lógica, que se genera a partir de “algoritmos” y “estructuras de datos”.
Qué es un algoritmo? un algoritmo son las operaciones ordenadas para llegar a un determinado objetivo o solución. Existen muchisimos algoritmos, algunos son de indole cientifica y otros se llevan acabo frecuentemente en la vida cotidiana, desde las operaciones que debemos realizar para hacer nuestro trabajo hasta los calculos que realizamos en la escuela para llegar a una solución. No hay que confundir un algoritmo con un programa, aplicativo o sistema (algo que suele pasar) ya que el algoritmo es la definicion de ese método y un programa ejecutable en un computador es el conjunto de codigo escrito por el programador que luego se compila para ser entendido por el computador o dispositivo (el codigo se transforma a otro codigo que puede interpretar el computador o dispositvo, llamado codigo maquina).
El algoritmo no puede ejecutarse. La implementacion de ese algoritmo es la que se ejecuta, ya sea, desde un codigo de programacion o un circuito electronico, entre otros. Para que un algoritmo se implemente, necesita “procesar” o “computar” la informacion. Esta informacion es la “estrucura de datos” (variables, propiedades, valores, clases, objetos) que identifican la forma de agrupar logicamente los datos para manipularlos, de forma que existiendo “estructuras de datos” de entrada se lleguen a “estructuras de datos” de salida. Cuando se procesan las estructuran de datos, se las crean, se las modifican, se las eliminan, se las ordena, se las busca, etc.
Existen distintas estructuras de datos para definir tipos comunes que nos permiten utilizarlos de distintas formas para distintos casos. Por ejemplo, no es lo mismo una estructura de texto, que una numerica, que una de listas, que un conjunto, que una tabla…

CONTINUARÁ…

Deja un comentario

Archivado bajo Teoría