> For the complete documentation index, see [llms.txt](https://chubu.gitbook.io/chubu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chubu.gitbook.io/chubu/vulnerabilidades-en-web-apps/broken-authentication.md).

# Broken Authentication

La Puerta Trasera Más Común en Aplicaciones Web

**Broken Authentication** (Autenticación Rota) ocupa consistentemente uno de los primeros lugares en el **OWASP Top 10**. No es solo "contraseñas débiles". Es un conjunto amplio de fallos que permiten a un atacante hacerse pasar por otro usuario, obtener privilegios elevados o secuestrar sesiones.

En términos de **bug bounty**, esta categoría suele generar reportes de **alta** o **crítica** (dependiendo del impacto), especialmente cuando permite acceso a cuentas de administradores o usuarios privilegiados.

#### ¿Qué es realmente Broken Authentication?

Ocurre cuando una aplicación no protege adecuadamente el proceso de verificación de identidad del usuario. Esto incluye:

* Gestión de sesiones
* Manejo de credenciales
* Recuperación de cuentas
* Implementación de autenticación multifactor (MFA)
* Tokens (JWT, sesiones, OAuth, etc.)

#### Ejemplos Prácticos (Escenarios Reales de Bug Bounty)

**1. Session Fixation**

Un clásico que aún aparece en aplicaciones legacy o mal configuradas.

**Escenario:**

* El atacante genera una sesión anónima (PHPSESSID=abc123).
* Envía el enlace con el session ID fijo a la víctima (vía email, mensaje, etc.).
* Cuando la víctima inicia sesión, el session ID sigue siendo el mismo.
* El atacante usa ese mismo session ID y ya está autenticado como la víctima.

**Detección en pentest:**

{% code expandable="true" %}

```bash
  Antes de login
GET / HTTP/1.1
Cookie: PHPSESSID=attacker123

# Después de que la víctima loguee con el mismo ID
GET /dashboard HTTP/1.1
Cookie: PHPSESSID=attacker123  ← Ahora tiene sesión de víctima
```

{% endcode %}

**2. JWT Weak Secret / Algorithm Confusion**

Extremadamente común en APIs modernas.

**Ejemplos reales:**

* **None Algorithm**: Cambiar alg: RS256 → alg: none y eliminar la firma.
* **Weak Secret**: Secretos como secret, password123, jwt-secret o el nombre de la empresa.
* **Key Confusion** (RS256 → HS256): Usar la clave pública como secreto simétrico.

**Explotación práctica (Burp Suite + jwt\_tool):**

{% code expandable="true" %}

```bash
# Con jwt_tool
python jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Opciones útiles:
-t (tamper)
-a (alg none)
-s (bruteforce secret)
```

{% endcode %}

**3. Password Reset Token Manipulation**

Muy buscado en programas de bug bounty.

**Vulnerabilidades comunes:**

* Token predecible (basado en timestamp + user ID).
* Token no invalidado después de usarse.
* Token que funciona para cualquier cuenta si se cambia el parámetro user\_id.
* Token enviado por email pero también aceptado por header o parámetro GET.

**Ejemplo de exploit:**

{% code expandable="true" %}

```http
POST /reset-password HTTP/1.1
Host: target.com

token=1234567890&user_id=1337&new_password=hacked123
```

{% endcode %}

**4. User Enumeration + Credential Stuffing / Brute Force**

* Diferentes respuestas de error ("Usuario no existe" vs "Contraseña incorrecta").
* Rate limiting ausente o débil.
* Bloqueo de cuenta por IP en lugar de por usuario.

**5. MFA Bypass / Race Conditions**

* Bypasses como:
  * mfa\_code=000000 aceptado en algunos flujos.
  * Reutilización de código MFA.
  * Race condition al cambiar email + MFA simultáneamente.
* Enviar múltiples requests al endpoint de verificación MFA.

#### Casos Realistas para Entornos Controlados (Labs / Bug Bounty)

1. **DVWA / PortSwigger Academy / HackTheBox** → Práctica segura.
2. **Aplicaciones con Juice Shop** (OWASP) → Excelente para JWT y auth rota.
3. **Programas de bug bounty privados** con scope claro (siempre autorizado).

**Metodología:**

1. Mapear todos los endpoints relacionados con auth (/login, /register, /reset, /oauth, /api/token).
2. Probar **IDOR en contexto de autenticación** (cambiar user\_id en cookies/tokens).
3. Analizar todos los tokens (JWT, session cookies, refresh tokens).
4. Probar ataques de **state manipulation**.
5. Revisar headers de seguridad: HttpOnly, Secure, SameSite=Strict/Lax, X-Frame-Options, etc.

#### Impacto Real

Un solo fallo de Broken Authentication puede llevar a:

* Account Takeover masivo
* Robo de datos personales
* Fraude financiero
* Persistencia (backdoors persistentes)

En programas de bug bounty, un **Account Takeover de administrador** fácilmente puede valer **$5,000 - $50,000+** dependiendo del programa.

#### **Ejemplo 1: JWT Algorithm Confusion + Weak Secret** 

**Escenario Realista:** Una aplicación SaaS moderna usa JWT para autenticación en su API. El desarrollador configuró el algoritmo como HS256 (simétrico) pero usó un secreto débil o predecible.

**Pasos de Explotación:**

1. **Reconocimiento:**
   * Interceptas una request autenticada con Burp Suite.
   * Encuentras el token JWT en el header Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
2. **Análisis del Token:**
   * Usas la extensión **JWT Editor** de Burp o la herramienta jwt\_tool.
   * Cambias el algoritmo de HS256 a none:

{% code expandable="true" %}

```json
{
  "alg": "none",
  "typ": "JWT"
}
```

{% endcode %}

Eliminás la firma (dejas la parte final en blanco: header.payload.)

Bruteforce del Secret (si none no funciona):

{% code expandable="true" %}

```bash
# Con jwt_tool
python jwt_tool.py <token> -s wordlist.txt -a HS256
```

{% endcode %}

Repo de jwt tool:<br>

{% embed url="<https://github.com/ticarpi/jwt_tool>" %}

1. Wordlist recomendada: rockyou.txt, jwt-secrets.txt o nombres de la empresa.
2. **Explotación Exitosa:**
   * Modificás el claim "role": "user" → "role": "admin" o "user\_id": 1001 → 1 (ID de administrador).
   * Reenvías la request y obtienes acceso como administrador.

**Impacto:** Account Takeover de cualquier usuario + acceso administrativo.

#### **Ejemplo 2: Password Reset Token Manipulation**

**Escenario Realista:** La funcionalidad de "Olvidé mi contraseña" genera un token basado parcialmente en información predecible (user\_id + timestamp) y no valida correctamente el usuario asociado.

**Pasos de Explotación:**

1. **Inicias el proceso:**
   * Usas tu propia cuenta y solicitas reset de contraseña.
   * Recibes un enlace: <https://target.com/reset?token=abc123\\&user=456>
2. **Análisis del Token:**
   * Observas que el token es relativamente corto o sigue un patrón (ej: timestamp + user\_id codificado en base64).
   * Pruebas cambiar el parámetro user= o id= por el de otra cuenta (ej: una cuenta de prueba o una que hayas identificado).
3. **Explotación:**
   * Cambias el parámetro user=456 por user=1337 (ID de administrador).
   * Usas el mismo token que te generaron a ti.
   * La aplicación acepta el token y te permite cambiar la contraseña del usuario 1337.

**Variante Avanzada (Race Condition + Token Reuse):**

* Generas el token para tu cuenta.
* Cambias tu email a <admin@target.com> rápidamente.
* Usas el token antes de que se invalide → tomas control de la cuenta admin.

**Herramientas útiles:**

* Burp Suite (Intruder para enumerar user IDs)
* Turbo Intruder o custom script en Python

**Impacto:** Account Takeover completo sin necesidad de credenciales.

**Recomendaciones:**

* **Siempre** reproduce el exploit en tu propia cuenta primero y en cuentas de prueba.
* Graba un video PoC claro (sin datos reales de víctimas).
* En el reporte incluye:
  * Impacto real (qué puede hacer el atacante)
  * Pasos detallados + screenshots
  * Recomendación de solución