SAML expose des failles de conception liées à XML et aux signatures

Contexte historique

SAML, publié en 2002 par le comité OASIS Security Services Technical Committee, a été conçu pour répondre à la demande croissante d’authentification unique (SSO) lors du passage du Web 1.0 au Web 2.0. Le protocole a rapidement été adopté par des projets universitaires (CAS, Shibboleth) puis par des fournisseurs commerciaux (Ping Identity, Okta, Duo). Cette adoption massive a conduit à une standardisation autour d’un format XML, hérité d’une époque où le JSON n’était pas encore dominant.

Complexité du XML et des signatures

Le choix du XML impose la prise en charge de nombreux mécanismes de sécurité (DTD, namespaces, CDATA, schémas) et de vulnérabilités historiques telles que les attaques XXE, l’expansion d’entités (« billion laughs ») et les injections XPath/XQuery. En outre, SAML repose sur les signatures XML, implémentées via la bibliothèque libxmlsec, un code C peu audité. La validation des signatures XML est réputée difficile à implémenter correctement, ce qui crée une surface d’attaque importante.

Vulnérabilités majeures et impacts

Les recherches depuis 2005 ont identifié les attaques de type XML Signature Wrapping (XSW), où un attaquant insère un élément signé légitime puis ajoute un élément non signé contrôlé. L’article de 2012 « On Breaking SAML » a automatisé la détection de ces vecteurs, montrant que même des implémentations réputées comme simpleSAMLphp pouvaient être compromises avant que les correctifs ne soient déployés. Malgré les correctifs, les XSW persistent parce que chaque bibliothèque SAML doit d’abord gérer l’ensemble des classes de bugs XML avant de pouvoir valider les assertions d’authentification. Cette chaîne de dépendances augmente le coût de maintenance et le risque de régression.

En pratique, une faille XSW permet à un acteur malveillant de se faire passer pour n’importe quel utilisateur, contournant ainsi les contrôles d’accès des services SaaS intégrés. Le problème est aggravé par la « kitchen‑sink » design du protocole : plusieurs spécifications (S2ML, AuthXML, X‑TASS, ITML) ont été agrégées, rendant la spécification SAML difficile à lire et à implémenter de façon cohérente. Cette complexité pousse les équipes de sécurité à recommander la migration vers OpenID Connect, qui repose sur JSON et des signatures JWT plus simples à valider.