Host header injection leads to SSRF via resource-js endpoint

Beschreibung

### Zusammenfassung Der Endpunkt "resource-js" in Craft CMS ermöglicht nicht authentifizierte Anforderungen an Proxy-Remote-Javascript-Ressourcen. Wenn "trustedHosts" nicht explizit eingeschränkt ist (Standardkonfiguration), vertraut die Anwendung dem vom Client bereitgestellten Host-Header. Dadurch kann ein Angreifer die abgeleitete `baseUrl` steuern, die in der Präfixvalidierung innerhalb `actionResourceJs()` verwendet wird. Durch die Bereitstellung eines bösartigen Host-Headers kann der Angreifer den Server dazu bringen, willkürliche HTTP-Anforderungen auszugeben, was zu Server-Side Request Forgery (SSRF) führt. ### Details Die Sicherheitslücke existiert in `AppController::actionResourceJs()`. Die Funktion bestätigt, dass der Parameter `url` mit `assetManager->baseUrl` beginnt. "baseUrl" wird jedoch vom aktuellen Request-Host abgeleitet. Wenn "trustedHosts" nicht konfiguriert ist, ist der Host-Header vollständig angreifergesteuert. Angriffskette: 1. Angreifer sendet Anfrage mit kontrolliertem "Host"-Header. 2. Die Anwendung leitet `baseUrl` vom bösartigen Host ab. 3. Der Parameter `url` ist erforderlich, um mit diesem `baseUrl` zu beginnen. 4. Validierung besteht. 5. Guzzle führt eine serverseitige HTTP-Anfrage an den vom Angreifer kontrollierten Host aus. 6. SSRF tritt auf. Dies ist nicht auf String Parsing Bypass angewiesen. Es setzt auf Host Header Trust. PoC (sichere Reproduktionsschritte) Umgebung: - Craft CMS 5.9.12 - Standardkonfiguration (keine TrustedHosts-Einschränkung) - Docker-Bereitstellung 1. Starten Sie einen Listener im Container: python3 -m http.server 9999 2. Senden Sie eine Anfrage an Resource-js mit einem kontrollierten Host-Header. 3. Beachten Sie, dass der interne Zuhörer eine Anfrage erhält (OOB-Bestätigung). ## Referenzen https://github.com/craftcms/cms/commit/ebe7e85f1c89700d64332f72492be2e9a594e783

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 5.9.15, 4.17.9.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Pixel & Tonic Craft CMS.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.