SAML, nos bastidores: a assinatura dentro da carta
O SAML permite iniciar sessão em quase todas as aplicações de trabalho, e a sua assinatura reside no XML que assina.
O SAML permite iniciar sessão em quase todas as aplicações de trabalho, e a sua assinatura reside no XML que assina. Nos bastidores: o processo de início de sessão entre a aplicação, o navegador e o fornecedor de identidade, como é uma asserção, porque a canonicalização tem de concordar em cada byte, e porque a mesma classe de erros continua a surgir de 2012 a 2025. Inspirado por "SAML: A fractal of bad design" (312 pontos no Hacker News) da Trail of Bits.
Ler a edição escrita (Inglês) ↗
O que este vídeo aborda
- SAML: o início de sessão que se assina a si mesmo por dentro
- 2002: quatro formatos XML, um comité, uma indústria inteira
- O processo de início de sessão: aplicação → fornecedor de identidade → de volta pelo seu navegador
- A asserção: a assinatura reside dentro do que assina
- Canonicalização: concordar em cada byte, ou ninguém inicia sessão
Transcrição traduzida
Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.
SAML: o início de sessão que se assina a si mesmo por dentro
0:00 SAML é o XML que lhe permite iniciar sessão em quase todas as aplicações de trabalho que possui, e a sua assinatura reside dentro do documento que assina, como um notário a carimbar dentro do envelope que está a selar. Dez anos depois de um comité o ter escrito, investigadores testaram catorze frameworks SAML. Onze falharam. E esta semana, uma publicação da Trail of Bits a chamá-lo de fractal de mau design chegou à primeira página do Hacker News. Em três minutos: como funciona o processo de início de sessão, onde a assinatura se esconde,
0:27 e porque 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 na Oasis funde quatro formatos XML de fornecedores num só. As universidades adotam-no primeiro, depois a Okta constrói uma empresa sobre ele, a forma mais rápida como um documento de comité alguma vez se transformou em receita. Abre a aplicação.
O processo de início de sessão: aplicação → fornecedor de identidade → de volta pelo seu navegador
0:46 Não faz ideia de quem você é, então redireciona o seu navegador para o fornecedor de identidade, digamos, a Okta da sua empresa. Inicia sessão lá. A Okta entrega ao seu navegador um documento XML assinado que diz quem você é, e o navegador envia-o de volta.
A asserção: a assinatura reside dentro do que assina
0:59 Esse documento é a asserção. Nomeia o utilizador, e a assinatura está dentro dele, apontando de volta para a asserção pelo seu ID. E tudo isso passa pelo seu navegador, ou seja, pelo utilizador. Para verificar, a aplicação
Canonicalização: concordar em cada byte, ou ninguém inicia sessão
1:11 reconstrói os exatos bytes que foram assinados. Remove a assinatura, normaliza o espaço em branco e a ordem dos atributos, e aplica hash ao resultado. Isso é a canonicalização, e se os dois lados discordarem num único byte, ninguém inicia sessão. Um token web JSON fá-lo de forma diferente. Cabeçalho, payload e assinatura ficam lado a lado com pontos entre eles. Nada para cortar 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 utilizador são muitas vezes duas peças diferentes. Em 2012, um artigo chamado On Breaking SAML mostrou que podia 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 na armadilha. Em 2018, a Duo mostrou que um comentário dentro de um nome de utilizador podia fazer com que algumas
2018 e 2025: dois parsers, duas respostas diferentes
1:55 bibliotecas lessem apenas metade do nome, enquanto a assinatura ainda era válida. Em 2025, a GitHub encontrou dois parsers XML dentro do Ruby SAML a discordar sobre o mesmo documento. O mesmo erro, nova década. A Trail of Bits chama-lhe um fractal, porque cada nível em que se faz zoom tem a
Porque é que continua a falhar: um fractal de mau design
2:12 mesma falha. É construído em XML, a assinatura é envelopada, e os inícios de sessão reais usam talvez um décimo da especificação. E a resposta principal no Hacker News vem do comprador. Se não tiver suporte SAML, posso encontrar um produto que tenha. Ambas são verdade, o que é o problema. Então, segunda-feira. SHIP IT OpenID Connect primeiro, a Fly e a Tailscale vendem para
Segunda-feira: OIDC primeiro, uma biblioteca mantida, formas estritas
2:31 empresas sem SAML nenhum. Se um cliente o impuser, use uma biblioteca mantida, mantenha-a atualizada, e rejeite mensagens que não se pareçam com as que a Okta ou a Google enviam. Nunca escreva a 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 erros que nunca morre, e a correção em que todos concordam é um protocolo diferente. No sábado passado desmontei as passkeys, então digam-me o que abrir a seguir nos comentários. E essa é a diferença de hoje. Sou o Niko da Axrisi. Façam merge responsavelmente.
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
