DocumentationExperience Cloud KCS

L’accès non authentifié expose le TrustStore et les métadonnées internes via les URL des instances de publication

Dernière mise à jour : 23 juin 2026

Si les filtres Dispatcher sur les instances de publication Adobe Experience Manager (AEM) sont trop permissifs, les requêtes non authentifiées peuvent exposer les ressources liées au TrustStore, les métadonnées internes et d’autres chemins d’accès non publics. Pour résoudre ce problème, passez en revue et resserrez les règles de filtrage Dispatcher, refusez explicitement l’accès aux points d’entrée sensibles et vérifiez que les requêtes conçues sont bloquées avant d’atteindre le niveau de publication.

Description description

Environnement

Déploiements de Adobe Experience Manager (AEM) qui utilisent Dispatcher devant les instances de publication

Problème/Symptômes

Les symptômes suivants sont observés sur les instances de publication AEM lorsque les règles de filtrage de Dispatcher sont trop permissives ou que les chemins sensibles ne sont pas explicitement limités :

  • Certaines URL de l’instance de publication sont accessibles par le biais de requêtes GET non authentifiées sans nécessiter d’authentification, de cookies ou d’en-têtes spéciaux.
  • Les requêtes réussies peuvent exposer les ressources liées au TrustStore, les noms de nœuds internes, la structure de contenu, les chemins d’accès liés à la configuration et les métadonnées des ressources.
  • Certaines demandes préconçues permettent également d’accéder à des chemins d’accès liés à la connexion interne qui devraient normalement être restreints.

Exemples d’URL :

  • https://www.example.com/etc/truststore.-1.json;x='.ico/x'- Peut exposer les informations liées au TrustStore
  • https://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- Peut autoriser le téléchargement du fichier de certificat truststore
  • https://www.example.com/.children.-1.json;x='.ico/x'- Peut exposer les noms de nœuds internes, la structure de contenu, les chemins liés à la configuration et les métadonnées
  • https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- Peut exposer les métadonnées de ressources par le biais de MergeMetadataServlet
  • https://www.example.com/libs/granite/core/content/login.html;x='.ico/x'- Peut autoriser l’accès à un chemin d’accès lié à la connexion interne qui devrait normalement être restreint

Erreur/Sortie du journal

Aucun message d’erreur explicite ; le problème est l’exposition involontaire des ressources internes.

Cause

Le problème est généralement causé par des règles de filtrage Dispatcher qui ne sont pas suffisamment restrictives pour bloquer les requêtes conçues ou pour empêcher l’accès aux chemins internes sensibles sur les instances de publication.

Résolution resolution

Remarque : le filtrage Dispatcher est important, mais il ne constitue pas en lui-même une limite de sécurité fiable. Les listes de contrôle d’accès du référentiel AEM et les restrictions de point d’entrée sur la publication doivent rester le contrôle principal, avec les règles Dispatcher/Apache/CDN comme défense en profondeur.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifier la configuration des filtres Dispatcher

    • Ouvrez le fichier de configuration Dispatcher, par exemple dispatcher.any.
    • Recherchez la section /filter ou /filters .

  2. Ajoutez une règle pour refuser les requêtes contenant des points-virgules ou d’autres modèles d’URL suspects lorsque ces modèles ne sont pas requis par l’application.

    code language-none 
    /0xxx { /type "deny" /url "*;*" }

    Cette règle bloque toute requête contenant un point-virgule dans l’URL, qui est généralement utilisée dans les requêtes conçues pour contourner le filtrage.

  3. Restreindre l’accès aux chemins sensibles

    • Ajoutez des règles de refus explicites pour les chemins sensibles tels que /etc/truststore, /libs/dam/merge et /libs/granite/core/content/login.html.

    • Exemple :

      code language-none 
      /0xxx { /type "deny" /url "/etc/truststore*" }
                        /0xxx { /type "deny" /url "/libs/dam/merge*" }
                        /0xxx { /type "deny" /url "/libs/granite/core/content/login.html*" }

  4. Validation de la configuration mise à jour

    • Déployez la configuration Dispatcher mise à jour sur toutes les instances de publication.
    • Testez à nouveau les URL précédemment exposées et confirmez qu’elles renvoient désormais une réponse bloquée, telle que 404 ou une autre réponse de refus attendue en fonction de votre configuration.

  5. Examiner le renforcement du niveau de publication

    • Vérifiez que les ressources sensibles ne sont pas accessibles de manière anonyme lors de la publication.
    • Examinez les autorisations AEM et l’exposition du servlet pour les points d’entrée internes.
    • Dans la mesure du possible, privilégiez un modèle Dispatcher basé sur des données afin que seuls les chemins connus et requis soient exposés publiquement.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles