Vulnérabilité XSS critique dans Shibboleth Identity Provider
Qu’est-ce qui a été découvert ?
Le CERT-FR vient de publier un avis de sécurité alertant sur une vulnérabilité au sein de Shibboleth Identity Provider, le logiciel d’authentification fédérée très utilisé dans l’enseignement supérieur et la recherche. Cette faille permet à un attaquant de provoquer une injection de code indirecte de type XSS (Cross-Site Scripting) à distance, sans authentification préalable.
Pourquoi est-ce important ?
Shibboleth centralise les identités : il vérifie qui vous êtes et délivre des assertions SAML aux applications partenaires. Si un attaquant parvient à exécuter du JavaScript malveillant dans le contexte du serveur d’identité, il peut :
- Détourner des sessions administrateur,
- Intercepter ou modifier les assertions SAML,
- Obtenir un accès illicite à des services « confiance » (mails, bibliothèques, notes, etc.).
Autrement dit, la compromission du Identity Provider revient à ouvrir la porte principale d’un écosystème complet.
Comment fonctionne l’attaque ?
Le XSS est qualifié d’indirect car le script injecté n’est pas renvoyé immédiatement à la victime : il transite d’abord par une données stockée ou répliquée (log, métadonnée SAML, assertion anonymisée, etc.). Dès qu’un utilisateur ou un administrateur consulte la ressource contaminée, le payload s’exécute. Ce mode « secondaire » le rend plus difficile à détecter, mais tout aussi dangereux.
Quels systèmes sont concernés ?
Toute installation de Shibboleth Identity Provider antérieure à la version corrigée (watch security advisory officiel) est concernée. Les « Service Providers » (SP) ne sont pas directement vulnérables, mais ils héritent du risque si l’IdP qu’ils sollicitent est compromis.
Que faire immédiatement ?
- Inventorisez : listez vos serveurs Shibboleth, leurs versions et leurs rôles (test, prod, fédération).
- Patch : appliquez la dernière mise à jour fournie par le Shibboleth Consortium dès qu’elle est disponible.
- Compartimentez : restreignez l’accès administrateur par réseau, activez l’A2F, séparez les logs et les sessions.
- Surveillez : vérifiez les journaux d’accès à la recherche de payloads suspects (
<script>,javascript:,onerror=, etc.). - Communiquez : alertez vos fournisseurs de service et les utilisateurs clés afin qu’ils repèrent d’éventuelles anomalies de connexion.
Bonnes pratiques à moyen terme
- Adoptez une politique de divulgation coordonnée : intégrez les canaux d’alerte du CERT-FR et du consortium Shibboleth.
- Déployez des WAF (Web Application Firewall) en amont de l’IdP pour filtrer les tentatives XSS avant qu’elles n’atteignent l’application.
- Chiffrez et signez systématiquement les assertions SAML pour limiter l’impact d’une altération.
- Testez régulièrement votre chaîne de confiance via des campagnes de pen-testing ciblées sur le flux SAML complet.
Sommes-nous prêts pour les attaques de demain ?
Cette nouvelle faille rappelle que même les protocoles les plus robustes (SAML, OAuth2, OpenID) dépendent de l’intégrité de leurs implémentations. Une simple XSS peut faire basculer toute une infrastructure. La sécurité ne se décrète pas, elle s’entretient : veille, patch, test, repeat.
Et vous, avez-vous déjà audité votre Identity Provider ? Partagez vos retours d’expérience ou vos questions dans les commentaires, votre astuce pourrait éviter un incident à la communauté !
Pour consulter le détail technique et les indicateurs de compromission, rendez-vous sur l’avis original du CERT-FR.