DocumentaçãoKCS da Experience Cloud

O acesso não autenticado expõe a truststore e os metadados internos por meio de URLs da instância de publicação

Última atualização: 20 de junho de 2026

Se os filtros do Dispatcher nas instâncias de publicação do Adobe Experience Manager (AEM) forem muito permissivos, as solicitações não autenticadas poderão expor recursos relacionados ao truststore, metadados internos e outros caminhos não públicos. Para resolver esse problema, revise e aprimore as regras de filtro do Dispatcher, negue explicitamente o acesso a endpoints confidenciais e valide se as solicitações criadas estão bloqueadas antes de atingirem o nível de publicação.

Descrição description

Ambiente

Implantações do Adobe Experience Manager (AEM) que usam o Dispatcher na frente de instâncias de publicação

Problema/Sintomas

Os seguintes sintomas são observados nas instâncias de publicação do AEM quando as regras de filtro do Dispatcher são muito permissivas ou caminhos confidenciais não são explicitamente restritos:

  • Determinadas URLs da instância de publicação podem ser acessadas por meio de solicitações GET não autenticadas sem a necessidade de autenticação, cookies ou cabeçalhos especiais.
  • As solicitações bem-sucedidas podem expor recursos relacionados ao truststore, nomes de nós internos, estrutura de conteúdo, caminhos relacionados à configuração e metadados de ativos.
  • Algumas solicitações criadas também permitem acesso a caminhos internos relacionados ao logon que normalmente devem ser restritos.

Exemplo de URLs:

  • https://www.example.com/etc/truststore.-1.json;x='.ico/x'- Pode expor informações relacionadas ao truststore
  • https://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- Pode permitir o download do arquivo de certificado do truststore
  • https://www.example.com/.children.-1.json;x='.ico/x'- Pode expor nomes de nós internos, estrutura de conteúdo, caminhos relacionados à configuração e metadados
  • https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- Pode expor metadados de ativos através de MergeMetadataServlet
  • https://www.example.com/libs/granite/core/content/login.html;x='.ico/x'- Pode permitir acesso a um caminho interno relacionado a logon que normalmente deve ser restrito

Saída de Erro/Log

Não há mensagens de erro explícitas; o problema é a exposição não intencional dos recursos internos.

Causa

O problema geralmente é causado por regras de filtro do Dispatcher que não são restritivas o suficiente para bloquear solicitações criadas ou impedir o acesso a caminhos internos confidenciais em instâncias de publicação.

Resolução resolution

Observação: a filtragem de Dispatcher é importante, mas não é um limite de segurança confiável por si só. As ACLs de repositório do AEM e as restrições de endpoint na publicação devem permanecer como o controle principal, com as regras do Dispatcher/Apache/CDN como defesa em profundidade.

Siga estas etapas para resolver o problema:

  1. Revisar a configuração de filtros do Dispatcher

    • Abra o arquivo de configuração do Dispatcher, como dispatcher.any.
    • Localize a seção /filter ou /filters.

  2. Adicione uma regra para negar solicitações que contenham ponto e vírgula ou outros padrões de URL suspeitos quando esses padrões não forem exigidos pelo aplicativo.

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

    Essa regra bloqueia qualquer solicitação contendo um ponto e vírgula na URL, que é comumente usada em solicitações criadas com o objetivo de ignorar a filtragem.

  3. Restringir o acesso a caminhos confidenciais

    • Adicione regras de negação explícitas para caminhos confidenciais como /etc/truststore, /libs/dam/merge e /libs/granite/core/content/login.html.

    • Exemplo:

      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 a configuração atualizada

    • Implante a configuração atualizada do Dispatcher em todas as instâncias de publicação.
    • Teste novamente as URLs expostas anteriormente e confirme se elas agora retornam uma resposta bloqueada, como 404 ou outra resposta de negação esperada, com base em sua configuração.

  5. Revisar proteção no nível de publicação

    • Verifique se os recursos confidenciais não estão acessíveis anonimamente na publicação.
    • Revise as permissões do AEM e a exposição do servlet para endpoints internos.
    • Prefira um modelo Dispatcher baseado em incluo na lista de permissões sempre que possível, para que somente os caminhos conhecidos e necessários sejam expostos publicamente.

Leitura relacionada

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