En los  últimos posts he estado hablando sobre la seguridad de ASP.NET basada en Forms. Esto ha traído algunas preguntas por parte de los visitantes. Una de ellas, bastante común, es la de cómo almacenar información adicional atada a los usuarios que hemos autenticado.La API de Membership que viene con ASP.NET, y en concreto el proveedor de Membership para trabajo contra SQL Server (SqlMembershipProvider) nos provee de los medios suficientes para almacenar la información básica sobre los usuarios, esto es, el nombre, su login y su clave, que es lo mínimo necesario para trabajar. En este gráfico puedes ver la estructura completa creada por ASP.NET (más bien por aspnet_regsql.exe) en nuestra base de datos para dar soporte a SqlMembershipProvider y relacionados.Obviamente casi siempre necesitaremos almacenar mucha más información sobre ellos, relacionándola de manera directa y sencilla para poder extraerla. Así, por ejemplo, podemos necesitar almacenar sus datos de contacto, infromac... [Más]

En mi anterior post hablaba sobre el funcionamiento de las cookies en los navegadores y de cómo podíamos usar una extensión estándar (HttpOnly) para intentar impedir que las cookies sean accesibles desde el lado cliente y sólo se puedan manejar desde el servidor. No obstante se trata de una medida que, de funcionar, complica un poco a los posibles piratas, pero no es una verdadera barrera de seguridad. Para empezar ni siquiera está soportada por todos los navegadores. Las cookies residen en el disco duro del usuario por lo que son fáciles de manipular por cualquiera. Además se envían al servidor en cada petición, por lo que cualquiera con un proxy estilo Fiddler puede leerlas y manipularlas antes de enviarlas al servidor. Es decir, las cookies son elementos realmente inseguros. A raíz de estas disquisiciones alguien me escribió preguntándome por la seguridad de la autenticación Forms de ASP.NET (la más habitual). Ésta se basa precisamente en la existencia de una cookie que identific... [Más]

Una de las técnicas de hacking de páginas web más conocidas es la de Cross-Site-Scripting o XSS. Mediante esta técnica, las aplicaciones Web vulnerables pueden ser atacadas para multitud de propósitos: servir de zombies para atacar a otras Webs inundándolas con peticiones, ejecutar código en zonas de seguridad menos restrictivas (como la local) o, sobre todo, robar la identidad de los usuarios del sitio vulnerable. Ha sido utilizado tradicionalmente en combinación con correos electrónicos maliciosos para entrar en sitios Web protegidos suplantando la identidad de usuarios autenticados. En mi curso de Desarrollo de aplicaciones seguras y seguridad de .NET monto un ejemplo completo de cómo utilizarlo en un supuesto sitio de banca electrónica (muy mal hecha y vulnerable), para robar la sesión del usuario y entrar en su cuenta. Este robo de sesiones se basa en la obtención mediante XSS de la cookie de sesión de un usuario, enviándola a un servidor bajo el control del atacante. Éste al rec... [Más]

Lo reconozco, no me he podido resisitir más. Las presiones eran demasiado fuertes y me he metido en Facebook. Llevo sólo un par de días y la aplicación, técnicamente hablando, me parece que está muy bien por lo que he podido ver (el UI). Me gusta mucho su sencillez, la agilidad de la interfaz AJAX, el chat, las notificaciones, etc.. Pero hoy, dándole al botón de "Me gusta" se ve que coincidí en el mismo preciso instante con otra persona haciendo lo mismo (porque justo a continuación aparecía una notificación al respecto) y fijaos el mensaje que me apareció: No me digas que no es flipante: una aplicación con decenas de millones de usuarios, super-escalable, y ¿me aparece esto?. Creo que he encontrado la aguja en el proverbial pajar. Es un don que tengo :-) Al menos sale en un formato apropiado y no "casca" miserablemente como pasa con otras. ¿Alguien sabe qué tecnología usa FaceBook por debajo? SQL Server seguro que no ;-)¿Y para la parte de programación Web de servidor? Si algui... [Más]

La metodología clásica de creación de páginas Web recomienda que todos nuestros scripts se encuentren en la cabecera de la página. Está bien tener un orden pero realmente no es necesario. Es más, nadie nos dice que no podamos incluso tener varias cabeceras en la página, una por ejemplo, después de cerrar la etiqueta </body>, si queremos. Hay algunas aplicaciones que usan mucho JavaScript. Sobre todo ahora con el uso masivo de capacidades AJAX en las aplicaciones Web. Algunos de estos scripts son simples bibliotecas de funciones con decenas o cientos de ellas que lo único que hacen es retrasar la carga de página mientras son procesadas por el navegador, ya que éste no sólo carga cada Script sino que también lo interpreta y ejecuta a medida que lo va leyendo. En otros casos el script necesita tener acceso a todos los elementos de la página antes de poder actuar (es decir, el HTML de la página debe ser procesado por completo y el árbol DOM construido). Si lo colocamos en la cabecer... [Más]

Llevo usando la banca electrónica de diversos bancos desde hace muchos años. Incluso creo que debo de haber sido de los primeros usuarios de algunas de ellas, sufriendo su mal funcionamiento en los primeros años. Recuerdo que en algún caso hasta detecté problemas de seguridad (hace ya una década) avisando a los interesados, que los parchearon enseguida pero ni siquiera tuvieron la decencia de dar las gracias. Lo cierto es que para ser aplicaciones de tanta responsabilidad y tan ampliamente usadas, la mayoría de las bancas electrónicas que conozco son aplicaciones Web bastante mal hechas, sobre todo desde el punto de vista de la usabilidad, donde les queda mucho camino por recorrer a casi todas. Actualmente utilizo 5 bancas electrónicas de otros tantos bancos, y son todas para echarse a temblar a excepción, quizá, de la de Fibanc. Una que me sorprende siempre negativamente y que es una de las que más años llevo usando, es la del Banco Santander. Desde mi punto de vista ni siquiera en ... [Más]

Uno de los posts más visitados de mi blog es en el que comento cómo evitar que las sesiones caduquen por inactividad. Es la tercera parte de una serie de posts sobre caducidad de sesiones en ASP.NET. Ha habido también muchos comentarios y parece que a mucha gente le cuesta bastante implementar la solución, por lo que tras varias peticiones (tanto en mi blog original, JASoft.org, como en Geeks.ms) me he decidido a generar un vídeo práctico mostrando como se hace.  Es del estilo de los que tenemos en los cursos de campusMVP pero con mucha peor calidad, que viene impuesta por las limitaciones de SOAPBox. Lo cierto es que estos sitios de vídeo en Internet no son los más adecuados para este tipo de grabaciones por su elevada compresión, que limita la calidad, pero bueno... se deja ver. A ver si lo puedo colgar en Channel9 de Microsoft en breve y así que podáis verlo con major calidad: