Herramientas de desarrollo · JWT decodificador
El ataque alg:none y la confusión de claves: por qué los verificadores deben fijar algoritmos
· Por qué es importante
jwt seguridad criptografía
Si un verificador permite que el token elija su propio algoritmo, un atacante puede elegir ninguno o cambiar RSA por HMAC. Este post explica tanto los ataques como la regla que los previene.
El token que se verificó a sí mismo: cómo un campo de encabezado se convirtió en una superficie de ataque
Una etiqueta de algoritmo se encuentra dentro de la entrada del token controlado por el atacante. Si un verificador trata esa etiqueta como un permiso para seleccionar cualquier modo de validación disponible, el token comienza a influir en la regla utilizada para juzgarse a sí mismo. ToolAcre expone la etiqueta precisamente para que los revisores puedan verla, pero nunca actúa criptográficamente.
La dirección segura es la inversa: la configuración del servicio confiable define familias de algoritmos aceptables y claves asociadas, luego los encabezados entrantes deben coincidir con esa política. Un panel de decodificación no puede proporcionar esa política y no debe confundirse con protección simplemente porque resalta un valor sospechoso.
El repositorio marca alg:none pero no establece el historial de especificaciones detrás de los JWT no seguros.
La implementación trata `alg: none` como una declaración sin firmar y advierte que aceptarla aceptaría contenido arbitrario. También informa por separado un tercer segmento vacío. La evidencia del repositorio respalda el rechazo de dicha entrada en flujos de trabajo autenticados; no documenta por qué los JWT no garantizados se incluyeron originalmente en una especificación.
Por lo tanto, esa redacción histórica se corrige en lugar de inventarse. Lo que importa desde el punto de vista operativo está claro: un servicio que espera credenciales firmadas no debe permitir que un encabezado de token deshabilite la verificación de firmas. ToolAcre en sí no realiza ninguna verificación, por lo que su capacidad para mostrar `none` es detección solo para inspección.
El ataque alg:none: elimina la firma y pide al verificador que acepte una vacía
Un ataque sin firmar cambia el encabezado para solicitar `none`, cambia las reclamaciones si se desea y no proporciona bytes de firma. Cada segmento aún puede ser sintácticamente válido y los dos primeros se decodifican en JSON pulido. Un verificador permisivo convertiría la preferencia del atacante en una omisión de autenticación.
Un verificador estricto no tiene una rama que actualice esta entrada al estado confiable cuando se requieren tokens firmados. La advertencia de ToolAcre ayuda a identificar la forma durante la depuración, pero leer la palabra `none` no impide que un backend tome una mala decisión. La aplicación de la ley pertenece al lugar donde se consume la credencial.
Confusión de claves: presentar una clave pública como un secreto HMAC para que los tokens RS256 se verifiquen como HS256
La confusión de claves surge cuando un verificador permite familias de algoritmos con funciones clave incompatibles y no vincula cada elección al tipo de clave correcto. Una clave de verificación RSA pública no es un secreto HMAC. Tratar sus bytes como uno solo después de que un atacante cambia la etiqueta de un algoritmo colapsa la separación public/private prevista.
Prevenir esa clase de error requiere más que verificar si hay un segmento con forma de firma. El servicio debe emparejar el algoritmo esperado, el tipo de clave, el emisor y el perfil del token a través de una configuración confiable. Un decodificador que muestra RS256 o HS256 no puede saber si el backend mantiene esos enlaces.
La solución: fijar los algoritmos aceptados en el verificador y nunca derivarlos del token
Fije los algoritmos aceptados en la configuración del verificador y mantenga la lista tan estrecha como lo permita el contrato del emisor. Rechace `none` para flujos de credenciales firmadas y rechace las discrepancias en lugar de probar otro algoritmo. No derive la lista de permitidos del encabezado no verificado o de un reclamo de carga útil.
La búsqueda de claves sigue el mismo principio. Un `kid` puede seleccionar entre candidatos que ya son de confianza, pero no debe crear una nueva fuente de confianza. Las URL de encabezado o las claves incrustadas no deben seguirse simplemente porque el token las solicite. El verificador decide sus fuentes de forma independiente.
Ejemplo resuelto: leer un encabezado en el decodificador ToolAcre JWT para detectar alg:none y por qué detectarlo no es lo mismo que estar protegido
Cree un encabezado de token inofensivo que declare `none` y deje el tercer segmento vacío. ToolAcre decodifica el JSON, informa el algoritmo declarado, advierte que no está firmado y anota la firma ausente. Este es exactamente el comportamiento que se espera de una herramienta de inspección.
El ejercicio no prueba que una API rechace el token. Confirme eso por separado con una prueba negativa controlada con el verificador y la configuración reales. Si la API lo acepta, la solución pertenece a ese límite de verificación; agregar una advertencia más fuerte a un decodificador no protegería las solicitudes.
Lo que esto no cubre: las numerosas correcciones específicas de la biblioteca; consulte el RFC 8725 y el registro de cambios de su biblioteca
Las API de la biblioteca, los valores predeterminados y las correcciones históricas varían según el producto y la versión. Este módulo no establece qué nombre de opción fija los algoritmos en su pila, y este artículo no inventa ninguno intencionalmente. Lea la documentación actual y el registro de cambios de la biblioteca seleccionada y luego pruebe los casos de rechazo en su propio conjunto de pruebas.
Pruebe también tipos de claves incorrectos, valores `kid` desconocidos, firmas faltantes y perfiles de tokens inesperados. El objetivo es mostrar que la configuración gana a las sugerencias de tokens. Una decodificación exitosa no pertenece a ninguna parte de estas afirmaciones de aceptación porque el éxito de la sintaxis es compatible con todos los ejemplos maliciosos.
Conclusión: el verificador decide, no el token: un descodificador te ayuda a ver el encabezado, pero solo la verificación fija te protege
El verificador decide; la ficha no. ToolAcre puede revelar un encabezado que dice `none`, un algoritmo desconocido o un identificador de clave sorprendente. Esa visibilidad ayuda a la clasificación, pero sólo la política de algoritmos fijados y las claves confiables vinculadas correctamente impiden la aceptación.
Nunca recomiende habilitar `none`, elegir una clave de verificación de un encabezado que no sea de confianza o tratar la longitud de una firma mostrada como validación. Decodifique para inspección y luego pruebe el comportamiento de rechazo y aceptación en el límite criptográfico real con pruebas controladas.