¡De sesiones va la cosa!

Hoy, en esta tarde de domingo, para unos de descanso y para otros de trabajo, vengo a hablar de sesiones, cookies o como demonios queráis llamarlos ya que el nombre no es importante.

En esta entrada, vamos a tocar (quizás para algunos mostrar) un vector de ataque que puede ser irrelevante para una gran mayoría de los actuales programadores. ¿De que estoy hablando? ¡Pues de sesiones va la cosa!

¿Que es una cookie?

Esto no es una definición de diccionario, es de mi propia cosecha y como un servidor, es simple. Vamos a definirlas como elementos que permiten guardar la sesión de un usuario para que este no tenga que introducir continuamente sus datos en cada acceso.

Los que me estéis leyendo seguro que ya os oléis un vector de ataque y ya no os centraréis solamente en atacar la parte del cliente. }:))

Me gustaría aclarar que, el simple hecho de utilizar cookies no es un factor de inseguridad, ya que el fallo está en entregar una única e irreemplazable a cada usuario. A lo largo del post trataré de mostrar factores que pueden ayudar a crear una cookie más segura.

1. - ¿Cookie insegura?

En este ejemplo de cookie a primera vista observamos algo claro. Si robamos la cookie de cualquier usuario estaremos bajo su sesión como si hubiésemos introducido sus datos. ¡Sin problemas!

Cuando se compruebe la cookie todo estará bien, sin importar la ip del usuario, su navegador, o otros aspectos.

Ahora si, ¿no? Es importante que la sesión esté cifrada bajo un algoritmo one-way que no sea reversible. También, como mayor medida concatenar una "string" de creación propia al cóctel puede ayudar a dificultar la falsificación de la sesión.

Es importante también, dependiendo, controlar el tiempo que va a funcionar hasta que esta expire y sea descartada. PHP nos permite que solo se cree si estamos usando https.

Os recomiendo a todos vosotros, programadores o interesados en la seguridad de la información, echarle un vistazo a la función que siempre está bien conocer. };))

Aunque siempre quedan "cafres", que crean la sesión y la usan en la página principal de su sistema pero obvian que nadie no conectado pueda usar dichas funciones.

Puede que aquí los mecanismos de implementación de sesiones sean perfectos, incluso mejores que la modificación que muestro arriba. ¿Que falla?

FAIL! Cualquier persona podría usar todas las funciones sin disponer tan siquiera de usuario y password, ni de cookie, ni de nada de nada.

Ahí van un par de recomendaciones de la casa (seguro que me dejáis más en los comentarios):

   - Sesiones únicas por usuario y con factores como user-agent, ip, password, etc.

   - Duración razonable de la sesión.

   - Uso del flag httpOnly.

   - Renovación de la sesión tras haber sido usada en acciones importantes. (Evitar CSRF)

No se me ocurren más, pero ya sabéis, nuevas sugerencias en comentarios!

Que disfrutéis de esta tarde de domingo, con una cervecita y leyendo mis delirios bloggeros. ¡Saludos seguratas! };))