SAML, en detalle: la firma dentro de la carta
SAML te inicia sesión en casi todas las aplicaciones de trabajo, y su firma reside dentro del XML que firma.
SAML te inicia sesión en casi todas las aplicaciones de trabajo, y su firma reside dentro del XML que firma. En detalle: el proceso de inicio de sesión entre la aplicación, el navegador y el proveedor de identidad, cómo se ve una aserción, por qué la "canonicalización" debe coincidir en cada byte, y por qué la misma clase de error 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) ↗
Qué cubre este vídeo
- SAML: el inicio de sesión que se firma a sí mismo desde dentro
- 2002: cuatro formatos XML, un comité, toda una industria
- El proceso de inicio de sesión: app → proveedor de identidad → de vuelta a través de tu navegador
- La aserción: la firma reside dentro de lo que firma
- Canonicalización: ponte de acuerdo en cada byte, o nadie inicia sesión
Transcripción traducida
Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.
SAML: el inicio de sesión que se firma a sí mismo desde dentro
0:00 SAML es el XML que te inicia sesión en casi todas las aplicaciones de trabajo que tienes, y su firma reside dentro del documento que firma, como un notario grapando su sello dentro del sobre que está sellando. Diez años después de que un comité lo escribiera, investigadores probaron catorce frameworks Saml. Once cayeron. Y esta semana una publicación de Trail of Bits llamándolo un fractal de mal diseño llegó a la portada de Hacker News. En tres minutos: cómo funciona el proceso 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. Esto es The Daily Diff, en detalle.
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. Las universidades lo adoptan primero, luego Okta construye una empresa sobre él, la forma más rápida en que un documento de comité se ha convertido en ingresos. Abres la aplicación.
El proceso de inicio de sesión: app → proveedor de identidad → de vuelta a través de tu navegador
0:46 No tiene idea de quién eres, así que rebota tu navegador al proveedor de identidad, digamos el Okta de tu empresa. Inicias sesión allí. Okta le entrega a tu navegador un documento XML firmado que dice quién eres, y el navegador lo publica de vuelta.
La aserción: la firma reside dentro de lo que firma
0:59 Ese documento es la aserción. Nombra al usuario, y la firma se encuentra dentro de él, apuntando de vuelta a la aserción por su ID. Y todo el proceso viaja a través de tu navegador, es decir, a través del usuario. Para verificarlo, la aplicación
Canonicalización: ponte de acuerdo en cada byte, o nadie inicia sesión
1:11 reconstruye los bytes exactos que fueron firmados. Corta la firma de nuevo, normaliza los espacios en blanco y el orden de los atributos, y aplica un hash al resultado. Eso es la "canonicalización", y si las dos partes no están de acuerdo 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 en medio. Nada que cortar 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 dos mil doce, un artículo llamado "On Breaking Saml" mostró que podías mover la aserción firmada donde el lector la ignora, y poner una segunda donde la busca. Salesforce y Shibboleth estaban entre los once que cayeron en la trampa. En dos mil dieciocho, Duo demostró que un comentario dentro de un nombre de usuario podía hacer que algunas
2018 y 2025: dos analizadores, dos respuestas diferentes
1:55 librerías leyeran solo la mitad del nombre, mientras que la firma seguía siendo válida. En dos mil veinticinco, GitHub encontró dos analizadores XML dentro de ruby Saml en desacuerdo sobre el mismo documento. Mismo error, nueva década. Trail of Bits lo llama un fractal, porque cada nivel al que haces 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 usan quizás una décima parte de la especificación. Y la respuesta principal en Hacker News proviene del comprador. Si no tienes soporte para Saml, puedo encontrar un producto que sí lo tenga. Ambas son ciertas, lo cual es el problema. Así que, lunes. SHIP IT OpenID Connect primero, Fly y Tailscale venden a
Lunes: OIDC primero, una librería mantenida, formas estrictas
2:31 empresas sin Saml en absoluto. Si un cliente lo fuerza, usa una librería mantenida, mantenla parcheada, y rechaza los mensajes que no se parecen a lo que envían Okta o Google. Nunca escribas tu propio verificador de firmas.
Veredicto, en detalle: REVERT
2:43 Veredicto, en detalle. REVERT. Casi veinticinco años, una clase de error que nunca muere, y la solución en la que todos están de acuerdo es un protocolo diferente. El sábado pasado desmonté las passkeys, así que dime qué abrir a continuación en los comentarios. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusiona 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
