OWASP TOP 10 (III): Pérdida de autenticación y Gestión de Sesiones

Tras los dos artículos previos sobre el TOP 10 de OWASP, en esta ocasión el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como pérdida de autenticación y gestión de sesiones. Esta vulnerabilidad, desde mi punto de vista, demuestra lo poco que suele preocupar la seguridad a los usuarios. Aunque en la primera clasificación del año 2004 estaba situada como la tercera más encontrada, en la clasificación el año 2007 destacaba por haber descendido hasta el séptimo puesto. Sin embargo, tres años después, en esta nueva clasificación, se vuelve a observar un repunte en la localización de este tipo de vulnerabilidades que la vuelve a colocar en la tercera posición dejando como anécdota la anterior mejora.

Las vulnerabilidades relacionadas con la pérdida de autenticación y gestión de sesiones son críticas en la seguridad de las aplicaciones y en especial de las aplicaciones WEB, ya que permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos.

Existen multitud de situaciones en las que nos podemos encontrar ante una aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Además, debe prestarse especial atención a las procesos que permiten la recuperación de los valores del usuario de forma automática como pueden ser los servicios de pregunta secreta, de actualización de cuenta o de “Recordar contraseña”.

De nuevo, igual que ocurría en la vulnerabilidad explicada en el primer post de la serie de inyecciones, hay multitud de ejemplos que podrían demostrar el uso de esta vulnerabilidad, por lo que vamos a introducir únicamente un grupo reducido de ejemplos que permitan ilustrar la situación, y en caso de que sea necesaria alguna aclaración sobre cualquiera de los aspectos no considerados esperamos que nos lo hagan saber a través de los comentarios.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo: sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Navegando por cada uno de los artículos accede a uno que le interesa y que quiere compartir con sus amigos, por lo que accede a la url que tiene en su navegador del tipo:

A continuación cierra su navegador y postea en una red social este enlace para que todos puedan acceder a este curioso artículo. Como el servidor en el que se encuentra el artículo no cierra la sesión del usuario salvo que sea por petición de éste, cualquiera de sus “amigos” que acceda a dicho enlace aparecerá registrado en la aplicación como el usuario autenticado con el consecuente acceso a sus datos.

Del mismo modo, es posible encontrar un ejemplo de autenticación realizada a través de medios no confiables. Pensemos que esta misma aplicación utiliza un servicio de autenticación seguro a través de https. De esta forma, la comunicación viaja cifrada y no es posible interceptar el tráfico para capturar la contraseña del usuario. Como sucede en muchas páginas, el proceso de autenticación proporciona la posibilidad de “recordar” al usuario al marcar un check, de forma que se almacena en local una cookie de la página con el nombre de usuario y contraseña introducidos en el formulario de autenticación.

Aunque durante el proceso de autenticación manual el servicio utiliza una configuración segura a través de https, el proceso de autenticación automático utiliza una configuración a través de http.

En este momento, cualquier atacante de la aplicación que se encuentre controlando el tráfico que intenta acceder la aplicación de catálogo dispondrá del nombre de usuario y su contraseña por no haber utilizado un sistema de comunicación seguro.

Existen diferentes formas de proteger la aplicación desarrollada de este tipo de vulnerabilidades, pero requieren decisiones a nivel de diseño. En primer lugar, la gestión de contraseñas nunca puede almacenarse en texto plano, aspecto que aunque a ustedes les parezca obvio, es más común de lo que piensan. Esto provocaría que un atacante que tuviese acceso a la tabla o al fichero en el que se almacena la información de los usuarios tendría automáticamente acceso a cualquier recurso de la aplicación que desease, independientemente de las medidas de control que pudiésemos plantear. Además, deben utilizarse los servicios que utilicen información sensible a través de canales seguros, como puede ser una conexión sobre SSL, de forma que se evite la posibilidad de que un atacante se interponga en la comunicación de esta información entre nuestro cliente y el servidor de la aplicación de datos.

Por último, una serie de indicaciones generales sobre la forma de gestionar las sesiones:

• Añadir la comunicación cifrada en en el proceso de acceso a la aplicación.
• Eliminar, en la medida de lo posible, la utilización de mecanismos de autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta contraseña se almacena para poder ser utilizada y la sustracción de ésta valor podría ocasionar la suplantación de usuarios. Por supuesto, en este punto entramos en el equilibrio entre seguridad y funcionalidad.
• Ofrecer un enlace en todas las páginas de la aplicación para que el usuario pueda cerrar la sesión.
• Gestionar de forma adecuada la caducidad de las sesiones ante un período de inactividad.
• Gestionar de forma adecuada el tratamiento de la información cuando se introduzca un identificador de sesión caducado o no válido.

Y hasta aquí todo lo referente a las vulnerabilidades de pérdida de autenticación y gestión de Sesiones, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Como siempre, si tienen interés en que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.