Para los no iniciados, un Descodificación de firmas web JSON La operación parece trivial: un simple ejercicio de descodificación Base64URL para ver las reivindicaciones dentro de un token. Pero para los ingenieros de seguridad, los probadores de penetración y los investigadores de seguridad de IA, la "decodificación" no es más que la fase de reconocimiento de un campo de batalla mucho más complejo.
Mientras que los desarrolladores utilizan la descodificación para depurar los flujos de autenticación, los atacantes la emplean para aplicar ingeniería inversa a la lógica de firma. La brecha entre descodificación una ficha y verificando su integridad es donde han vivido las vulnerabilidades de elusión de autenticación más peligrosas de la historia moderna de las API.
En este artículo se disecciona la anatomía del JWS, se analizan los fallos críticos de verificación, incluidos los CVE de alto impacto, y se explora cómo la seguridad impulsada por la IA, al igual que los motores que alimentan el Penligente-está cambiando la forma de auditar estos mecanismos criptográficos.
Anatomía de un JWS: Más que Base64
Antes de analizar los exploits, debemos alinearnos sobre la estructura definida en RFC 7515. Una Firma Web JSON (JWS) representa contenido asegurado con una firma digital o Código de Autenticación de Mensaje (MAC).
Una cadena JWS compacta consta de tres partes separadas por puntos (.):
Cabecera.Carga.útil.Firma
Lógica de descodificación
Cuando realice una descodificación de firmas web jsonestá convirtiendo los dos primeros segmentos del formato Base64URL a JSON.
Esta es una implementación en Python para investigadores de seguridad que prefieren CLI a herramientas basadas en web que podrían registrar tokens sensibles:
Python
`import sys import json import base64
def padding_fix(datos): missing_padding = len(datos) % 4 if missing_padding: datos += '=' * (4 - missing_padding) return datos
def decode_jws(token): try: header_b64, payload_b64, signature_b64 = token.split('.')
header = json.loads(base64.urlsafe_b64decode(padding_fix(header_b64)))
payload = json.loads(base64.urlsafe_b64decode(padding_fix(payload_b64)))
return header, payload
except ValueError:
print("[-] Invalid Token Format")
sys.exit(1)
Contexto de uso
header, payload = decode_jws(sys.argv[1])
print(json.dumps(header, indent=2))`
La salida de una operación de descodificación suele revelar los metadatos que dictan cómo la verificación debe suceder. Estos metadatos son el objetivo principal del atacante.
| Parámetro de cabecera | Descripción | Implicaciones para la seguridad |
|---|---|---|
alg | Algoritmo (por ejemplo, HS256, RS256) | Dicta la primitiva criptográfica. Objetivo principal de los ataques a la baja. |
typ | Tipo de token (por ejemplo, JWT) | A menudo se ignora, pero puede utilizarse para la confusión tipográfica. |
chico | Clave ID | Indica qué tecla utilizar. Puede manipularse para Recorrido de directorios o Inyección SQL en raras ocasiones. |
jku / x5u | URL de la clave web JSON | Apunta a la URL de la clave pública. Objetivo para SSRF o alojamiento de claves maliciosas. |
La brecha "descodificar-verificar": dónde residen las vulnerabilidades
El problema principal es que muchas bibliotecas e implementaciones personalizadas desacoplan la función descodificar paso del verifique paso. Una aplicación podría descodificar la cabecera para leer el alg y, a continuación, utilizar esa entrada controlada por el usuario para decidir cómo verificar la firma.
1. Eludir el algoritmo "Ninguno
Este es el "Hola Mundo" de los exploits JWS, y sin embargo persiste en los sistemas heredados. Si una implementación backend se basa en el alg del token descodificado para determinar la lógica de verificación, un atacante puede modificar el token:
- Descodifique la cabecera.
- Cambia
alganinguno(oNinguno,NONE). - Quita la firma.
Si la biblioteca admite ninguno (destinado a la depuración) y no incluye algoritmos en la lista blanca, la comprobación de la firma se omite por completo.
2. Confusión de algoritmos (confusión de claves)
Se trata de un ataque más sofisticado. Se produce cuando un servidor admite tanto la firma simétrica (HMAC) como la asimétrica (RSA/ECDSA), pero no valida cuál se está utilizando para una clave específica.
- Escenario: El servidor espera un token RS256 (firmado con una Clave Privada, verificado con una Clave Pública).
- Ataque: El atacante realiza un descodificación de firmas web json, cambios
algaHS256(HMAC), y firma el token utilizando el protocolo Clave pública como el secreto HMAC. - Resultado: Dado que la clave pública suele estar disponible para el cliente (o es fácilmente accesible), el atacante puede falsificar una firma válida que el servidor verifica utilizando su propia clave pública (tratándola como un secreto HMAC).
Estudio de caso: CVE-2022-21449 ("Psychic Paper")
Mientras que la confusión de algoritmos es un fallo lógico, algunas vulnerabilidades existen en lo más profundo de la propia implementación criptográfica.
CVE-2022-21449 (CVSS 7.5), apodado "Psychic Paper", afectaba a la implementación de Java de las firmas ECDSA. Es un excelente ejemplo de por qué validar simplemente que una "firma existe" es insuficiente.
El mecanismo
En ECDSA, la verificación implica una ecuación matemática: $v = R'$ (simplificada). La vulnerabilidad residía en el método ECDSA implementación en la que si las partes de firma $r$ y $s$ se establecieran ambas en 0la lógica de verificación devolvería incorrectamente verdadero para cualquier carga útil.
Un atacante podría:
- Descodifique un JWS legítimo.
- Modificar la carga útil (por ejemplo,
{"admin": true}). - Construye una firma donde $r=0$ y $s=0$.
- Envíelo a un backend basado en Java (que ejecute Java 15, 16, 17 o 18).
El servidor verificaría que la firma es válida, lo que permitiría eludir por completo la autenticación. Esto pone de manifiesto que ni siquiera las bibliotecas estándar, ampliamente utilizadas, son inmunes a fallos catastróficos.
Auditoría del JWS basada en IA: El enfoque penligente
El análisis manual de tokens JWS es eficaz para exploits individuales, pero las arquitecturas de microservicios modernas a menudo emplean cientos de claves, políticas de rotación y configuraciones de algoritmos diferentes. Un ingeniero humano no puede descodificación de firmas web json y probar todas las permutaciones de inyección de encabezados, confusión de claves y desvíos específicos de bibliotecas en toda una superficie de ataque.
Aquí es donde las pruebas de penetración automatizadas basadas en IA se vuelven esenciales.
Penligente aprovecha los modelos avanzados de grandes lenguajes (LLM) y el aprendizaje por refuerzo para automatizar esta profundidad de las pruebas. A diferencia de los analizadores tradicionales que utilizan expresiones regulares estáticas para buscar cadenas maliciosas conocidas, el motor de Penligent:
- Descodificación contextual: Intercepta el tráfico, descodifica los tokens JWS y entiende el contexto (por ejemplo, "Este token se utiliza para la pasarela de pago, no sólo para iniciar sesión").
- Generación adaptativa de cargas útiles: No sólo intenta
alg: ninguno. Analiza las respuestas de error del servidor para inferir la biblioteca backend. Si detecta un entorno Java, podría intentar variaciones de CVE-2022-21449. Si detectachicosondea la inyección SQL o la inyección de comandos a través de Key ID. - Análisis del flujo lógico: Penligent puede identificar si un token está correctamente verificado en un endpoint pero simplemente descodificado y de confianza sin verificación en un microservicio secundario, un fallo arquitectónico común.
Al integrar el análisis inteligente de JWS, Penligent va más allá de la simple exploración de vulnerabilidades y se adentra en el terreno de la red teaming autónomogarantizando que las implementaciones criptográficas sean sólidas tanto frente a los CVE conocidos como frente a los fallos lógicos de día cero.
Directrices de endurecimiento para ingenieros
Para asegurar las aplicaciones contra ataques JWS, debemos pasar de la "confianza implícita" a la "verificación explícita".
1. Aplicar listas blancas de algoritmos
No confíe nunca en el alg del token descodificado para determinar el método de verificación. Codifica el algoritmo esperado en tu verificador.
JavaScript
// Enfoque seguro (Node.js jose library) const verified = await jose.jwtVerify(token, secretKey, { algorithms: ['RS256'], // Explicitly whitelist ONLY RS256 });
2. Valide la chico (Clave ID) ESTRICTAMENTE
Si su configuración utiliza claves múltiples (JWKS), asegúrese de que la clave chico coincide con una clave de su lista blanca. No pase la cabecera chico directamente a una consulta a la base de datos o a una llamada al sistema de archivos.
3. Utilizar bibliotecas modernas
Evite escribir sus propias envolturas criptográficas. Utilice bibliotecas de eficacia probada como jose (Node.js), PyJWT (Python), o jjwt (Java). No obstante, asegúrese de estar suscrito a los boletines de seguridad de estas bibliotecas.
4. Separar la descodificación de la verificación (lógicamente)
Entienda que descodificación de firmas web json es para mostrar (interfaz de usuario, registro). Verifique es para autorización. Nunca utilice datos descodificados para la lógica empresarial antes de que vuelva el paso de verificación verdadero.
Conclusión
La capacidad de descodificación de firmas web json es una habilidad fundamental, pero no es más que arañar la superficie. Para el ingeniero de seguridad, el JSON en bruto es un mapa de posibles errores de configuración. Desde el clásico algoritmo "None" hasta derivaciones matemáticas como CVE-2022-21449, la integridad de la web depende de una verificación rigurosa, no sólo de una descodificación correcta.
A medida que aumenta la complejidad de las aplicaciones, el aprovechamiento de herramientas basadas en IA como Penligente para automatizar la detección de estos sutiles fallos criptográficos se está convirtiendo en una necesidad para una sólida postura de seguridad empresarial.
Referencias:
