DocumentaciónKCS de Experience Cloud

El acceso no autenticado expone el almacén de confianza y los metadatos internos a través de las direcciones URL de instancia de publicación

Última actualización: 22 de junio de 2026

Si los filtros de Dispatcher en las instancias de publicación de Adobe Experience Manager (AEM) son demasiado permisivos, las solicitudes no autenticadas pueden exponer recursos relacionados con el almacén de confianza, metadatos internos y otras rutas no públicas. Para resolver este problema, revise y ajuste las reglas de filtro de Dispatcher, deniegue explícitamente el acceso a los extremos confidenciales y valide que las solicitudes escritas se bloquean antes de que lleguen al nivel de publicación.

Descripción description

Entorno

Implementaciones de Adobe Experience Manager (AEM) que utilizan Dispatcher delante de las instancias de publicación

Problema/Síntomas

Los siguientes síntomas se observan en las instancias de publicación de AEM cuando las reglas de filtro de Dispatcher son demasiado permisivas o las rutas confidenciales no están restringidas explícitamente:

  • Se puede acceder a ciertas URL de instancia de publicación a través de solicitudes GET no autenticadas sin requerir autenticación, cookies ni encabezados especiales.
  • Las solicitudes correctas pueden exponer recursos relacionados con el almacén de confianza, nombres de nodos internos, estructura de contenido, rutas relacionadas con la configuración y metadatos de recursos.
  • Algunas solicitudes creadas también permiten el acceso a rutas internas relacionadas con el inicio de sesión que, normalmente, se esperan restringir.

URL de ejemplo:

  • https://www.example.com/etc/truststore.-1.json;x='.ico/x': puede exponer información relacionada con truststore
  • https://www.example.com/etc/truststore/truststore.p12;x='.ico/x': puede permitir la descarga del archivo de certificado del almacén de confianza
  • https://www.example.com/.children.-1.json;x='.ico/x': puede exponer nombres de nodo internos, estructura de contenido, rutas de acceso relacionadas con la configuración y metadatos
  • https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico: puede exponer los metadatos del recurso mediante MergeMetadataServlet
  • https://www.example.com/libs/granite/core/content/login.html;x='.ico/x': puede permitir el acceso a una ruta de acceso interna relacionada con el inicio de sesión que, por lo general, se espera que esté restringida

Salida de error/registro

No hay mensajes de error explícitos; el problema es la exposición no deseada de los recursos internos.

Causa

El problema suele deberse a reglas de filtro de Dispatcher que no son lo suficientemente restrictivas como para bloquear solicitudes escritas o para impedir el acceso a rutas internas confidenciales en instancias de publicación.

Resolución resolution

Nota: El filtrado de Dispatcher es importante, pero no es un límite de seguridad confiable en sí mismo. Las ACL del repositorio de AEM y las restricciones de extremo en la publicación deben seguir siendo el control principal, con reglas de Dispatcher/Apache/CDN como defensa en profundidad.

Siga estos pasos para resolver el problema:

  1. Revisar configuración de filtros de Dispatcher

    • Abra el archivo de configuración de Dispatcher, como dispatcher.any.
    • Busque la sección /filter o /filters.

  2. Agregue una regla para denegar las solicitudes que contengan punto y coma u otros patrones de URL sospechosos cuando la aplicación no requiera dichos patrones.

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

    Esta regla bloquea cualquier solicitud que contenga un punto y coma en la dirección URL, que se usa comúnmente en solicitudes escritas para evitar el filtrado.

  3. Restringir el acceso a rutas confidenciales

    • Agregar reglas de denegación explícitas para rutas confidenciales como /etc/truststore, /libs/dam/merge y /libs/granite/core/content/login.html.

    • Ejemplo:

      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. Validar la configuración actualizada

    • Implemente la configuración actualizada de Dispatcher en todas las instancias de publicación.
    • Vuelva a probar las direcciones URL expuestas anteriormente y confirme que ahora devuelven una respuesta bloqueada, como 404 u otra respuesta de denegación esperada según la configuración.

  5. Revisar protección del nivel de publicación

    • Compruebe que los recursos confidenciales no son accesibles de forma anónima durante la publicación.
    • Revise los permisos de AEM y la exposición al servlet para los extremos internos.
    • Prefiera un modelo de Dispatcher basado en listas de permitidos siempre que sea posible, de modo que solo las rutas conocidas y requeridas se expongan públicamente.

Lectura relacionada

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