SAML, nos bastidores: a assinatura dentro da carta
O SAML faz seu login em quase todos os aplicativos de trabalho, e sua assinatura vive dentro do XML que ele assina.
O SAML faz seu login em quase todos os aplicativos de trabalho, e sua assinatura vive dentro do XML que ele assina. Nos bastidores: a dança de login entre aplicativo, navegador e provedor de identidade, como é uma asserção, por que a canonicalização precisa concordar em cada byte, e por que a mesma classe de bugs continua voltando de 2012 a 2025. Provocado por "SAML: A fractal of bad design" (312 pontos no Hacker News) da Trail of Bits.
Leia a edição escrita (Inglês) ↗
O que este vídeo aborda
- SAML: o login que se autoassina por dentro
- 2002: quatro formatos XML, um comitê, uma indústria inteira
- A dança do login: app → provedor de identidade → de volta pelo seu navegador
- A asserção: a assinatura vive dentro do que ela assina
- Canonicalização: concordar em cada byte, ou ninguém faz login
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
SAML: o login que se autoassina por dentro
0:00 SAML é o XML que faz seu login em quase todos os aplicativos de trabalho que você tem, e sua assinatura vive dentro do documento que ele assina, como um tabelião grampeando seu selo dentro do envelope que está selando. Dez anos depois que um comitê o escreveu, pesquisadores testaram catorze frameworks SAML. Onze falharam. E esta semana, uma postagem da Trail of Bits chamando-o de fractal de mau design chegou à página principal do Hacker News. Em três minutos: como funciona a dança de login, onde a assinatura se esconde,
0:27 e por que a correção que todos concordam é um protocolo diferente. Este é o The Daily Diff, nos bastidores.
2002: quatro formatos XML, um comitê, uma indústria inteira
0:34 Dois mil e dois. Um comitê de segurança da Oasis funde quatro formatos XML de fornecedores em um. As universidades o adotam primeiro, depois a Okta constrói uma empresa sobre ele, o mais rápido que um documento de comitê já se transformou em receita. Você abre o aplicativo.
A dança do login: app → provedor de identidade → de volta pelo seu navegador
0:46 Ele não tem ideia de quem você é, então ele redireciona seu navegador para o provedor de identidade, digamos, a Okta da sua empresa. Você faz login lá. A Okta entrega ao seu navegador um documento XML assinado que diz quem você é, e o navegador o envia de volta.
A asserção: a assinatura vive dentro do que ela assina
0:59 Esse documento é a asserção. Ele nomeia o usuário, e a assinatura está dentro dele, apontando de volta para a asserção por seu ID. E tudo isso passa pelo seu navegador, ou seja, pelo usuário. Para verificá-lo, o aplicativo
Canonicalização: concordar em cada byte, ou ninguém faz login
1:11 reconstrói os exatos bytes que foram assinados. Ele remove a assinatura, normaliza os espaços em branco e a ordem dos atributos, e faz o hash do resultado. Essa é a canonicalização, e se os dois lados discordarem em um único byte, ninguém faz login. Um token web JSON faz isso de forma diferente. Cabeçalho, carga útil e assinatura ficam lado a lado com pontos no meio. Nada para remover primeiro.
2012: o verificador e o leitor olham para elementos diferentes
1:32 Aqui está a falha. O código que verifica a assinatura e o código que lê o nome de usuário são frequentemente duas partes diferentes. Em dois mil e doze, um artigo chamado On Breaking Saml mostrou que você poderia mover a asserção assinada para onde o leitor a ignora, e colocar uma segunda onde ele procura. Salesforce e Shibboleth estavam entre os onze que caíram nessa. Em dois mil e dezoito, a Duo mostrou que um comentário dentro de um nome de usuário poderia fazer algumas
2018 e 2025: dois parsers, duas respostas diferentes
1:55 bibliotecas lerem apenas metade do nome, enquanto a assinatura ainda era válida. Em dois mil e vinte e cinco, o GitHub encontrou dois parsers XML dentro do Ruby SAML discordando sobre o mesmo documento. Mesmo bug, nova década. A Trail of Bits o chama de fractal, porque todo nível que você amplia tem a
Por que continua quebrando: um fractal de mau design
2:12 mesma falha. É construído em XML, a assinatura é envelopada, e logins reais usam talvez um décimo da especificação. E a principal resposta no Hacker News vem do comprador. Se você não tem suporte SAML, posso encontrar um produto que tenha. Ambos são verdadeiros, o que é o problema. Então, segunda-feira. SHIP IT OpenID Connect primeiro, Fly e Tailscale vendem para
Segunda-feira: OIDC primeiro, uma biblioteca mantida, formatos estritos
2:31 empresas sem SAML de forma alguma. Se um cliente o forçar, use uma biblioteca mantida, mantenha-a atualizada, e rejeite mensagens que não se pareçam com as que a Okta ou o Google enviam. Nunca escreva sua própria verificação de assinatura.
Veredito, nos bastidores: REVERT
2:43 Veredito, nos bastidores. REVERT. Quase vinte e cinco anos, uma classe de bugs que nunca morre, e a correção que todos concordam é um protocolo diferente. No último sábado eu desmontei as chaves de acesso, então me diga o que abrir em seguida nos comentários. E essa é a diferença de hoje. Sou Niko da Axrisi. MERGE RESPONSIBLY.
Fontes
- 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
