Buenas Prácticas de Desarrollo Seguro: A2 Broken Authentication

Continuando con las publicaciones en relación al OWASP TOP 10, en esta oportunidad abordaremos el número 2, el cual hace referencia a problemas de validación de los mecanismos de autenticación. Los mecanismos de autenticación permiten –como su nombre lo dice– autenticar a un usuario o a un sistema, con el fin de autorizar su acceso […]

Continuando con las publicaciones en relación al OWASP TOP 10, en esta oportunidad abordaremos el número 2, el cual hace referencia a problemas de validación de los mecanismos de autenticación.

Los mecanismos de autenticación permiten –como su nombre lo dice– autenticar a un usuario o a un sistema, con el fin de autorizar su acceso a ciertas funcionalidades. Existen diversos mecanismos de autenticación, el más tradicional es el uso de usuario/contraseña. Existen mecanismos basados en identidades digitales, basados en llaves compartidas, basados en la confianza, etc. Es importante entender los diversos mecanismos de autenticación que existen y definir adecuadamente cual es el que usaremos.

Por lo general, una vez que se realiza de forma exitosa el proceso de autenticación, se genera un token el cual será utilizado posteriormente en cada una de las acciones que se realice. Este token debe cumplir una serie de requisitos con el fin de proteger la integridad y la confidencialidad de los datos. En este análisis nos referiremos a las cookies de sesión.

Una sesión es un elemento utilizado para identificar al usuario que se encuentra operando el sistema. A nivel de navegador, por el lado del cliente, estas sesiones se almacenan en las cookies y por el lado del servidor en archivos o bien en memoria.

Un manejo correcto de sesiones debe considerar la creación, manipulación y destrucción de la información relacionada a dicha sesión.

• Creación: La sesión debe ser única y debe ser generada a nivel de cliente y de servidor.
• Manipulación: No se debe permitir la manipulación de los datos de sesión desde el navegador.
• Destrucción: La destrucción de las sesiones se debe realizar tanto en el servidor como en el navegador.
• Expiración: Las sesiones deben tener fecha de caducidad.
• Datos de Sesión en las Cookies: No se deben almacenar datos sensibles en las cookies.

Por otro lado, las Listas de Control de Acceso permiten determinar a qué sección o funcionalidad del sistema es posible acceder. El momento de ingresar al sistema, se genera la sesión correspondiente y de acuerdo a su perfil, se les otorga acceso a ciertas funcionalidades del sistema. Una correcta implementación de Listas de Control de Acceso debe prevenir que el usuario autenticado pueda acceder a funcionalidades que no le fueron otorgadas.

Para esto se debe considerar:

• Roles, Perfiles y Privilegios: Se debe contar con una matriz de roles, perfiles y privilegios que permita determinar qué acciones pueden realizar los distintos tipos de roles o perfiles.
• Validación: Por cada acción que se requiera, el sistema debe validar que la sesión activa tenga los permisos y privilegios necesarios para acceder.
• Registro: Se debe registrar las acciones exitosas y los intentos indebidos, con el fin de realizar auditorías posteriores.

Los equipos de QA deben validar que los usuarios autenticados puedan realizar las acciones permitidas y tambien deben verificar que no puedan realizar aquellas que no les corresponde.

Además, se debe considerar el almacenamiento de la contraseña, ya que el tratamiento de contraseñas es un tema delicado al momento de exponer un sistema a internet, es por esto que se recomiendan los siguientes aspectos:

• Utilización de HASH robusto, mínimo SHA2.
• Utilización de SALT dinámico por cada usuario.
• No exigir una longitud máxima.
• Exigir una longitud mínima de 5 caracteres.
• No limitar el uso de caracteres especiales.
• No truncar las contraseñas.
• No almacenar las contraseñas en texto plano en archivos de logs y de auditoría.

De manera opcional, se recomienda implementar los siguientes mecanismos de apoyo al usuario:

• Indicador de Fortaleza: Indicador que permite determinar de acuerdo a los caracteres ingresados, que tan fuerte es la clave que se va a utilizar.
• Verificación en base a diccionario: Utilizar diccionarios básicos de contraseñas con el fin de advertir al usuario si es que éste está utilizando una contraseña poco segura.

Se debe considerar que el sistema y los operadores del mismo nunca deben tener acceso a la contraseña del usuario final. Cuando se requiera una recuperación de contraseña o bien un resrteo, existen dos opciones:

• El sistema debe generar un nuevo salt, una clave aleatoria que cumpla con los requisitos de contraseña segura. Posteriormente envía mediante correo electrónico dicha clave, la cual debe tener una fecha de expiración.
• Utilización de un link especialmente preparado para el reseteo de claves. El sistema genera un token aleatorio, asociado al correo electrónico del usuario final, se le envía el link y mediante ese link permite el ingreso de una nueva contraseña. Este token no debe ser predecible.

Finalmente, se debe tener en consideración que no se deben utilizar contraseñas en duro en el código fuente, ya sea a nivel de servidor o a nivel del cliente.