Réduction du risque de contournement de l’authentification dans Adobe Experience Manager Assets à l’aide des règles de filtrage Dispatcher
Cet article explique comment passer en revue les règles de filtrage Dispatcher pour le point d’entrée de connexion AEM Assets exclu de l’authentification SAML. Les filtres Dispatcher limitent les requêtes par URL et méthode ; ils n’authentifient pas les utilisateurs et utilisatrices et ne remplacent pas les autorisations du référentiel AEM. Pour atténuer ce risque, vérifiez les chemins de rappel SAML et le point d’entrée, vérifiez l’ordre de filtrage en vigueur et les autorisations de référentiel, puis testez les modifications dans un environnement hors production avant le déploiement en production.
Description description
Environnement
Environnements Adobe Experience Manager as a Cloud Service utilisant AEM Assets, l’authentification SAML et Dispatcher
Problème/Symptômes
- Une révision de sécurité identifie un point d’entrée de connexion AEM Assets qui est exclu de l’authentification SAML.
- La configuration de Dispatcher ne limite pas les requêtes à ce point d’entrée comme prévu.
- L’équipe de sécurité doit vérifier si le point d’entrée expose des fonctionnalités ou des données à des requêtes non authentifiées.
Cause
Un point d’entrée SAML exclu n’appelle pas le test SAML pour les requêtes vers ce chemin d’accès. Les filtres Dispatcher correspondent aux attributs de requête tels que l’URL et la méthode ; ils n’authentifient pas l’appelant. Une règle d’autorisation de filtre n’accorde pas d’authentification ou ne remplace pas les autorisations de référentiel. Protégez les fonctionnalités et les données sensibles avec l’authentification AEM et les autorisations de référentiel applicables, et utilisez Dispatcher comme couche de filtrage d’accès supplémentaire.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème.
-
Passez en revue les règles de filtrage Dispatcher et identifiez les entrées qui s’appliquent au point d’entrée de connexion, telles que
/libs/granite/core/content/login*). -
Mettez à jour votre configuration Dispatcher pour ajouter les règles suivantes :
- Par défaut, refusez toutes les requêtes au nœud de connexion :
/0100 { /type "deny" /url "/libs/granite/core/content/login*" }- Autorisez uniquement les requêtes GET légitimes sur la page de connexion.
/0101 { /type "allow" /method "GET" /url "/libs/granite/core/content/login.html" }- Autorise uniquement la cible POST du formulaire utilisée par le flux de connexion.
/0102 { /type "allow" /method "POST" /url "/libs/granite/core/content/login.html/j_security_check" } -
Vérifiez que les règles sont correctement ordonnées. Comme les règles de filtrage Dispatcher utilisent un modèle d’évaluation last-match-wins, placez la règle de refus plus large avant les règles d’autorisation plus spécifiques.
-
Déployez la configuration Dispatcher mise à jour dans un environnement hors production.
-
Vérifiez que seules les requêtes de connexion légitimes sont autorisées et que toutes les autres requêtes au point d’entrée de connexion sont refusées.
-
Vérifiez que le processus de connexion continue de fonctionner comme prévu.
-
Après avoir validé la configuration, déployez les modifications dans l’environnement de production.
-
Surveillez les journaux et les tentatives d’accès pour vérifier que la vulnérabilité est atténuée et que les tentatives d’accès non autorisées sont bloquées.