Assertion fédérée injectée : pourquoi une assertion valide ne suffit pas

Une assertion bien signée, émise par le bon fournisseur d’identité, non expirée, décrivant un utilisateur réel. Et pourtant l’accès accordé est celui de l’attaquant. L’attaque ne porte pas sur l’assertion mais sur la session à laquelle le service la rattache : si l’attaquant parvient à faire traiter par le service une assertion qu’il a obtenue ou fabriquée ailleurs, il obtient une session authentifiée sans rien avoir cassé. Le NIST a nommé et traité cette classe d’attaques dans la quatrième révision de son volume sur la fédération, publiée en juillet 2025, et il en a fait le critère principal de ses niveaux d’assurance de fédération.

→ Lire l’explication complète de la marmotte

Ce qu’est une injection d’assertion

La définition du NIST mérite d’être citée intégralement, parce qu’elle contient déjà tout le mécanisme. « Une attaque par injection d’assertion, dans le contexte d’un protocole fédéré, consiste en un attaquant tentant de forcer un service consommateur à accepter ou à traiter une assertion, ou une référence d’assertion, afin d’obtenir l’accès à ce service ou de refuser l’accès à un abonné légitime. L’attaquant procède en prenant une assertion ou une référence d’assertion et en l’injectant dans un service vulnérable. Un attaquant qui réussit peut tromper le service pour qu’il lie la session de l’attaquant à l’identifiant fédéré contenu dans l’assertion. L’assertion de l’attaquant peut avoir été soit volée à un abonné légitime, soit fabriquée pour perpétrer l’attaque. »

Trois choses à relever. D’abord, la cible n’est pas l’assertion mais la liaison entre l’assertion et une session : le défaut est dans le service consommateur, pas dans la cryptographie. Ensuite, le déni de service en est une variante explicitement prévue, cas souvent oublié : injecter l’assertion d’un tiers dans la session de la victime lui donne accès au compte de ce tiers, ce qui est au moins une confusion et parfois une fuite. Enfin, le NIST précise que l’assertion peut être volée ou fabriquée, ce qui inclut les cas où une signature valable est obtenue par les moyens décrits dans l’enveloppement de signature XML.

Le document ajoute une remarque qui désigne la combinaison la plus efficace en pratique : « les attaques par injection d’assertion sont particulièrement dangereuses combinées à des attaques d’hameçonnage, parce que l’attaquant peut soit tromper l’abonné pour qu’il génère une assertion valable que l’attaquant injectera dans sa propre session, soit tromper l’abonné pour qu’il injecte l’assertion de l’attaquant dans la session de l’abonné au service consommateur ». Les deux sens de l’attaque existent, et ils demandent la même qualité de manipulation que celle décrite dans contrer le spear phishing.

Les six parades que le NIST énumère

La protection « est recommandée à tous les niveaux et exigée au niveau 2 et au-dessus ». Le document note que les deux grandes familles de protocoles, OpenID Connect et SAML, « fournissent des mécanismes de protection contre l’injection d’assertion », et que « différents mécanismes offrent différents degrés de protection et s’appliquent dans des circonstances différentes ». Puis il énumère six bonnes pratiques, qu’il vaut la peine de prendre une par une.

La présentation par canal arrière, qui « empêche un service consommateur d’accepter des assertions en dehors d’une réponse directe du fournisseur d’identité ». C’est la parade la plus radicale : l’assertion ne transite pas par le navigateur, qui ne transporte qu’une référence que le service échange lui-même, de serveur à serveur, contre l’assertion. Tout ce que l’attaquant peut injecter dans le navigateur devient inexploitable, puisque le service n’accepte pas d’assertion par ce chemin. C’est exactement le raisonnement qui a fait préférer le flux par code d’autorisation au flux implicite, et le même qui motive la requête d’autorisation poussée.

Une valeur imprévisible liant la session non authentifiée du service à sa requête, ce qui « empêche un attaquant d’injecter une référence d’assertion d’une session dans une autre ». C’est le rôle du paramètre d’état, et il faut mesurer que sa fonction n’est pas anti-rejeu mais anti-confusion de session : sans lui, le service ne sait pas que la réponse qu’il traite répond à sa demande.

L’authentification du service consommateur auprès du fournisseur d’identité lors de la demande d’assertion, « pour empêcher l’attaquant de feindre une requête du service consommateur ».

L’interdiction des processus initiés par le fournisseur d’identité, « pour empêcher le service consommateur d’accepter des assertions et des références d’assertion non sollicitées ». Le NIST apporte ici une nuance qui évite une lecture trop stricte : cette interdiction « n’inclut pas les processus dans lesquels une partie externe, par exemple le fournisseur d’identité ou une autorité de fédération, signale au service consommateur de démarrer un processus de fédération avec le fournisseur, ce qui permet au service de commencer la transaction et d’attendre une réponse en sécurité dans le cadre de cette transaction ». La différence entre « voici une assertion » et « commence une transaction » est toute la sécurité du dispositif.

Une réponse signée par canal avant, avec un aléa fourni par le service et couvert par la signature, mesure qui produit le même effet que la précédente quand le canal arrière n’est pas disponible. Le mot important est « couvert par la signature » : un aléa transporté à côté de la signature ne prouve rien.

L’usage d’interfaces de plateforme pour la communication par canal avant, plutôt que des redirections HTTP. C’est la recommandation la plus récente et la moins appliquée : une redirection de navigateur est un canal que l’attaquant peut déclencher, tandis qu’une interface de plateforme lie la réponse au contexte applicatif qui l’a demandée.

Ces six mesures ne s’excluent pas, et le document insiste sur le fait que le service consommateur « doit prendre des mesures raisonnables » au regard de la nature de son logiciel, des capacités du protocole utilisé et des besoins du système d’ensemble. Il n’y a pas de case à cocher, et c’est l’honnêteté de ce texte.

Les trois niveaux d’assurance de fédération

Le NIST organise ces exigences en trois niveaux, qu’il note FAL1, FAL2 et FAL3, et qui se cumulent : « chaque niveau successif subsume et satisfait toutes les exigences des niveaux inférieurs ». Six dimensions les distinguent : restriction d’audience, protection contre le rejeu, protection contre l’injection, établissement de l’accord de confiance, établissement des identifiants et des clés, et mode de présentation.

FAL1 est le socle. Le fournisseur d’identité « DOIT signer l’assertion avec de la cryptographie approuvée » et le service consommateur « DOIT valider la signature avec la clé de vérification associée au fournisseur attendu ». L’assertion « DOIT être restreinte en audience à un service ou à un ensemble de services », chacun devant vérifier qu’il en fait partie, et chacun devant appliquer une protection anti-rejeu : « une assertion avec plusieurs audiences pourrait être acceptée par plusieurs services, mais seulement une fois par chacun ». La protection contre l’injection n’est à ce niveau que recommandée, et la transaction « DEVRAIT » être initiée par le service consommateur. Dernière exigence, souvent négligée et pourtant simple : « les identifiants fédérés NE DEVRAIENT PAS contenir d’informations personnelles en clair, telles que des noms d’utilisateur, des adresses électroniques, des numéros d’employé ».

FAL2 durcit trois points. L’assertion « DOIT être fortement protégée contre les attaques par injection » et la transaction « DOIT être initiée par le service consommateur ». La restriction d’audience passe à un service unique par assertion, ce qui supprime la possibilité qu’une même assertion serve ailleurs. L’accord de confiance « DOIT être établi préalablement à la transaction », donc plus d’accord négocié à la volée par l’utilisateur. Et l’interdiction sur les identifiants devient impérative : ils « NE DOIVENT PAS contenir d’informations personnelles en clair ». Le document ajoute une exigence propre aux agences fédérales américaines, intéressante comme repère : les fournisseurs d’identité opérés pour leur compte qui présentent des assertions à ce niveau ou au-dessus « DOIVENT protéger les clés de signature avec des mécanismes validés au niveau 1 ou supérieur » du référentiel FIPS 140, dont la portée est discutée dans les certifications FIPS et Critères communs.

FAL3 change de nature. Il « établit une très haute confiance dans le fait que l’information communiquée correspond à ce qui a été établi » par l’autorité d’identité, et surtout il « protège contre la possibilité d’un fournisseur d’identité compromis en exigeant une authentification additionnelle de l’abonné auprès du service consommateur ». C’est le seul niveau qui ne fait pas confiance au fournisseur d’identité. Il impose également que les identifiants des trois parties « soient établis manuellement », chaque identifiant étant « uniquement associé aux clés de vérification de la partie représentée », transmises par un mécanisme de confiance. Autrement dit, l’enregistrement dynamique décrit dans la découverte et l’enregistrement dynamique de client est admis aux deux premiers niveaux et exclu au troisième.

FAL3 : la liaison à l’authentificateur présent

La différence opérationnelle de FAL3 tient en une phrase : « le service consommateur DOIT vérifier que l’abonné contrôle un authentificateur en plus de l’assertion ». Deux formes sont prévues, et elles n’ont pas les mêmes contraintes.

L’assertion à détenteur de clé porte l’identification d’une clé dont l’abonné doit prouver la possession auprès du service consommateur. Le document pose la précaution évidente mais nécessaire : une telle assertion « NE DOIT PAS inclure de clé privée non chiffrée ni de clé symétrique ». La parenté avec les mécanismes de preuve de possession côté OAuth est directe : c’est le même raisonnement que celui de DPoP et de la liaison au certificat client, appliqué à l’abonné au lieu du client.

L’authentificateur lié est un authentificateur que le service consommateur connaît pour cet abonné, indépendamment du fournisseur d’identité, et qu’il lui demande de présenter en plus de l’assertion. Le document décrit deux voies pour l’établir : une délivrance par le service consommateur, ou une cérémonie de liaison d’un authentificateur fourni par l’abonné. En pratique, c’est une clé de sécurité enregistrée auprès du service, selon la mécanique décrite dans le déploiement de WebAuthn FIDO2.

L’intérêt de cette exigence dépasse la défense contre l’injection. Elle répond à une question que la fédération élude d’ordinaire : que se passe-t-il si le fournisseur d’identité lui-même est compromis ? À FAL1 et FAL2, la réponse est que l’attaquant obtient tout, puisque le service consommateur n’a aucun moyen de distinguer une assertion authentique d’une assertion émise par un fournisseur sous contrôle adverse. À FAL3, il lui manque encore l’authentificateur de l’abonné. C’est la seule construction de la fédération qui ne suppose pas le fournisseur d’identité honnête, et c’est pourquoi elle est réservée aux fonctions à fort impact.

L’assertion chiffrée, et ce qu’elle ne règle pas

Le chiffrement de l’assertion est traité séparément, et il faut comprendre qu’il répond à un autre problème que l’injection : celui de l’exposition du contenu aux intermédiaires, navigateur compris. Le fournisseur d’identité « DOIT chiffrer le contenu de l’assertion avec la clé de chiffrement du service consommateur », une assertion SAML pouvant l’être par le chiffrement XML et un jeton d’identité OpenID Connect par JWE. Le document note qu’« alors que la plupart des formats d’assertion prennent en charge le chiffrement de l’assertion entière, certains » permettent de ne chiffrer qu’une partie, « fournissant la divulgation sélective d’informations sensibles au service consommateur sans chiffrer l’assertion entière », ce qui rejoint le mécanisme exposé dans la divulgation sélective.

Une exigence mérite d’être isolée, parce qu’elle est fréquemment violée par des déploiements par ailleurs soignés : lorsque la présentation se fait par canal avant, c’est-à-dire à travers le navigateur, le fournisseur « DOIT chiffrer toutes les informations personnelles » contenues dans l’assertion. Faire transiter un jeton d’identité en clair par une redirection, c’est le confier à l’historique du navigateur, aux journaux des intermédiaires et à l’en-tête de référent, pour exactement les raisons détaillées dans la clé de cache HTTP.

Le chiffrement ne protège en revanche pas contre l’injection : une assertion chiffrée à destination d’un service consommateur reste, pour ce service, parfaitement déchiffrable et exploitable, quelle que soit la session dans laquelle on la lui glisse. C’est la confusion la plus courante sur le sujet, et elle vient de ce que le chiffrement « pour un destinataire unique » ressemble à une restriction d’audience. Ce sont deux contrôles distincts : le chiffrement décide qui peut lire, la restriction d’audience et la protection contre l’injection décident ce qui peut être accepté. Les deux sont nécessaires, et ni l’un ni l’autre ne dispense de vérifier la signature, l’émetteur, la fenêtre temporelle et l’unicité de l’identifiant d’assertion, contrôles dont la mise en œuvre concrète est détaillée dans la configuration d’OIDC entre un fournisseur et une application interne.

Sources

NIST SP 800-63C-4 : Digital Identity Guidelines, Federation and Assertions, NIST, juillet 2025.

🐝 Ce qui arrive si on s’en passe

Sans valeur imprévisible liant la requête à la session du service consommateur, une assertion obtenue par l’attaquant se glisse dans la session d’une victime, ou l’inverse, et le service lie la mauvaise identité à la mauvaise session sans qu’aucune signature ne soit en défaut. Sans interdiction des processus initiés par le fournisseur d’identité, le service accepte des assertions non sollicitées, ce qui dispense l’attaquant de toute synchronisation. Sans présentation par canal arrière ni aléa couvert par la signature, le navigateur reste un canal d’injection ouvert. Sans restriction d’audience à un service unique, une assertion acceptée quelque part est présentable ailleurs. Sans authentificateur additionnel exigé du côté du service, un fournisseur d’identité compromis délivre des assertions authentiques pour n’importe qui, et rien ne le distingue d’un fournisseur sain. Et sans chiffrement des informations personnelles présentées par canal avant, le contenu de l’assertion finit dans l’historique du navigateur et dans les journaux des intermédiaires.

🦫 Explication de la marmotte 🍫

Dans la connexion fédérée, une application délègue l’authentification à un fournisseur d’identité, qui lui renvoie un document signé affirmant « cette personne est untel ». L’application vérifie la signature et ouvre une session.

L’attaque consiste à faire traiter par l’application un document authentique, mais qui ne concerne pas la personne qui est en train de se connecter. L’attaquant peut par exemple obtenir un document signé pour son propre compte, puis s’arranger pour que l’application le reçoive dans la session d’une victime, ou l’inverse : récupérer un document concernant la victime et le présenter dans sa propre session. Dans les deux cas, la signature est bonne et l’application se trompe de personne.

Le remède n’est pas cryptographique, il est procédural. L’application doit garder la trace de la demande qu’elle a émise, au moyen d’une valeur imprévisible qu’elle inclut dans sa requête et qu’elle retrouve dans la réponse. Elle doit refuser tout document qui arrive sans qu’elle l’ait demandé. Et le meilleur dispositif consiste à ne pas faire passer le document par le navigateur du tout : le navigateur ne transporte qu’un numéro, que l’application échange directement avec le fournisseur d’identité, de serveur à serveur.

Les recommandations américaines classent tout cela en trois niveaux. Le premier exige une signature, une audience déclarée et une protection contre la réutilisation. Le deuxième exige en plus une véritable protection contre l’injection, une audience limitée à une seule application, et un accord établi à l’avance. Le troisième est le seul qui ne fasse pas confiance au fournisseur d’identité : il exige que la personne présente aussi, directement à l’application, un moyen d’authentification que celle-ci connaît, par exemple une clé de sécurité. Même si le fournisseur était entièrement compromis, l’attaquant n’aurait pas cette clé.

Dernier point souvent mal compris : chiffrer le document ne protège pas contre cette attaque. Le chiffrement décide qui peut le lire, pas s’il doit être accepté. Les deux contrôles sont nécessaires et ne se remplacent pas.

Pages voisines

La citent

Assertion fédérée injectée : pourquoi une assertion valide ne suffit pas

Elle cite

: les deux pages se citent l’une l’autre.

Assertion fédérée injectée : pourquoi une assertion valide ne suffit pas

Assertion fédérée injectée : pourquoi une assertion valide ne suffit pas

Ce qu’est une injection d’assertion

Les six parades que le NIST énumère

Les trois niveaux d’assurance de fédération

FAL3 : la liaison à l’authentificateur présent

L’assertion chiffrée, et ce qu’elle ne règle pas

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines