Vulnérabilités SAML courantes et comment y remédier

Le langage SAML (Security Assertion Markup Language) est un framework basé sur XML qui joue un rôle essentiel dans la gestion sécurisée des identités et des accès. Il sert d’intermédiaire de confiance entre les différentes entités d’un écosystème numérique, comme les fournisseurs d’identité, les fournisseurs de services et les utilisateurs. SAML a principalement pour objectif de faciliter l’authentification unique (SSO), un processus d’authentification fluide et efficace qui permet à un utilisateur d’accéder à plusieurs applications et services à l’aide d’un seul jeu d’identifiants. Bien que SAML présente de nombreux avantages par rapport à l’authentification traditionnelle par nom d’utilisateur et mot de passe, des vulnérabilités peuvent toujours survenir en fonction des éléments suivants :

1. Bibliothèque SAML utilisée par le développeur

2. Paramètres SAML utilisés par le développeur

Cet article présente brièvement les vulnérabilités SAML les plus courantes et explique comment y remédier à l’aide de quelques exemples.

Vulnérabilités SAML courantes

Validation des signatures et signature des messages 

La validation des assertions XML permet de prévenir les attaques par altération de XML. Elle confirme l’authenticité des messages XML contenus dans les assertions SAML. L’enveloppement de signature XML est une vulnérabilité qui exploite des faiblesses dans le traitement des signatures XML et peut entraîner une manipulation malveillante des données.

Dans l’exemple ci-dessous (VulnerableSAMLApp), lorsqu’un utilisateur standard s’authentifie, les informations suivantes s’affichent sur son profil.

Il est possible d’élever les privilèges de cet utilisateur en modifiant la requête SAML et en changeant son appartenance à un groupe pour le faire passer dans le groupe des administrateurs.

Pour remédier à un problème de ce type, plusieurs mesures sont nécessaires :

1. Les assertions doivent être signées. Une signature sera ainsi ajoutée à votre attribut d’assertion et signée à l’aide du certificat de confiance.

2. Les valeurs des assertions doivent être validées afin de vérifier que les signatures correspondent aux données du message dans son ensemble, y compris à l’assertion.

La plupart des bibliothèques SAML modernes proposent des paramètres que vous pouvez activer pour signer et valider les messages. En voici un exemple dans samlify : https://github.com/tngan/samlify/blob/master/docs/sp-configuration.md 

Chiffrement faible

Dans le cadre de l’authentification SAML, il est essentiel de chiffrer certaines parties du message SAML afin de garantir la sécurité et la confidentialité des données sensibles. Les assertions SAML, qui contiennent des informations sur l’utilisateur et ses attributs, doivent notamment être chiffrées. Elles sont échangées entre le fournisseur d’identité (IdP) et le fournisseur de services (SP) afin de vérifier l’identité et les autorisations de l’utilisateur.

1const idp = IdentityProvider({
2  isAssertionEncrypted: true,
3  metadata: fs.readFileSync('./metadata_idp.xml'),
4  dataEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#aes256-cbc',
5  keyEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#rsa-1_5' 
6});
7An example on setting the encryption on an IdentityProvider when using Samilify: https://github.com/tngan/samlify/blob/master/docs/encrypted-saml-response.md

Expiration des messages

Par défaut, les messages SAML peuvent être vulnérables aux attaques par rejeu. Une attaque par rejeu consiste à réutiliser sans autorisation un message SAML valide intercepté, dans le but d’usurper une action SAML légitime, comme une authentification unique (SSO) ou une déconnexion unique (SLO). Les attributs « NotBefore » et « NotOnOrAfter » permettent de prévenir ces attaques.

• NotBefore (attribut) : cet attribut définit le moment le plus tôt auquel l’assertion SAML peut être considérée comme valide. En d’autres termes, l’assertion ne doit pas être utilisée pour l’authentification ou l’autorisation avant l’heure « NotBefore » spécifiée. Il garantit que l’assertion n’est pas utilisée prématurément, ce qui est particulièrement important pour les opérations sensibles au facteur temps. Avant l’heure « NotBefore », l’assertion est généralement considérée comme invalide.

• NotOnOrAfter (attribut) : cet attribut indique la dernière date et heure auxquelles l’assertion SAML reste valide. Une fois cette échéance passée, l’assertion ne doit plus être utilisée pour l’authentification ou l’autorisation. Cette limite temporelle permet d’empêcher l’utilisation abusive d’assertions obsolètes qui auraient pu être interceptées ou obtenues de manière malveillante.

Redirection ouverte

SAML est par nature un protocole asynchrone. Lorsqu’un processus de connexion initié par le SP commence, celui-ci crée une requête d’authentification SAML, qui est ensuite envoyée au fournisseur d’identité (IdP). À ce stade, le fournisseur de services ne conserve aucune information sur la requête. Par conséquent, lorsqu’il reçoit la réponse SAML de l’IdP, il ne connaît pas le lien profond d’origine qui a déclenché la requête d’authentification. Pour résoudre ce problème, SAML intègre un paramètre essentiel appelé « RelayState ».

RelayState est un paramètre HTTP qui peut être intégré à la requête SAML comme à la réponse SAML. Lors d’un processus de connexion initié par le SP, celui-ci peut utiliser le paramètre RelayState pour intégrer des informations supplémentaires à la requête SAML. Ce mécanisme permet de préserver le contexte et les données essentiels au cours du processus asynchrone. Cependant, un attaquant peut détourner ce paramètre RelayState pour mener des attaques par redirection ouverte.

Pour éviter les attaques par redirection ouverte, vérifiez que la valeur de RelayState correspond à une URL de confiance avant de procéder à la redirection. Voici un exemple fourni par les responsables de la bibliothèque python3-saml.

Conclusion

Nous avons présenté plusieurs exemples de vulnérabilités SAML courantes et de mesures correctives. Notez toutefois que ces mesures peuvent varier, voire être impossibles à appliquer dans certains cas, en fonction de la bibliothèque SAML et du fournisseur d’identité que vous utilisez. Consultez donc la documentation de ces bibliothèques et des fournisseurs tiers pour savoir comment prévenir efficacement ces vulnérabilités. 

Enfin, si SAML offre un framework pour gérer les identités et les accès de manière sécurisée, OpenID Connect (OIDC) peut constituer une alternative intéressante qui n’utilise pas XML. OIDC est une couche d’identité moderne reposant sur OAuth 2.0 et JWT. Au lieu d’utiliser des assertions XML, OIDC s’appuie sur des JSON Web Tokens (JWT) pour transmettre les informations d’identité, ce qui le rend mieux adapté aux applications web et mobiles modernes. OIDC simplifie le processus d’intégration et offre des fonctionnalités telles que la récupération des informations de profil utilisateur. C’est donc une option intéressante pour les développeurs qui préfèrent éviter les subtilités de la sécurité XML. Bon nombre des attaques évoquées dans cet article ne s’appliquent pas à OIDC. OIDC peut donc être une alternative à envisager, dont l’adoption pourrait réduire certaines des complexités associées à SAML.