El año de seguridad en Java

John Melton comenzó a principios de este año su serie sobre seguridad para Java. Aunque los ejemplos son con este lenguaje, lo cierto es que casi siempre la prsentación es suficientemente general como para aprender/recordar algunas cosas aunque Java no sea nuestro lenguaje favorito. Comenzó con Year Of Security for Java – Introduction y lleva hasta ahora más de cuarenta entradas, todas muy interesantes.

Por poner una pega, no hay un índice. La búsqueda por Java Security en el blog debería ayudar.

Considero su lectura muy recomendable para cualquier persona interesada en estos temas, como recordatorio, temas en los que no habíamos pensado tanto …

Actualización: la serie ha terminado y pueden verse todos los enlaces en

Year Of Security for Java – Conclusion and Links y también descargar un pdf con todo, tal y como se anuncia en Year of Security for Java – PDF

Anuncios

Fallos por todas partes

Algo que la gente no cree cuando se lo decimos es que todo el mundo comente fallos (algunos que pueden tener consecuencias verdaderamente graves), hasta los más grandes. Por eso es bueno recopilarlos, para tenerlos a mano cuando hace falta recordarlo. En este caso es Hacking Google for Fun and Profit donde nos cuentan algunos fallos para desvelar información sobre usuarios de gmail: por ejemplo, cómo era posible determinar si un usuario había enviado un mail a otro. Se utilizaban fallos de Cross Site Request Forgery (CSRF), esto es, cuando engañamos al navegador (y al sitio, claro) para que haga una petición en nombre del usuario de la que somos capaces de sacar partido.

5 decisiones de diseño que afectan a la seguridad de aplicaciones web

En 5 Key Design Decisions That Affect Security in Web Applications algunos puntos para tener en cuenta. Ya he dicho en vidas anteriores que a mi las listas me asustan mucho (sobre todo por lo que puedan dejarse; también porque fijan la atención en unas cosas y, por lo tanto, la alejan de otras) pero estoy seguro de que algunos aprenderán cosas con esta y otros las recordarán:

  • Replicación de sesiones
  • Contexto de autorización
  • Etiquetas vs código en las vistas
  • Elección del entorno de desarrollo
  • Registro y monitorización

Seguridad pasiva

En clase lo comentamos de vez en cuando: la industria de la seguridad informática debería aprender de tantas otras industrias que ya han recorrido antes parte del camino. En la bitácora que recientemente he descubierto de Dick Lipton lo cuenta aplicado a la informática en general (que tampoco es mala idea), en Trains, Elevators, and Computer Science: los productos deberían ser robustos sin hacer nada, no por las acciones encaminadas a ello.

El ejemplo más sencillo es el de los frenos del tren: mientras el sistema funciona correctamente el tren puede correr (y frenar, claro); cuando algo falla, los frenos quedan activados (y frenando). De esta forma el fallo no puede conducir al efecto contrario: que se rompa algo y no sea posible detener el tren. También explica un sistema similar para los ascensores.