SAML, tras bambalinas: la firma dentro de la carta
SAML le permite iniciar sesión en casi todas las aplicaciones de trabajo, y su firma vive dentro del XML que firma.
SAML le permite iniciar sesión en casi todas las aplicaciones de trabajo, y su firma vive dentro del XML que firma. Tras bambalinas: el "baile" de inicio de sesión entre la aplicación, el navegador y el proveedor de identidad, cómo se ve una afirmación, por qué la "canonicalización" tiene que coincidir en cada byte y por qué la misma clase de errores sigue regresando de 2012 a 2025. Impulsado por "SAML: A fractal of bad design" (312 puntos en Hacker News) de Trail of Bits.
Leer la edición escrita (inglés) ↗
Lo que cubre este video
- SAML: el inicio de sesión que se firma a sí mismo desde adentro
- 2002: cuatro formatos XML, un comité, toda una industria
- El "baile" de inicio de sesión: aplicación → proveedor de identidad → de vuelta a través de su navegador
- La afirmación: la firma vive dentro de lo que firma
- Canonicalización: coincida en cada byte, o nadie iniciará sesión
Transcripción traducida
Traducido de la narración original en inglés. El audio y los subtítulos disponibles son controlados por YouTube.
SAML: el inicio de sesión que se firma a sí mismo desde adentro
0:00 SAML es el XML que le permite iniciar sesión en casi todas las aplicaciones de trabajo que posee, y su firma vive dentro del documento que firma, como un notario que engrapa su sello dentro del sobre que está sellando. Diez años después de que un comité lo escribiera, los investigadores probaron catorce marcos de SAML. Once fallaron. Y esta semana una publicación de Trail of Bits, que lo llama un fractal de mal diseño, llegó a la portada de Hacker News. En tres minutos: cómo funciona el "baile" de inicio de sesión, dónde se esconde la firma,
0:27 y por qué la solución en la que todos están de acuerdo es un protocolo diferente. Este es The Daily Diff, tras bambalinas.
2002: cuatro formatos XML, un comité, toda una industria
0:34 Dos mil dos. Un comité de seguridad en Oasis fusiona cuatro formatos XML de proveedores en uno solo. Las universidades lo adoptan primero, luego Okta construye una compañía sobre él, la forma más rápida en que un documento de comité se convirtió en ingresos. Usted abre la aplicación.
El "baile" de inicio de sesión: aplicación → proveedor de identidad → de vuelta a través de su navegador
0:46 No tiene idea de quién es usted, por lo que envía su navegador al proveedor de identidad, digamos el Okta de su empresa. Usted inicia sesión allí. Okta le entrega a su navegador un documento XML firmado que dice quién es usted, y el navegador lo publica de vuelta.
La afirmación: la firma vive dentro de lo que firma
0:59 Ese documento es la afirmación. Nombra al usuario, y la firma se encuentra dentro de él, señalando la afirmación por su ID. Y todo el proceso se realiza a través de su navegador, es decir, a través del usuario. Para verificarlo, la aplicación
Canonicalización: coincida en cada byte, o nadie iniciará sesión
1:11 reconstruye los bytes exactos que se firmaron. Recorta la firma, normaliza los espacios en blanco y el orden de los atributos, y "hashea" el resultado. Eso es "canonicalización", y si las dos partes discrepan por un solo byte, nadie inicia sesión. Un "token" web JSON lo hace de manera diferente. El encabezado, la carga útil y la firma se encuentran uno al lado del otro con puntos intermedios. Nada que recortar primero.
2012: el verificador y el lector miran elementos diferentes
1:32 Aquí está la falla. El código que verifica la firma y el código que lee el nombre de usuario son a menudo dos piezas diferentes. En 2012, un documento llamado "On Breaking SAML" mostró que se podía mover la afirmación firmada a donde el lector la ignora, y poner una segunda donde la busca. Salesforce y Shibboleth estaban entre los once que cayeron en ello. En 2018, Duo demostró que un comentario dentro de un nombre de usuario podía hacer que algunas
2018 y 2025: dos analizadores sintácticos, dos respuestas diferentes
1:55 bibliotecas leyeran solo la mitad del nombre, mientras que la firma aún se verificaba. En 2025, GitHub encontró dos analizadores sintácticos XML dentro de ruby SAML discrepando sobre el mismo documento. Mismo error, nueva década. Trail of Bits lo llama un fractal, porque cada nivel al que se hace zoom tiene la
Por qué sigue fallando: un fractal de mal diseño
2:12 misma falla. Está construido sobre XML, la firma está envuelta, y los inicios de sesión reales utilizan quizás una décima parte de la especificación. Y la principal respuesta en Hacker News proviene del comprador. Si no tiene soporte para SAML, puedo encontrar un producto que sí lo tenga. Ambas son ciertas, que es el problema. Entonces, lunes. SHIP IT OpenID Connect primero, Fly y Tailscale venden a
Lunes: OIDC primero, una biblioteca mantenida, formas estrictas
2:31 empresas sin SAML en absoluto. Si un cliente lo exige, use una biblioteca mantenida, manténgala parcheada, y rechace los mensajes que no se parezcan a los que envían Okta o Google. Nunca escriba su propia verificación de firma.
Veredicto, tras bambalinas: REVERT
2:43 Veredicto, tras bambalinas. REVERT. Casi veinticinco años, una clase de errores que nunca muere, y la solución en la que todos están de acuerdo es un protocolo diferente. El sábado pasado desarmé las "passkeys", así que díganme qué debo abrir a continuación en los comentarios. Y esa es la "diferencia" de hoy. Soy Niko de Axrisi. Fusionen con responsabilidad.
Fuentes
- Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
- Hacker News threadnews.ycombinator.com
- Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
- Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
- GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog
