04.-Pruebas de autenticación

4.4.- Pruebas de Autenticación¶

Las pruebas de autenticación verifican si el proceso de identificación de usuarios en una aplicación web es seguro y no permite accesos no autorizados. También evalúan si existen vulnerabilidades que permitan recuperar o acceder a las credenciales de un usuario legítimo.

Evasión del Proceso de Autenticación¶

Se busca determinar si es posible acceder a la parte privada de la aplicación sin autenticación. Aunque actualmente es menos común encontrar este tipo de fallos, algunas técnicas pueden seguir siendo efectivas.

1. Acceso directo a la parte privada¶

Consiste en intentar acceder directamente a URLs protegidas sin autenticación previa.
Aunque es raro encontrar un aplicativo completamente expuesto, en ocasiones pueden existir rutas accesibles sin control de acceso.

2. Modificación de parámetros¶

Algunas aplicaciones almacenan un parámetro en la URL o en las cookies que indica si el usuario está autenticado.
Si este parámetro es manipulable, podría permitir el acceso sin credenciales.

3. Predicción del Identificador de Sesión¶

Si los tokens de sesión no son generados aleatoriamente, un atacante podría predecirlos y suplantar la identidad de un usuario legítimo.
Se analiza si existen patrones predecibles en los identificadores de sesión.

4. Inyección SQL en el formulario de acceso¶

Se intenta inyectar código SQL en los campos de usuario y contraseña para evadir la autenticación.

Ejemplo de ataque SQL Injection en autenticación¶

La consulta SQL que realizaría de manera interna el aplicativo sería la siguiente:

SELECT * FROM login WHERE username=’usuario’ and password=’contraseña’

La siguiente inyección en el formulario de acceso generaría la siguiente consulta

SELECT * FROM login WHERE username='usuario' AND password='contraseña' OR 1=1 --

De esta manera la consulta SQL resultante devolvería resultados si el nombre de usuario es correcto y si la contraseña introducida es correcta o no siempre y cuando 1=1. Dado que la inyección introducida 1=1 siempre es una condición verdadera, no es necesario que indiquemos la contraseña del usuario, dado que el motor de la Base de Datos validará la segunda condición y nos autenticaremos suplantando la identidad del usuario que hubiéramos especificado en el parámetro “username”.

How Authentication Can Be Bypassed

Credenciales Enviadas por un Canal sin Cifrar¶

Si una aplicación transmite credenciales a través de un canal no cifrado, un atacante podría interceptarlas mediante un ataque Man in the Middle (MitM).

1. Uso del protocolo HTTP en lugar de HTTPS¶

HTTP transmite datos sin cifrar, permitiendo la captura de credenciales en tránsito.

2. Aplicativo disponible en HTTP y HTTPS (SSL Strip Attack)¶

Si el servidor acepta conexiones en HTTP y HTTPS, un atacante podría forzar al usuario a conectarse sin cifrado y robar sus credenciales.
Ataque SSL Strip: Consiste en interceptar y modificar la comunicación para degradar la conexión a HTTP.

3. Envío de credenciales en la URL con método GET¶

El método HTTP GET se caracteriza por que no dispone de cuerpo de la petición HTTP y los parámetros necesarios son transmitidos en la propia dirección URL. En el caso de que se esté enviando la información a través del protocolo cifrado HTTPS, la información transmitida se encontrará protegida ante ataques de tipo Man in The Middle. Sin embargo, al transmitirse esta información en la propia URL queda expuesta en el historial del navegador web utilizado y en los log del servidor web que sustenta el aplicativo.

Si las credenciales son enviadas en la URL, quedan registradas en:
Historial del navegador
Archivos de logs del servidor
Intermediarios en la red (proxies, firewalls, etc.)

Esta ilustración muestra la captura de una petición transmitida por HTTPS pero que expone las credenciales del usuario en la propia dirección URL.

Uso de Credenciales por Defecto¶

Algunas aplicaciones utilizan credenciales preconfiguradas que no han sido cambiadas tras la instalación.

Técnicas para detectar credenciales por defecto¶

Buscar credenciales en manuales y documentación del software utilizado.
Consultar bases de datos de credenciales públicas.
Utilizar herramientas de fuerza bruta con diccionarios de credenciales conocidas (el propio proxy de interceptación Burp Suite te permite automatizar esta tarea).

Funcionalidad de Recuperación de Contraseña Vulnerable¶

El proceso de reset de contraseña debe ser seguro para evitar que un atacante pueda suplantar la identidad de un usuario legítimo.

Pruebas de seguridad en recuperación de contraseñas¶

Verificar la información solicitada para el reset
Se debe requerir datos únicos del usuario (ej. correo, pregunta secreta).
Evitar preguntas cuyas respuestas puedan obtenerse públicamente (redes sociales, etc.).
Método de comunicación de la nueva contraseña
❌ No seguro: Mostrar la nueva contraseña directamente en pantalla.
⚠️ Moderado: Asignar una contraseña temporal y forzar el cambio en el próximo inicio de sesión.
✅ Seguro: Enviar un enlace único para que el usuario restablezca su contraseña.

Política de Contraseñas Débil¶

Se debe verificar que el aplicativo implemente políticas de contraseñas robustas:

Debe incluir:
Mayúsculas, minúsculas, números y caracteres especiales.
Longitud mínima de 8 caracteres.
No debe contener información personal (nombre, usuario, etc.).
Evitar contraseñas predecibles o de uso común.

Conclusión¶

Las pruebas de autenticación son cruciales en una auditoría de seguridad web, ya que permiten detectar fallos que podrían comprometer el acceso a la aplicación. Implementar cifrado HTTPS, autenticación robusta y controles adecuados ayuda a proteger las credenciales de los usuarios y prevenir accesos no autorizados.