DocumentazioneExperience Cloud KCS

L’accesso non autenticato espone il truststore e i metadati interni tramite gli URL dell’istanza Publish

Ultimo aggiornamento: 24 giugno 2026

Se i filtri di Dispatcher nelle istanze di pubblicazione di Adobe Experience Manager (AEM) sono troppo permissivi, le richieste non autenticate possono esporre risorse correlate al truststore, metadati interni e altri percorsi non pubblici. Per risolvere questo problema, rivedi e stringi le regole del filtro Dispatcher, nega esplicitamente l’accesso agli endpoint sensibili e verifica che le richieste create siano bloccate prima che raggiungano il livello di pubblicazione.

Descrizione description

Ambiente

Distribuzioni di Adobe Experience Manager (AEM) che utilizzano Dispatcher prima delle istanze di pubblicazione

Problema/Sintomi

I seguenti sintomi si osservano nelle istanze di pubblicazione di AEM quando le regole dei filtri di Dispatcher sono troppo permissive o i percorsi sensibili non sono esplicitamente limitati:

  • Alcuni URL dell’istanza Publish sono accessibili tramite richieste GET non autenticate senza richiedere autenticazione, cookie o intestazioni speciali.
  • Le richieste riuscite possono esporre risorse relative al truststore, nomi di nodi interni, struttura del contenuto, percorsi relativi alla configurazione e metadati delle risorse.
  • Alcune richieste create consentono anche l’accesso a percorsi interni correlati all’accesso che normalmente dovrebbero essere soggetti a restrizioni.

URL di esempio:

  • https://www.example.com/etc/truststore.-1.json;x='.ico/x'- Potrebbe esporre informazioni relative al truststore
  • https://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- Consenti il download del file di certificato del truststore
  • https://www.example.com/.children.-1.json;x='.ico/x'- Può esporre nomi di nodi interni, struttura del contenuto, percorsi relativi alla configurazione e metadati
  • https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- Potrebbe esporre i metadati della risorsa tramite MergeMetadataServlet
  • https://www.example.com/libs/granite/core/content/login.html;x='.ico/x'- Può consentire l’accesso a un percorso interno correlato all’accesso che normalmente si prevede sia soggetto a restrizioni

Errore/Output registro

Nessun messaggio di errore esplicito; il problema è l’esposizione involontaria di risorse interne.

Causa

Il problema è in genere causato da regole di filtro di Dispatcher che non sono abbastanza restrittive da bloccare le richieste create o impedire l’accesso a percorsi interni sensibili nelle istanze di pubblicazione.

Risoluzione resolution

Nota: il filtro Dispatcher è importante, ma non costituisce di per sé un limite di sicurezza affidabile. Le ACL dell’archivio AEM e le restrizioni degli endpoint sulla pubblicazione devono rimanere il controllo primario, con le regole Dispatcher/Apache/CDN come difesa approfondita.

Per risolvere il problema, segui la procedura riportata di seguito:

  1. Verifica la configurazione dei filtri di Dispatcher

    • Aprire il file di configurazione di Dispatcher, ad esempio dispatcher.any.
    • Individuare la sezione /filter o /filters.

  2. Aggiungi una regola per rifiutare le richieste contenenti punti e virgola o altri pattern di URL sospetti quando tali pattern non sono richiesti dall’applicazione.

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

    Questa regola blocca qualsiasi richiesta contenente un punto e virgola nell’URL, che viene comunemente utilizzato nelle richieste create per ignorare il filtro.

  3. Limita l’accesso ai percorsi sensibili

    • Aggiungere regole di negazione esplicite per i percorsi sensibili come /etc/truststore, /libs/dam/merge e /libs/granite/core/content/login.html.

    • Esempio:

      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. Convalidare la configurazione aggiornata

    • Distribuisci la configurazione di Dispatcher aggiornata a tutte le istanze di pubblicazione.
    • Eseguire nuovamente il test degli URL esposti in precedenza e confermare che ora restituiscono una risposta bloccata, ad esempio 404 o un’altra risposta di negazione prevista in base alla configurazione.

  5. Verifica protezione avanzata livello di pubblicazione

    • Verifica che le risorse sensibili non siano accessibili in modo anonimo al momento della pubblicazione.
    • Controlla le autorizzazioni di AEM e l’esposizione al servlet per gli endpoint interni.
    • Se possibile, preferisci un modello Dispatcher basato su inserisce nell’elenco Consentiti di targeting in modo che solo i percorsi noti e richiesti siano esposti pubblicamente.

Lettura correlata

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