Nicht authentifizierter Zugriff macht TrustStore- und interne Metadaten über URLs der Veröffentlichungsinstanz verfügbar

Letzte Aktualisierung: 20. Juni 2026

Wenn Dispatcher-Filter auf Adobe Experience Manager (AEM)-Veröffentlichungsinstanzen zu tolerant sind, können nicht authentifizierte Anfragen TrustStore-bezogene Ressourcen, interne Metadaten und andere nicht öffentliche Pfade verfügbar machen. Um dieses Problem zu beheben, überprüfen Sie die Dispatcher-Filterregeln und verschärfen Sie sie, verweigern Sie explizit den Zugriff auf sensible Endpunkte und überprüfen Sie, ob erstellte Anfragen blockiert werden, bevor sie die Veröffentlichungsebene erreichen.

Beschreibung description

Umgebung

Adobe Experience Manager (AEM)-Bereitstellungen, die Dispatcher vor Veröffentlichungsinstanzen verwenden

Problem/Symptome

Die folgenden Symptome treten bei AEM-Veröffentlichungsinstanzen auf, wenn Dispatcher-Filterregeln zu tolerant sind oder sensible Pfade nicht explizit eingeschränkt sind:

Auf bestimmte URLs der Veröffentlichungsinstanz kann über nicht authentifizierte GET zugegriffen werden, ohne dass eine Authentifizierung, Cookies oder spezielle Kopfzeilen erforderlich sind.
Erfolgreiche Anfragen können TrustStore-bezogene Ressourcen, interne Knotennamen, die Inhaltsstruktur, konfigurationsbezogene Pfade und Asset-Metadaten offenlegen.
Einige erstellte Anfragen ermöglichen auch den Zugriff auf interne anmeldebezogene Pfade, die normalerweise eingeschränkt sein dürften.

Beispiel-URLs:

https://www.example.com/etc/truststore.-1.json;x='.ico/x'- Kann TrustStore-bezogene Informationen bereitstellen
https://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- Kann den Download der TrustStore-Zertifikatdatei zulassen.
https://www.example.com/.children.-1.json;x='.ico/x'- Kann interne Knotennamen, Inhaltsstruktur, konfigurationsbezogene Pfade und Metadaten verfügbar machen
https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- Kann Asset-Metadaten über MergeMetadataServlet verfügbar machen
https://www.example.com/libs/granite/core/content/login.html;x='.ico/x'- Kann den Zugriff auf einen internen anmeldebezogenen Pfad ermöglichen, der normalerweise eingeschränkt sein sollte

Fehler-/Protokollausgabe

Keine expliziten Fehlermeldungen. Das Problem ist die unbeabsichtigte Offenlegung interner Ressourcen.

Ursache

Das Problem wird in der Regel durch Dispatcher-Filterregeln verursacht, die nicht restriktiv genug sind, um erstellte Anfragen zu blockieren oder den Zugriff auf sensible interne Pfade auf Veröffentlichungsinstanzen zu verhindern.

Lösung resolution

Hinweis: Die Filterung mit Dispatcher ist wichtig, stellt jedoch keine zuverlässige Sicherheitsgrenze für sich selbst dar. AEM-Repository-ACLs und Endpunktbeschränkungen für die Veröffentlichung müssen weiterhin die primäre Kontrolle bleiben, wobei Dispatcher-/Apache-/CDN-Regeln als Verteidigung tief greifend sein müssen.

Führen Sie zur Behebung des Problems folgende Schritte aus:

Überprüfen der Konfiguration von Dispatcher-Filtern
- Öffnen Sie die Dispatcher-Konfigurationsdatei, z. B. dispatcher.any.
- Suchen Sie den Abschnitt /filter oder /filters .

Fügen Sie eine Regel hinzu, um Anfragen mit Semikolons oder anderen verdächtigen URL-Mustern zu verweigern, wenn diese Muster von der Anwendung nicht benötigt werden.

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

Diese Regel blockiert alle Anfragen, die ein Semikolon in der URL enthalten. Dies wird häufig in erstellten Anfragen verwendet, die die Filterung umgehen sollen.

Zugriff auf sensible Pfade einschränken

Fügen Sie explizite Ablehnungsregeln für sensible Pfade wie /etc/truststore, /libs/dam/merge und /libs/granite/core/content/login.html hinzu.

Beispiel:

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*" }`

Validieren der aktualisierten Konfiguration
- Stellen Sie die aktualisierte Dispatcher-Konfiguration für alle Veröffentlichungsinstanzen bereit.
- Testen Sie die zuvor offen gelegten URLs erneut und bestätigen Sie, dass sie jetzt eine blockierte Antwort zurückgeben, z. B. 404 oder eine andere erwartete Antwort vom Typ Ablehnen , die auf Ihrer Einrichtung basiert.
Überprüfen der Härtung auf Veröffentlichungsebene
- Stellen Sie sicher, dass bei der Veröffentlichung nicht anonym auf sensible Ressourcen zugegriffen werden kann.
- Überprüfen Sie die AEM-Berechtigungen und die Verfügbarkeit von Servlets für interne Endpunkte.
- Nach Möglichkeit sollten Sie möglichst ein auf Zulassungslisten basierendes Dispatcher-Modell bevorzugen, damit nur bekannte, erforderliche Pfade öffentlich verfügbar gemacht werden.