SAML Decoder

Qu’est-ce que SAML ?

SAML, ou Security Assertion Markup Language, est un standard d’échange d’assertions XML sur l’authentification, les attributs et l’autorisation. Il sert notamment au SSO : un fournisseur d’identité transmet à une application une assertion sur l’utilisateur, que l’application doit valider avant d’accorder l’accès.

Les flux et les deux bindings

SAML 2.0, standard OASIS publié en mars 2005, fait circuler une identité entre un fournisseur d’identité (IdP) et un fournisseur de service (SP) en passant par le navigateur de l’utilisateur. Dans le flux SP-initiated, l’utilisateur arrive sur l’application, le SP fabrique un AuthnRequest et renvoie le navigateur vers l’IdP. Après authentification, l’IdP renvoie une Response qui contient une assertion, avec InResponseTo égal à l’ID de la requête, vers l’Assertion Consumer Service (ACS) du SP. Dans le flux IdP-initiated, l’utilisateur part d’un portail de l’IdP et la réponse arrive sans requête préalable : rien ne la rattache à une session du SP, ce qui la rend plus facile à rejouer ou à injecter dans le navigateur d’une victime.

Le binding HTTP-Redirect transporte le message dans l’URL : il est compressé en DEFLATE brut (RFC 1951), encodé en base64 puis URL-encodé (SAML Bindings, §3.4.4.1). La compression existe parce que les navigateurs et les serveurs limitent la longueur des URL. La signature y est détachée : les paramètres SigAlg et Signature sont calculés sur la chaîne de requête. Ce binding sert surtout aux requêtes, plus courtes que les réponses. Le binding HTTP-POST place le message en base64, sans compression, dans un formulaire HTML soumis automatiquement : c’est le cas de presque toutes les réponses, dont la signature est intégrée au XML. L’outil détecte le binding d’après l’encodage rencontré et affiche chaque étape du décodage.

Ce que couvre la signature

Une signature XML enveloppée (ds:Signature) se place à l’intérieur de l’élément qu’elle protège et le désigne par une Reference dont l’URI vaut # suivi de son ID. SAML Core (§5.4.2) impose une seule référence, vers l’élément parent de la signature. Signer la Response protège tout son contenu, assertion comprise. Signer seulement l’assertion protège l’identité, les dates et l’audience ; le statut et les attributs de la Response elle-même restent modifiables. Les deux configurations sont valides ; le danger vient du SP qui vérifie un élément puis en lit un autre.

La canonicalisation exclusive retire les commentaires et normalise l’écriture avant le calcul du condensat. Un message peut donc changer d’aspect sans invalider la signature, et toute différence entre ce que lit le vérificateur et ce que lit l’application devient une faille. L’outil montre la cible de chaque référence, les algorithmes et les transformations ; il ne vérifie pas la signature elle-même.

Les attaques classiques

XML Signature Wrapping

L’attaquant conserve l’assertion signée, pour que la vérification réussisse, et ajoute une assertion de son choix que l’application lira à la place : en premier enfant de la Response, avec le même ID, ou en déplaçant l’originale dans Extensions. Somorovsky et al. ont trouvé cette faille dans 11 des 14 implémentations étudiées (On Breaking SAML, USENIX Security 2012). Elle revient régulièrement : en 2024, CVE-2024-45409 dans ruby-saml, puis en mars 2025 CVE-2025-25291 et CVE-2025-25292, deux différences entre les parseurs REXML et Nokogiri décrites par GitHub Security Lab.

Troncature par commentaire

Publiée par Duo Labs le 27 février 2018 (VU#475445) : l’attaquant obtient une assertion signée pour admin@sp.example.attacker.example, puis insère un commentaire dans le NameID, admin@sp.example<!---->.attacker.example. La signature reste valide puisque la canonicalisation ignore les commentaires, mais une bibliothèque qui ne lit que le premier nœud texte obtient admin@sp.example. Plusieurs bibliothèques étaient touchées, dont python-saml (CVE-2017-11427), ruby-saml (CVE-2017-11428) et OmniAuth-SAML (CVE-2017-11430).

XXE et certificat non validé

Le SP analyse le XML avant de vérifier quoi que ce soit : une DTD avec entités externes atteint donc le parseur sans authentification. Autre erreur fréquente, vérifier la signature avec le certificat contenu dans KeyInfo : l’attaquant signe alors avec sa propre clé et le message passe.

Rejeu et Golden SAML

Sans contrôle de NotOnOrAfter, de l’audience et des ID déjà consommés, une assertion interceptée se rejoue. Golden SAML, décrit par CyberArk en novembre 2017, va plus loin : avec la clé de signature de l’IdP (par exemple extraite d’un serveur AD FS), l’attaquant fabrique des assertions valides pour n’importe quel utilisateur. La technique a servi lors de la campagne SolarWinds, comme le décrit l’alerte CISA AA20-352A du 17 décembre 2020, qui cite parmi les indices des jetons à la durée de validité inhabituelle.

Tester un SP avec Burp et SAML Raider

SAML Raider, extension Burp maintenue par Compass Security, intercepte les messages SAML, les décode et propose les huit variantes XSW, la suppression de signature, l’insertion de payloads XXE et la re-signature avec un certificat de test. Cet outil sert à lire un message hors de Burp, à repérer les points à tester et à préparer une valeur modifiée.

• Connectez-vous avec un compte de test, capturez la SAMLResponse postée sur l’ACS et collez-la ici pour lire signatures, dates, audience et attributs.
• Rejouez-la sans modification après expiration, puis une seconde fois avant expiration : les deux doivent être refusées si le SP mémorise les ID.
• Retirez les signatures dans l’atelier, ré-encodez en POST et remplacez la valeur : le SP doit refuser.
• Modifiez le NameID ou un attribut de rôle sans retirer la signature, puis testez la troncature par commentaire et les variantes XSW avec SAML Raider.
• Re-signez avec votre propre certificat (SAML Raider) pour vérifier que le SP n’utilise pas la clé du message.
• Côté IdP, modifiez l’AssertionConsumerServiceURL d’un AuthnRequest pour vérifier qu’une ACS non enregistrée est refusée.

Se défendre

• Utilisez une bibliothèque SAML maintenue et à jour ; ne réimplémentez ni la vérification ni l’extraction d’assertion.
• Vérifiez la signature avec le seul certificat des métadonnées de l’IdP, exigez rsa-sha256 et un digest sha256, et refusez tout message non signé.
• Traitez exactement l’élément couvert par la signature, refusez les ID en double et les réponses à plusieurs assertions.
• Configurez le parseur XML pour refuser toute DTD et ne lisez pas le texte d’un élément nœud par nœud.
• Contrôlez Destination, Recipient, Audience, NotBefore, NotOnOrAfter et InResponseTo, et mémorisez les ID consommés jusqu’à leur expiration.
• Protégez la clé de signature de l’IdP comme un secret de domaine et surveillez les connexions fédérées sans authentification correspondante côté IdP, signe d’un Golden SAML.