Ataques a tokens y refuerzo de seguridad

En la autenticación moderna, los tokens son credenciales. Quien posea un token bearer válido será tratado como la parte autenticada hasta que el token caduque o se revoque.

• Por ello, el robo de un token equivale al robo de una credencial.
• El refuerzo de la seguridad se centra en limitar la duración de los tokens, vincularlos a su titular y habilitar una revocación rápida.

Esta lección aborda los ataques contra tokens de OAuth/OIDC/SAML y los controles defensivos para contrarrestarlos.

Un ataque clásico contra JWT explota la cabecera alg.

• Si se acepta alg: none, un atacante puede falsificar tokens sin firma.
• En la confusión de RS256 con HS256, el atacante vuelve a firmar un token utilizando la clave pública RSA como secreto HMAC.

Defensa: fije el algoritmo esperado en el servidor y no permita nunca que el token determine qué ruta de verificación se ejecuta.

El compromiso de tokens más habitual consiste simplemente en robar un token válido.

• XSS lee tokens de localStorage o de la memoria.
• Los tokens incluidos en las URL se filtran mediante el historial del navegador, las cabeceras de referencia y los registros del servidor.
• Registro detallado de las cabeceras Authorization.

Prefiera cookies httpOnly, Secure y SameSite para las sesiones del navegador, y elimine los tokens de los registros y las URL.

Un ataque de repetición reutiliza un token válido capturado para actuar como la víctima.

• Se mitiga mediante expiraciones breves, un nonce de un solo uso (OIDC) y el seguimiento del ID de la aserción (SAML).
• TLS evita la captura pasiva en la red.
• Los tokens vinculados al remitente impiden la reutilización incluso si son robados.

Cualquier persona que posea un token bearer puede utilizarlo. Los tokens vinculados al remitente asocian el token a una clave específica del cliente.

• Los tokens vinculados mediante mTLS (RFC 8705) asocian el token al certificado TLS del cliente.
• DPoP (RFC 9449) asocia el token a una clave de prueba de posesión que el cliente utiliza para firmar cada solicitud.

Así, un token robado resulta inútil sin la clave privada correspondiente.

Limite el periodo de utilidad de cualquier token robado.

• Mantenga los tokens de acceso con una duración breve (minutos).
• Utilice la rotación de tokens de renovación: cada renovación emite un token de renovación nuevo e invalida el anterior.
• Detecte la reutilización de un token de renovación ya rotado como señal de robo y revoque toda la cadena.

Los JWT autocontenidos son válidos hasta que caducan, lo que complica la revocación. Proporcione mecanismos para cortar rápidamente el acceso.

• El endpoint de revocación (RFC 7009) invalida tokens de renovación y de acceso.
• La introspección (RFC 7662) permite que un servidor de recursos compruebe el estado de un token en tiempo real.
• Mantenga una lista de denegación por jti para las revocaciones críticas.

Un token válido no autoriza automáticamente el acceso a su API. Haga cumplir su propósito.

• Compruebe aud para impedir que un token emitido para otro servicio se reutilice en el suyo.
• Haga cumplir el scope en cada endpoint; no suponga que un token válido implica acceso total.
• Valide iss para bloquear tokens de emisores que no sean de confianza.

Esto evita la reutilización de tokens entre servicios y los abusos del tipo confused deputy.

Cuando un cliente admite varios proveedores de identidad, los ataques de mix-up pueden engañarlo para que envíe a un endpoint elegido por el atacante un código o token emitido por otro IdP.

• El cliente pierde la referencia de qué AS originó la respuesta.
• Defensa: vincule las respuestas al emisor mediante el parámetro iss (RFC 9207) y valide state para cada proveedor.

El lugar y la forma en que se almacenan los tokens determinan su exposición.

• Sesiones del navegador: cookies httpOnly, Secure y SameSite; evite localStorage.
• Móviles: llavero/keystore del sistema operativo, nunca archivos de texto plano.
• Servidores: gestor de secretos, cifrado en reposo y mínimo privilegio con alcance limitado.
• Utilice siempre TLS en tránsito; no incluya nunca tokens en cadenas de consulta.

Integre los controles en una línea base operativa.

• Fije los algoritmos; rechace alg: none y los ataques de confusión.
• Valide iss, aud, exp, signature, nonce/state.
• Utilice un TTL breve para los tokens de acceso y rotación de tokens de renovación con detección de reutilización.
• Prefiera tokens vinculados al remitente (DPoP/mTLS) para las API de alto valor.
• Admita la revocación y la introspección.
• Almacene los tokens de forma segura; manténgalos fuera de las URL y los registros.

Elija el control que limite mejor el daño causado por el propio robo de tokens.

Ideas clave:

• Los tokens son credenciales; su robo equivale a la toma de control de la cuenta.
• Defienda los JWT fijando los algoritmos y validando iss, aud, exp, signature, nonce.
• Limite la exposición mediante duraciones breves y rotación de tokens de renovación con detección de reutilización.
• Los tokens vinculados al remitente (DPoP/mTLS) neutralizan los tokens bearer robados.
• Proporcione revocación e introspección, y mantenga los tokens fuera de las URL, los registros y localStorage.