Por qué descodificar JWS es sólo el punto de partida
En la arquitectura de identidad moderna -especialmente OAuth 2.0 y OpenID Connect- los tokens firmados se tratan a menudo como "contenedores de confianza" que pueden pasarse entre servicios. Pero para los ingenieros de seguridad, los equipos rojos y los investigadores de seguridad de IA, un JWS se entiende mejor como una entrada compacta y controlada por el atacante que se encuentra en la intersección de la criptografía y la lógica empresarial. La capacidad de realizar un descodificación de firmas web json no es el objetivo; es la instrumentación la que permite razonar sobre lo que el verificador piensa está validando, lo que la aplicación en realidad para la autorización, y qué partes del token se tratan como datos de configuración y no como datos no fiables.
Esta distinción es importante porque la "seguridad del token" no es una propiedad del formato del token. Es una propiedad del proceso de verificación y validación de reclamaciones-selección de algoritmos, selección de claves, comprobaciones de emisor/audiencia, reclamaciones basadas en el tiempo y, lo que es más importante, cómo utiliza el código posterior las reclamaciones una vez que las tiene. En el momento en que un sistema trata las declaraciones descodificadas como "verdad" antes de que la verificación se complete (o incluso se ejecute), el token deja de ser un límite de seguridad y se convierte en un parámetro controlado por el usuario.
La ingeniería detrás de la cadena: Base64url sin relleno
Cuando la gente dice "descodificar un JWS", lo que suele estar haciendo es invertir un paso de la codificación base64url. En la serialización compacta de JWS, cada uno de los tres segmentos se codifica con base64url, utilizando el alfabeto seguro para URL y omitiendo normalmente = acolchado. RFC 7515 define el formato compacto y utiliza explícitamente BASE64URL(...) para la construcción de la cabecera y la carga útil, y luego se concatena con . separadores. (Editor de RFC)
La convención "sin relleno" suena menor hasta que se construyen herramientas o se analiza el tráfico capturado a escala. Muchas rutinas genéricas base64 asumen que el relleno está presente y arrojarán errores o producirán una salida ambigua cuando falte el relleno. Un decodificador robusto debe volver a añadir el relleno de forma determinista y utilizar una rutina de decodificación consciente de base64url, de lo contrario su análisis se convierte en no reproducible, especialmente cuando usted está tratando con tokens malformados o intencionalmente corruptos durante el fuzzing.
JWS vs JWT: qué significa realmente cada punto
Una ficha JWS Compact siempre lo es:
BASE64URL(cabecera) . BASE64URL(carga útil) . BASE64URL(firma)
Ese tercer segmento no es "hex". Es el base64url de los bytes de la firma (o MAC). Trátalo como opaco a menos que estés verificando o haciendo triaje criptográfico.
JWT (RFC 7519) es una convención de conjunto de reclamaciones que se suele llevar dentro de la carga útil de JWS, razón por la que la gente confunde casualmente "JWT" con "JWS". El RFC 7519 define reclamaciones registradas como iss, sub, aud, expy nbfy describe cómo se representan estas reclamaciones como un objeto JSON. (IETF Datatracker)
En la práctica, esto significa que un paso de sólo descodificación puede decirle lo que el token reclamaciones, pero no puede decir si esas afirmaciones son verdadero. La verdad sólo llega después de que la verificación de las firmas y la validación de las reclamaciones tengan éxito.
La cabecera es la superficie de ataque: alg, chico, jku como entradas no fiables
En los sistemas bien diseñados, la cabecera del token es un metadato que ayuda al verificador a seleccionar una estrategia de verificación conocida. En los sistemas mal diseñados, la cabecera se convierte en un canal de configuración controlado por el atacante. Por eso, durante una descodificación de firmas web jsonMuchos profesionales se centran primero en la cabecera.
En alg es especialmente sensible porque puede influir en el método de verificación invocado. La confusión de algoritmo (también llamada confusión de clave) ocurre cuando un atacante puede forzar al servidor a verificar un JWT usando un algoritmo diferente al que el desarrollador pretendía, permitiendo potencialmente tokens falsificados sin conocer la clave de firma del servidor. La Academia de Seguridad Web de PortSwigger describe esta clase claramente y la relaciona con una mala configuración o un manejo defectuoso de la elección de algoritmos. (PortSwigger)
En chico no es criptografía; es recuperación de claves. Si chico influye en rutas de archivos, consultas a bases de datos, claves de caché o resolvers dinámicos sin una lista de permisos estricta, se convierte en una superficie de inyección general dentro del límite de gestión de claves.
En jku es aún más peligroso cuando se utiliza indebidamente. Si un servidor obtiene una JWKS de una URL especificada por el encabezado del token (o de una variante insuficientemente restringida), el atacante puede intentar sustituir el anclaje de confianza dirigiendo el verificador a claves controladas por el atacante. Incluso cuando un sistema "sólo obtiene claves de HTTPS", la ausencia de listas de permisos estrictas, vinculación del emisor, política de almacenamiento en caché y registros de auditoría convierte la recuperación de claves en un problema de la cadena de suministro, no en un problema criptográfico.
Descodificador offline en Python (sólo descodificación, sin relleno)
Los depuradores de tokens basados en web son cómodos, pero suelen ser una mala idea en el trabajo de seguridad profesional. Los tokens pueden contener identificadores sensibles, correos electrónicos, ID de inquilinos internos o incluso PII incrustada. Usted quiere herramientas fuera de línea, con capacidad de secuencias de comandos, que sean deterministas y seguras frente a entradas malformadas. La siguiente implementación no "verifica" nada intencionadamente; sólo decodifica lo que está presente y hace que los modos de fallo sean observables.
importar base64
importar json
from typing import Any, Dict, Tuple, Optional
def _b64url_decode(datos: str) -> bytes:
# RFC 7515 base64url comúnmente omite el relleno "="; restáuralo determinísticamente.
pad = (-len(datos)) % 4
return base64.urlsafe_b64decode((datos + "=" * pad).encode("ascii"))
def _parse_json(b: bytes) -> Tuple[Optional[Dict[str, Any]], Optional[str]]:
try:
return json.loads(b.decode("utf-8")), None
except Exception as e:
return None, f"{tipo(e).__nombre__}: {e}"
def jws_decode(token: str) -> Dict[str, Any]:
parts = token.split(".")
if len(parts) != 3:
return {"error": "Invalid JWS compact format (expected 3 parts).", "parts": len(parts)}
header_b = _b64url_decode(partes[0])
payload_b = _b64url_decode(partes[1])
cabecera, he = _parse_json(cabecera_b)
carga, pe = _parse_json(carga_b)
out: Dict[str, Any] = {
"header_raw": header_b.decode("utf-8", errors="replace"),
"payload_raw": payload_b.decode("utf-8", errors="replace"),
"signature_b64url_sample": parts[2][:16] + "..."
}
si cabecera no es None
out["header"] = header
else:
out["header_error"] = he
si payload no es None
out["payload"] = payload
else:
out["payload_error"] = pe
devolver out
Esto se alinea con el uso de base64url de RFC 7515 (y la realidad de que JWS compacto está diseñado para contextos de encabezado URL/HTTP), mientras que le da un comportamiento estable cuando el token está malformado, truncado, o intencionalmente fuzzed. (Editor de RFC)
La brecha crítica: descodificación frente a verificación (y el verdadero patrón de errores)
La falacia de seguridad más persistente en torno a JWS/JWT es confundir decodificación con verificación. La descodificación es el formateo reversible; la verificación es la validación criptográfica más la aplicación de políticas.
En incidentes reales, el patrón de fallo común es "use-before-verify" en lugar de una carrera literal. Una aplicación descodifica el token, lee papel, usuario_id, arrendatarioo alcancey toma decisiones de autorización antes de que la verificación de firmas y la validación de reclamaciones se apliquen de forma concluyente. La guía de OWASP sobre pruebas JWT destaca cómo el mal manejo de las expectativas del algoritmo y la lógica de verificación permite ataques de alto impacto, incluyendo la confusión entre flujos de verificación asimétricos y simétricos. (Fundación OWASP)
Incluso si la firma es válida, un token necesita validación de reclamación. La RFC 7519 define aud como la reclamación de audiencia, y señala que si el mandante que procesa el token no se identifica como audiencia prevista, el token debe rechazarse cuando aud está presente. (IETF Datatracker) Esto nos recuerda que la validez criptográfica no es equivalente a la validez contextual.
Explotación avanzada: más allá de "alg: none"
La narrativa "alg: none" es históricamente importante, pero la mayoría de las bibliotecas modernas la bloquean por defecto. En la actualidad, los fallos más interesantes tienden a clasificarse en dos categorías: fallos de implementación en los proveedores de cifrado y derivaciones lógicas complejas causadas por procesos de verificación flexibles.
Firmas psíquicas (CVE-2022-21449): cuando la verificación ECDSA miente
CVE-2022-21449 -popularizada como "Psychic Signatures"- es una grave vulnerabilidad criptográfica de Java por la que la verificación de firmas ECDSA podría eludirse en determinadas condiciones en las versiones de Java afectadas (en particular, introducida en Java 15 y corregida en la CPU de abril de 2022). Los análisis destacan lo dramáticamente que debilita los sistemas que dependen de las firmas ECDSA, incluidos los escenarios que implican mecanismos JWT o WebAuthn firmados por ECDSA. (Neil Madden)
La lección más importante para la seguridad de los tokens no es la astucia del bypass; es la realidad operativa de que "elegí ES256" no es una garantía. La versión del tiempo de ejecución, la implementación del proveedor de seguridad y el estado de los parches forman parte del modelo de amenazas. Los equipos de seguridad deben tratar las "regresiones del proveedor criptográfico" como riesgos de primera clase, con SLA de parches explícitos y pruebas de regresión que ejerciten la verificación contra firmas malformadas.
Confusión de algoritmos / confusión de claves: cuando el servidor deja que el token elija las reglas.
Los ataques de confusión de algoritmos se producen cuando el verificador permite que el token influya en qué algoritmo se utiliza para la verificación, y el manejo de claves no se separa limpiamente entre los modos asimétrico y simétrico. PortSwigger señala que si este caso no se maneja adecuadamente, los atacantes pueden falsificar JWTs válidos que contengan valores arbitrarios sin conocer la clave de firma secreta del servidor. (PortSwigger)
En la práctica, la defensa es conceptualmente simple pero a menudo se pasa por alto: nunca permitas "agilidad de algoritmo" en el límite donde se toman las decisiones de autenticación. Si tu servicio espera RS256, impones RS256. No "aceptas cualquier alg que esté en la cabecera y ves si valida".
Recuperación de claves basada en encabezados: chico/jku como cadena de suministro de verificación
Una vez que aceptas que la cabecera es una entrada del atacante, también aceptas que la selección de claves es parte de tu superficie de ataque. A chico debe corresponder a una lista predefinida de claves permitidas, no a material de claves arbitrario obtenido, cargado o construido en tiempo de ejecución. A jku nunca debe permitir que un token redefina de dónde provienen los anclajes de confianza. Si admite la obtención de JWKS para OIDC, debe estar vinculada a una configuración de emisor de confianza y reforzada con listas de permisos, almacenamiento en caché y supervisión.
Estrategias de endurecimiento que sobreviven a la deriva de la producción
Un enfoque de defensa en profundidad de la validación del JWS tiende a parecer aburrido sobre el papel, pero es exactamente lo que evita la mayoría de los fallos de los tokens.
Fijas explícitamente los algoritmos aceptados y requieres que el verificador haga cumplir que se usó el algoritmo esperado. La guía JWT de OWASP para Java hace este punto directamente como medida preventiva. (Serie de hojas de trucos de OWASP)
Valida emisor y audiencia de forma coherente. Las definiciones de RFC 7519 para las reclamaciones registradas no son académicas; existen porque "firma válida, contexto erróneo" es una clase común de fallos. En particular, la falta de coincidencia de público es una de las formas más fáciles de aceptar accidentalmente un token acuñado para un servicio diferente. (IETF Datatracker)
Los identificadores de clave se tratan como datos, no como una consulta de búsqueda. A chico deben resolverse a través de un mapeo acotado (alias de KMS, registro de claves estáticas o almacén de claves estrictamente controlado) y no a través de una ruta de sistema de archivos o una consulta de base de datos creada a partir de datos no fiables.
Se parchean los tiempos de ejecución criptográficos agresivamente y se prueban contra clases catastróficas conocidas. CVE-2022-21449 existe como recordatorio de que la "correcta elección del algoritmo" no puede compensar las implementaciones de verificación rotas. (Neil Madden)
Supervisa las anomalías que indiquen un sondeo activo. Grandes volúmenes de errores de relleno de base64url, tokens no válidos repetidos o una alta rotación en chico pueden indicar intentos de fuzzing o confusión en curso. La supervisión no solucionará el fallo, pero puede acortar el tiempo de detección y ayudarle a correlacionar la actividad sospechosa con puntos finales y verificadores específicos.
Automatización de la auditoría lógica de verificación: dónde puede encajar Penligent
En entornos reales, lo difícil no es descodificar un token una vez. Se trata de descubrir dónde se aceptan los tokens, identificar qué servicios aplican qué reglas de verificación y probar si la autorización posterior depende de las declaraciones descodificadas antes de tiempo. Ese bucle "descodificar → interpretar → mutar → validar impacto" es repetitivo, y es exactamente el tipo de trabajo que las modernas plataformas de seguridad asistidas por IA pueden ayudar a industrializar.
Una plataforma como Penligent puede posicionarse de forma creíble como una capa de automatización para pruebas centradas en tokens: puede realizar decodificación offline para clasificar tokens y extraer campos de alta señal (emisor, audiencia, ámbitos, roles), inferir probables pilas de verificación a partir del comportamiento de respuesta y las huellas dactilares del servicio y, a continuación, probar sistemáticamente fallos de lista de permisos de algoritmos de deriva de políticas, aplicación inconsistente de emisor/audiencia a través de microservicios y patrones de selección de claves inseguras. El valor no son los "tokens mágicos de ruptura", sino la generación repetible de pruebas y las continuas comprobaciones de regresión que detectan sutiles regresiones de verificación antes de que se produzcan.
Si considera la verificación del JWS como un límite de API crítico para la seguridad, un flujo de trabajo basado en IA es más potente cuando le ayuda a garantizar que ese límite se mantiene coherente en todas las versiones, entornos y propietarios de servicios.
Conclusión
La orden de descodificación de firmas web json es la línea de salida, no la de llegada. La descodificación proporciona capacidad de observación, pero la seguridad procede de una verificación y validación estrictas, una gestión disciplinada de las claves y una higiene resistente en tiempo de ejecución.
Desde fallos catastróficos de criptoproveedores como "Psychic Signatures" (CVE-2022-21449) hasta la confusión de algoritmos y los riesgos de la cadena de suministro de claves basadas en encabezados, la seguridad del JWS es una propiedad del sistema. Los equipos que combinan un cuidadoso análisis manual con la automatización que detecta la desviación de la verificación pueden mantener robustas sus capas de autenticación, incluso cuando los ecosistemas evolucionan y surgen nuevos modos de fallo.
Recursos fiables y lecturas complementarias
RFC 7515: Firma web JSON (JWS). (Editor de RFC)
RFC 7519: Token Web JSON (JWT). (IETF Datatracker)
PortSwigger: Ataques de confusión de algoritmos. (PortSwigger)
OWASP WSTG: Pruebas de tokens web JSON. (Fundación OWASP)
Hoja de trucos de OWASP: JSON Web Token para Java. (Serie de hojas de trucos de OWASP)
Neil Madden: Firmas Psíquicas en Java. (Neil Madden)
Análisis JFrog de CVE-2022-21449. (JFrog)
Explicación criptomática de CVE-2022-21449. (Criptomatemáticas)
Spanish 
English 
German 
French 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew