SAML, sous le capot : la signature à l'intérieur de la lettre

Ce que couvre cette vidéo

• SAML : la connexion qui se signe elle-même de l'intérieur
• 2002 : quatre formats XML, un comité, toute une industrie
• La danse de connexion : application → fournisseur d'identité → retour via votre navigateur
• L'assertion : la signature réside à l'intérieur de ce qu'elle signe
• Canonicalisation : accord sur chaque octet, sinon personne ne se connecte

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.

SAML : la connexion qui se signe elle-même de l'intérieur

0:00 SAML est le XML qui vous connecte à presque toutes les applications de travail que vous possédez, et sa signature réside à l'intérieur du document qu'il signe, comme un notaire agrafant son sceau à l'intérieur de l'enveloppe qu'il scelle. Dix ans après qu'un comité l'ait écrit, des chercheurs ont testé quatorze frameworks SAML. Onze ont échoué. Et cette semaine, un article de Trail of Bits le qualifiant de fractale de mauvaise conception a atteint la première page de Hacker News. En trois minutes : comment fonctionne la danse de connexion, où se cache la signature,

0:27 et pourquoi la solution sur laquelle tout le monde est d'accord est un protocole différent. Ceci est The Daily Diff, sous le capot.

2002 : quatre formats XML, un comité, toute une industrie

0:34 Deux mille deux. Un comité de sécurité de l'Oasis fusionne quatre formats XML de fournisseurs en un seul. Les universités l'adoptent d'abord, puis Okta construit une entreprise dessus, la façon la plus rapide pour un document de comité de générer des revenus. Vous ouvrez l'application.

La danse de connexion : application → fournisseur d'identité → retour via votre navigateur

0:46 Elle n'a aucune idée de qui vous êtes, alors elle redirige votre navigateur vers le fournisseur d'identité, disons l'Okta de votre entreprise. Vous vous connectez là-bas. Okta donne à votre navigateur un document XML signé qui dit qui vous êtes, et le navigateur le renvoie.

L'assertion : la signature réside à l'intérieur de ce qu'elle signe

0:59 Ce document est l'assertion. Il nomme l'utilisateur, et la signature se trouve à l'intérieur, pointant vers l'assertion par son ID. Et le tout passe par votre navigateur, c'est-à-dire, par l'utilisateur. Pour le vérifier, l'application

Canonicalisation : accord sur chaque octet, sinon personne ne se connecte

1:11 reconstruit les octets exacts qui ont été signés. Elle retire la signature, normalise les espaces et l'ordre des attributs, et hache le résultat. C'est la canonisation, et si les deux parties ne sont pas d'accord sur un seul octet, personne ne se connecte. Un jeton web JSON le fait différemment. L'en-tête, la charge utile et la signature sont côte à côte avec des points entre eux. Rien à découper d'abord.

2012 : le vérificateur et le lecteur examinent des éléments différents

1:32 Voici la faille. Le code qui vérifie la signature et le code qui lit le nom d'utilisateur sont souvent deux éléments différents. En 2012, un article intitulé On Breaking SAML a montré que l'on pouvait déplacer l'assertion signée là où le lecteur l'ignore, et en placer une seconde là où il la cherche. Salesforce et Shibboleth faisaient partie des onze qui sont tombés dans le piège. En 2018, Duo a montré qu'un commentaire à l'intérieur d'un nom d'utilisateur pouvait faire en sorte que certaines

2018 et 2025 : deux analyseurs, deux réponses différentes

1:55 bibliothèques ne lisent que la moitié du nom, tandis que la signature était toujours vérifiée. En 2025, GitHub a trouvé deux analyseurs XML dans ruby SAML qui étaient en désaccord sur le même document. Même bug, nouvelle décennie. Trail of Bits l'appelle une fractale, car chaque niveau dans lequel vous zoomez présente la

Pourquoi cela ne cesse de casser : une fractale de mauvaise conception

2:12 même faille. Il est basé sur XML, la signature est enveloppée, et les connexions réelles utilisent peut-être un dixième de la spécification. Et la meilleure réponse sur Hacker News vient de l'acheteur. Si vous n'avez pas de support SAML, je peux trouver un produit qui en a. Les deux sont vrais, ce qui est le problème. Donc, lundi. Mettez en œuvre OpenID Connect d'abord, Fly et Tailscale vendent aux

Lundi : OIDC d'abord, une bibliothèque maintenue, des formes strictes

2:31 entreprises sans SAML du tout. Si un client l'impose, utilisez une bibliothèque maintenue, gardez-la à jour, et rejetez les messages qui ne ressemblent pas à ceux envoyés par Okta ou Google. Ne jamais écrire votre propre vérification de signature.

Verdict, sous le capot : REVERT

2:43 Verdict, sous le capot. REVERT. Presque vingt-cinq ans, une classe de bugs qui ne meurt jamais, et la solution sur laquelle tout le monde est d'accord est un protocole différent. Samedi dernier, j'ai démonté les clés d'accès, alors dites-moi ce que je dois ouvrir ensuite dans les commentaires. Et c'est la différence pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

Sources

1. Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
2. Hacker News threadnews.ycombinator.com
3. Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
4. 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
5. GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog