Prevención de problemas con las sesiones en Java

En Session Fixation Prevention in Java algunas pistas sobre el tema: el atacante obtiene un identificador de sesión válido, hace que nosotros lo utilicemos y consigue acceso a nuestra cuenta.

Para evitarlo:

1. Recibir las credenciales del usuario
2. Autentificarlo
3. La información de sesión necesaria se copia
4. Se invalida la sesión
5. Se crea una nueva
6. Se recuperan los datos temporales
7. Seguir…

Se pueden hacer más cosas y hay código de ejemplo. Interesante.

Por cierto, la primera semana del año de seguridad en Java que nombrábamos el otro día hablaba era justamente esta entrada, se puede ver también en Year Of Security for Java – Week 1 – Session Fixation Prevention.

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

Las claves como cadenas de caracteres

Un ordenador es una máquina muy compleja. Por sus propias características electrónicas, pero también por las capas que lleva encima: sistema operativo, programas y más…
En Don’t use Strings to hold Passwords! un recordatorio de cómo trata Java las cadenas de caracteres:

The essence of it is that strings in Java (and also in C#) are immutable. When you modify them it creates a new copy leaving the old one behind until garbage collected.

Eso sin contar que el Sistema Operativo puede decidir hacer ‘swapping’ y que estas claves terminen escritas en el disco duro.

Hace referencia Why is char[] preferred over String for passwords?.

Las aplicaciones en Java tienen más fallos

Ahora que el Java está de moda por los problemas de su ‘infraestructura’ (ver, por ejemplo, Grave vulnerabilidad sin parche en Java está siendo aprovechada por atacantes ) me ‘toca’ rescatar una noticia que tampoco deja en buen lugar al lenguaje.

Lo contaban en Java apps have most flaws, Cobol apps the least, study finds y se trata de un análisis de esos masivos (Que, por lo tanto, hay que tomar con prevención):

Cast Software, a maker of software quality tools that evaluate the engineering soundness of the architecture and coding of an application, analyzed the 745 applications which combined for some 365 million lines of code. The company Thursday released a report detailing the conclusions of that analysis.

Sobre Java, podría ser falta de formación y/o experiencia:

As for Java, Curtis said he can only speculate on the problems, but said that «there are many people going into Java now that really don’t have strong computer science backgrounds. We may just be seeing the fact that there is an awful lot of people writing code who aren’t gurus in software engineering.»

En New Worldwide Software Quality Study From CAST Exposes Millions in Hidden IT Costs también comentan, con cifras más concretas:

«Our findings, although conservative, revealed an average technical debt of $3.61 per line of code,» said Curtis. «A significant number of applications examined in the study — nearly 15% — had over a million lines of code which means even the smallest of those contains over $3.6 million in technical debt.»

Otras conclusiones:

– Despite assumptions to the contrary, outsourced and in-house developed applications didn’t show any difference in structure quality. The same was true for onshore and offshore applications.
– Java EE applications were the most prevalent among those studied and received significantly lower performance scores as well as carrying greater technical debt than other languages
– Established development methods such as agile and waterfall scored significantly better in structural quality than custom methods, while waterfall scored the highest in transferability and changeability.
– COBOL applications scored the highest in security, while .NET applications received the lowest security scores

Se puede ver la nota de prensa original en: New Worldwide Software Quality Study from CAST Exposes Millions In Hidden IT Costs

Curioso. Tomar con prevención, claro.

Algunas sorpresas revisando código

Un artículo que nos muestra lo truculentos que pueden llegar a ser los lenguajes de programación y sus características avanzadas. En particular, lo que podría pasársenos por alto haciendo revisiones de código. En SEC Consult Vulnerability Lab released a new whitepaper titled: «The Source Is A Lie» el resumen y un enlace para descargar el documento.

Denegación de servicio en Java

En Java Denial of Service Vulnerability (Double Trouble) se comenta sobre un fallo de Java y algunas versiones de PHP que entraban en un bucle infinito al convertir la cadena «2.2250738585072012e-308» en un valor de punto flotante de doble precisión. Esto podría provocar un ataque de denegación de servicio y, más allá de los detalles del problema y de cómo evitarlos, se comenta:

This bug is an excellent example of the evolving software security landscape. Until this problem came along, calling parseDouble() looked like an ideal way to validate input. Now parseDouble() is yet another weak point to protect. And so it goes. When you ship software, you have to make sure it’s protected against the risks we know about today. But when you wake up tomorrow, new risks may well have emerged during the night. Building secure systems means more than just avoiding foreseeable mistakes. It means preparing for the unforeseeable too. That means being ready to respond when new vulnerabilities emerge

Aparecen nuevos puntos débiles contínuamente, de manera que tenemos que estar preparados no sólo para evitar los desastres que ya conocemos, sino los que puedan aparecer en el futuro y, en particular, repsonder a los que puedan ir surgiendo y nos afecten.

Doce reglas para desarrollar código en Java más seguro

Otro artículo rescatado del ‘cajón’: Twelve rules for developing more secure Java code. Como dice al principio, son bastante técnicas y se refieren a aspectos para los que se requiere un conocimiento profundo del lenguaje. Pero quién sabe si algún día podemos llegar a necesitarlas.

Algunos aspectos de seguridad de Java EE 6

En el tema de la seguridad casi todo va con retraso: hace unos años alguna gente empezó a preocuparse del tema y detrás va todo lo demás. En Java EE 6: Web Application Security made simple ! hablan de los servicios de seguridad disponibles desde los programas (a través de bibliotecas y APIs adecuadas) de Java EE 6: autentificación, login, logout y otras primitivas. Aunque, como dicen los comentarios no es oro todo lo que reluce, al menos vemos que desde los los desarrolladores de las herramientas empieza a haber interés por estos temas.

Veo que, además, Sun ha publicado el Secure Coding Guidelines for the Java Programming Language, Version 3.0.