Sobre las sesiones (más o menos) permanentes

En How to build (and how not to build) a secure “remember me” feature Troy Hunt nos da ideas sobre el botoncito que tienen casi todas las aplicaciones web que permite que la próxima vez que volvamos a utilizarlas recuerden toda (o parte) de nuestra información a la hora de autentificarnos en el sistema.

Cosas que se pueden hacer mal, información que no sería necesaria pero que se almacena de alguna forma…. Y algunos ejemplos del ‘mundo real’ que parece que ya no deberían ser fáciles de encontrar.

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

Protección contra CSRF sin estado

En Stateless CSRF Protection se dan algunas ideas sobre protección contra CSRF (Cross Site Request Forgery) cuando no tenemos la ayuda de las sesiones en el servidor. En el caso de que tengamos una sesión, los consejos hablan de utilizar algún identificador adicional que envía el servidor y hay que re-enviarle, de forma que si la petición no viene de donde debe, ese identificador no será correcto.

Traditional anti-CSRF techniques use tokens issued by the server that the client has to post back. The server validates the request by comparing the incoming token with it’s copy. But that small word “copy” means server-side state. Not good.

Cuando no tenemos estado en la aplicación (cosa rara, la verdad, porque parece que eso de tener unas galletitas y sesiones se hace hasta cuando no hace falta para nada), la idea se que el cliente calcule un identificador y lo envíe como cookie y dentro de la petición (de esa forma sería más difícil para un atacante obligar a un usuario a enviar esa petición).

The protective measure of double submit lies in the fact that a malicious site cannot read the cookie and include it as request parameter. That condition still holds if the cookie is generated by the client and never saved by the server.

So let the client generate the anti-CSRF value and only compare and check format of cookie and request parameter on the server. Ergo, stateless CSRF protection!

Pistas sobre criptografía y otros

Como decíamos el otro día en Pistas sobre autentificación en aplicaciones web la serie de Cheat Sheets es muy interesante, y va acompañada de algunas explicaciones en los OWASP Podcast que todavía las hace más valiosas.

Por no poner entradas separadas para cada una de ellas me permito recomendar algunas más:

Cryptographic Storage Cheat Sheet con algunas cuestiones que a veces se olvidan en la gestión de datos cifrados (el podcast correspondiente sería el 68, [mp3] Kevin Kenan (Cryptographic Storage).

Transport Layer Protection Cheat Sheet sobre protocolos de transporte (y el podcast sería el 70, [mp3] Michael Coates (TLS).

SQL Injection Prevention Cheat Sheet (y un podcast sobre el tema sería el 29, OWASP Interview with Justin Clarke.

Todos son recomendables, pero marco aquí los que he ido escuchando hace menos tiempo y he encontrando interesantes.

INTECO: sobre la seguridad de sitios web

Revisando el baúl de los recuerdos (esas lecturas que se quedan en el kindle pendientes de algo) rescato este informe del INTECO: [PDF] Seguridad en sitios web con consejos a tres niveles:

– Detección de los ataques
– Minimizar los daños producidos por un ataque
– Puesta en marcha de medidas preventivas para evitar que un sistema llegue a estar comprometido

Fortalecimiento de PHP

Algunas generalidades sobre la configuración de PHP (siempre que podamos tocarla) en Hardening PHP mediante php.ini. Los lenguajes van ofreciendo estas medidas para remediar fallos detectados a un nivel más profundo. No es la panacea (e, insisto, a lo mejor ni siquiera podemos tocarlo, o los programas no funcionan) pero puede ser una buena idea echar un vistazo.

Las claves

Interesante el podcast de la OWASP sobre recuperación de claves ([mp3] forgot password) sobre la manera recomendada de recuperar una cuenta cuya clave hemos perdido (se pueden leer los consejos en: Forgot Password Cheat Sheet, aunque mucho me temo que es una visión parcial del problema, puesto que habla del bloqueo de cuentas y eso no siempre es factible/razonable y se ocupa de sitios con bastantes datos del interesado que tampoco es siempre el caso).
Escuchándolo, pensé en recopilar y poner los últimos enlaces sobre el tema que he ido recopilando. Por cierto, interesante el sitio Good Security Questions, que nos da una idea de buenas opciones para esta parte tan delicada (imagino que también habrá que prestar atención a las cuestiones culturales, así que convendrá tomarlas con una ‘pizca de sal’).

En The truth about passwords. Un análisis de las claves, la seguridad y la facilidad de uso bastante interesante. La conclusión:

It seems that the easy systems aren’t secure, and the recommended systems aren’t usable, because they take too long or require too much remembering.

En The Usability of Passwords que habla sobre seguridad razonable, alargando las claves mediante el uso de frases, más fáciles de recordar. Tiene sus detractores. Yo diría que la longitud ayuda pero que, seguramente, sería buena idea no utilizar sólo palabras que forman frases.

Por si acaso, A brief Sony password analysis:

La gente elige malas claves, pero sus propias malas claves, no hay muchas repeticiones:

However in the grand scheme of things, there weren’t a whole lot of instances of multiple people choosing the same password, in fact the 25 above boiled down to only 2.5%. Furthermore, 80% of passwords actually only occurred once so whilst poor password entropy is looking rampant, most people are making these poor choices independently and achieving different results.

Eso sí, la gente usa la misma clave (hay gente que lo hace en una cantidad
notable, al menos) entre diversos sitios:

Two thirds of people with accounts at both Sony and Gawker reused their passwords. Now I’m not sure how much crossover there was timeframe wise in terms of when the Gawker accounts were created versus when the Sony ones were. It’s quite possible the Sony accounts came after the Gawker breach (remember this was six months ago now), and people got a little wise to the non-unique risk. But whichever way you look at it, there’s an awful lot of reuse going on here.

Finalmente, con un ataque sencillo se adivinarían bastantes claves (y la importancia de la longitud de las claves):

82% of passwords would easily fall to a basic rainbow table attack. Not good, but you can see why the rainbow table approach can be so effective, not so much because of its ability to make smart use of the time-memory trade-off scenario, but simply because it only needs to work against a narrow character set of very limited length to achieve a high success rate

Y la conclusión: The only secure password is the one you can’t remember.

Para terminar, el aviso de que Hotmail: Microsoft bans the use of vulnerable passwords lo que redundara, seguramente, en una nueva generación de malas claves (es broma).

Sobre prevención de Cross Site Scripting

En Preventing XSS Attacks un artículo generalista sobre el tema. Recomiendan un proyecto alojado en Google Code:

If you are using Java, then a good place to go is XSS Protect, a project hosted on Google code. It claims to filter all “known” XSS attacks from HTML code. PHP boasts a more comprehensive library called HTML Purifier which licensed as Open Source and can be customised depending on your needs. HTML Purifier also boasts strict standards compliance and better features than other filters.

Supongo que es este, pero no lo tengo claro del todo: XSS Protect.

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