Symfony Profiler: Vom Debugging-Tool zum Sicherheitsrisiko

Symfony gehört zu den etablierten PHP Frameworks und bildet die technische Grundlage zahlreicher Webanwendungen - darunter auch Shopware 6. Für Entwickler bietet Symfony mit dem Web Profiler ein leistungsfähiges Werkzeug zur Fehlersuche. Doch was passiert, wenn dieses Tool versehentlich auf einem öffentlich erreichbaren Produktionssystem aktiviert bleibt? Normalerweise sollte es nur lokal verwendet werden.

Im schlimmsten Fall erhalten Angreifer Einblick in HTTP-Requests, Authentifizierungsinformationen, interne Konfigurationen und weitere sensible Daten. Unter bestimmten Voraussetzungen kann daraus eine vollständige Kompromittierung der Anwendung entstehen.

Öffentlich erreichbare Debug - Installationen lassen sich teilweise automatisiert identifizieren.

Was ist der Symfony Profiler?

Der Symfony Profiler ist ein Debugging-Werkzeug, das Entwicklern umfangreiche Informationen über die Verarbeitung einzelner HTTP-Requests liefert.

Damit können beispielsweise folgende Informationen untersucht werden:

• Eingehende HTTP-Requests inklusive Headern und Parametern
• Ausgeführte Datenbankabfragen
• Aufgerufene Controller und interne Routen
• Log-Meldungen und aufgetretene Exceptions
• Performance-Daten und Speicherverbrauch
• Informationen über den Security Context und authentifizierte Benutzer

Im Entwicklungsalltag ist das äußerst hilfreich. Anstatt Fehler mühsam über Logdateien nachzuvollziehen, können Entwickler direkt nachvollziehen, was während eines Requests passiert ist.

Die Informationen lassen sich über die bekannte Symfony Debug Toolbar oder das Webinterface unter `/_profiler` abrufen.

Genau dieser Detailgrad wird jedoch zum Sicherheitsrisiko, sobald unbefugte Personen Zugriff darauf erhalten.

Warum ist ein öffentlich erreichbarer Symfony Profiler so gefährlich?

Die offizielle Symfony Dokumentation warnt ausdrücklich davor, den Profiler in Produktionsumgebungen zu aktivieren.

Der Grund ist einfach: Der Profiler wurde für die Entwicklung und Fehleranalyse konzipiert, nicht als öffentlich zugängliches System.

Je nach Konfiguration und aktivierten Data Collectors können deutlich mehr Informationen sichtbar werden, als Betreiber erwarten.

1. Vergangene HTTP-Requests können eingesehen werden

Eine der kritischsten Funktionen ist die Aufzeichnung von Requests.

Über das Profiler-Interface können Entwickler vergangene Requests analysieren. Dabei lassen sich unter anderem angefragte URLs, HTTP-Methoden, Request-Parameter und weitere Metadaten untersuchen.

Das ist besonders interessant, wenn eine Anwendung APIs bereitstellt oder administrative Funktionen über HTTP erreichbar sind.

Beispiel: Eine API-Integration

Angenommen, ein Onlineshop kommuniziert mit einem ERP-System oder einem externen Dienst. Im Rahmen dieser Kommunikation könnten API-Keys oder Bearer Tokens übertragen werden.

Wenn solche Informationen vom Profiler erfasst und nicht ausreichend maskiert werden, können sie in den gespeicherten Request-Profilen auftauchen.

Ein Angreifer, der diese Informationen auslesen kann, erhält damit möglicherweise gültige Zugangsdaten für eine externe Integration.

Wichtig ist dabei: Nicht jeder Authorization-Header oder jedes Secret wird automatisch im Klartext gespeichert. Ob Informationen sichtbar sind, hängt von der konkreten Symfony-Version, der Anwendung, den Data Collectors und der jeweiligen Konfiguration ab.

Das sind auch keine konstruierten Fälle, sondern echte Beispiele denen ich nachgehen konnte.

Normalerweise ist die Integration auf das notwendigste eingeschränkt. In der Realität ist es einfacher volle Administratorrechte zu erteilen, damit alles funktioniert.

2. Auch administrative Requests sind interessant

Ein noch problematischeres Szenario entsteht, wenn administrative Requests profiliert werden.

Beispielsweise könnte ein Administrator:

• sich in der Administration anmelden
• Benutzer verwalten
• Integrationen konfigurieren

Der Bearer Token wird auch aufgezeichnet. Die Gültigkeit davon ist zwar eingeschraenkt, aber wenn der Angreifer etwas Geduld hat, kann es schwierig werden.

Falls dabei relevante Request-Daten, Session-Informationen oder sensible Parameter aufgezeichnet werden, könnte eine fremde Person diese Informationen über den Profiler auslesen.

Dabei muss der Angreifer nicht zwangsläufig selbst einen administrativen Request ausführen. Bereits gespeicherte Profile legitimer Benutzer können ausreichen, um vertrauliche Informationen offenzulegen.

Ob aus diesen Informationen tatsächlich eine Session übernommen oder ein Benutzerkonto kompromittiert werden kann, hängt davon ab, welche Daten verfügbar und noch gültig sind.

3. Interne Anwendungsinformationen können offengelegt werden

Neben einzelnen Requests kann ein erreichbarer Profiler auch interne technische Details preisgeben.

Dazu gehören unter Umständen:

• Symfony- und PHP-Versionen
• Interne Routen und Controller
• Exception-Informationen und Stacktraces
• Informationen über Datenbankabfragen
• Konfigurationsdetails und Umgebungsvariablen

Solche Informationen erleichtern es einem Angreifer, die Architektur einer Anwendung zu verstehen und weitere Angriffsmöglichkeiten zu identifizieren.

Besonders kritisch wird es, wenn Secrets, Datenbankzugangsdaten oder Informationen aus internen Konfigurationsdateien verfügbar sind, z.B. DATABASE_URL oder APP_SECRET

Wie lassen sich öffentlich erreichbare Symfony Profiler finden?

Eine Debug Toolbar muss nicht einmal sichtbar sein, damit sich eine potenzielle Fehlkonfiguration erkennen lässt.

Symfony verwendet verschiedene HTTP-Response-Header, um Informationen über gespeicherte Profile bereitzustellen.

Ein besonders interessanter Header lautet:

`X-Debug-Token-Link`

Bei profilierten Responses kann dieser Header einen direkten Link zum zugehörigen Request-Profil enthalten.

Das ist insbesondere bei API-Responses relevant, da Symfony die grafische Debug Toolbar normalerweise nur in HTML-Antworten einbindet.

Ein beispielhafter Response könnte so aussehen:

HTTP/1.1 200 OK
Content-Type: application/json
X-Debug-Token: abc123
X-Debug-Token-Link: https://example.com/_profiler/abc123

Der Header allein beweist allerdings noch nicht, dass ein Angreifer tatsächlich Zugriff auf den Profiler erhält. Entscheidend ist, ob die verlinkten Debug-Informationen ohne ausreichende Zugriffskontrolle abrufbar sind.

Über Suchmaschinen

Über Suchmaschinen für öffentlich erreichbare Internetdienste lassen sich HTTP-Header als Suchkriterium verwenden.

An dieser Stelle moechte ich keine Suchmaschinen dafuer vorstellen, sondern nur erklaeren, dass es sehr einfach ist. Die Suchergebnisse sind nicht automatisch bestätigte Sicherheitslücken. Sie liefern zunächst Hinweise auf potenziell exponierte Debug-Funktionen.

In der Recherche zu diesem Blog Post, konnte ich ueber 500 Ergebnisse finden, denen ich stichprobenartig nachgegangen bin. Bei fast allen Ergebnissen war der Profiler aktiv. Entweder auf der Production Umgebung oder auf einer Staging Umgebung, die auf dem selben Server liegt.

Oft werden bei Staging Umgebungen die Zugangsdaten oder API Integrationen von der Production Umgebung uebernommen, sodass es auch moeglich ist auf die Production Umgebung zuzugreifen.

EOS: Ein Werkzeug, das die Risiken demonstriert

Wie weitreichend die Folgen einer falsch konfigurierten Symfony-Anwendung sein können, zeigt das Open-Source-Projekt Enemies Of Symfony (EOS) des französischen IT-Sicherheitsunternehmens Synacktiv.

GitHub: https://github.com/Synacktiv/eos

EOS wurde entwickelt, um Informationen aus Symfony-Anwendungen mit exponiertem Debug-Modus zu sammeln und auszuwerten.

Das Tool untersucht unter anderem folgende Bereiche:

• Request Logs -> Potenziell sensible POST-Parameter und Zugangsdaten
• PHP-Informationen -> Umgebungsvariablen und Konfigurationswerte
• Routes -> Registrierte Endpunkte und interne Routen
• Project Files -> Projekt- und Konfigurationsdateien
• Source Code -> Unter geeigneten Bedingungen Anwendungscode
• Authentication -> Informationen, die zur Manipulation von Remember-Me-Cookies missbraucht werden könnten

Besonders interessant ist, dass EOS nicht auf einer klassischen Sicherheitslücke im Symfony-Framework basiert.

Das Werkzeug nutzt vielmehr die Informationen aus, die eine falsch konfigurierte Debug-Umgebung bereitstellt.

Die Schwachstelle liegt damit häufig nicht in Symfony selbst, sondern in der Bereitstellung der Anwendung.

Das Beispiel verdeutlicht außerdem, wie aus einer zunächst harmlos wirkenden Informationspreisgabe ein weitreichender Sicherheitsvorfall entstehen kann.

Wie aus einem Debug-Problem eine vollständige Kompromittierung werden kann

Betrachten wir ein hypothetisches Szenario.

Ein Unternehmen betreibt einen Shopware 6 Onlineshop. Bei einer Fehleranalyse wird der Profiler aktiviert und versehentlich öffentlich erreichbar gelassen.

Zunächst scheint das kein großes Problem zu sein. Der Shop funktioniert weiterhin, und die Debug Toolbar fällt im normalen Betrieb möglicherweise nicht einmal auf.

Allerdings werden im Hintergrund Profile einzelner Requests gespeichert.

In diesen Requests könnten sich Informationen über angebundene ERP-Systeme, administrative APIs oder Benutzeraktionen befinden.

Ein möglicher Angriffsverlauf sieht dann folgendermaßen aus:

1. Eine öffentlich erreichbare Anwendung gibt Hinweise auf einen aktivierten Symfony Profiler preis.
2. Ein Angreifer stellt fest, dass gespeicherte Profile ohne ausreichende Authentifizierung eingesehen werden können.
3. In den Profilen befinden sich sensible Informationen aus legitimen Requests.
4. Unter Umständen werden gültige Credentials oder andere sicherheitsrelevante Daten offengelegt.
5. Werden diese Daten erfolgreich missbraucht, können daraus weitere Zugriffe auf den Shop oder verbundene Systeme entstehen.

Die eigentliche Gefährdung ist deshalb nicht auf das Auslesen von Debug-Daten begrenzt.

Ein erreichbarer Profiler kann zum Ausgangspunkt weiterer Angriffe auf die gesamte E-Commerce-Infrastruktur werden.

Das gilt insbesondere für Systeme mit umfangreichen Schnittstellen, administrativen Funktionen und externen Integrationen.

Wie schützt man eine Symfony-Anwendung?

Die wichtigste Maßnahme ist eindeutig: Der Symfony Profiler darf auf öffentlich erreichbaren Produktionssystemen nicht aktiv sein.

Für Betreiber und Entwickler empfiehlt sich eine Überprüfung mehrerer Bereiche.

1. Produktionsumgebung korrekt konfigurieren

Die Anwendung sollte im vorgesehenen Produktionsmodus mit deaktiviertem Debugging ausgeführt werden.

Bei klassischen Symfony-Anwendungen sind folgende Einstellungen üblich: APP_ENV=prod

APP_ENV=prod
APP_DEBUG=0

Die tatsächliche Konfiguration sollte überprüft werden. Allein das Setzen dieser Variablen garantiert noch nicht, dass eine fehlerhafte Bereitstellung vollständig behoben ist.

2. Profiler oder Dev Tools rausnehmen

Seit 6.5 wird das Package nicht automatisch mit installiert. Das ist auch sinnvoll. Wenn es in deinem Shop noch vorhanden ist, solltest du es rausnehmen. Auch unter require-dev werden die Packages installiert.

Mit composer show shopware/dev-tools oder composer show symfony/web-profiler-bundle kannst du herausfinden ob die Packages bei dir im Shop installiert sind. 

Wenn du debuggen musst, kannst du die Tools lokal installieren und nutzen.

3. HTTP-Response-Header überprüfen

Untersuchen Sie in Ihren eigenen Anwendungen, ob unerwartete Debug-Header ausgeliefert werden.

Ein einfacher erster Check:

curl -I https://shop.example.com

Relevante Hinweise können beispielsweise diese Header sein:

x-debug-token
x-debug-token-link

Ein fehlender Header ist allerdings kein vollständiger Nachweis dafür, dass sämtliche Debug-Endpunkte deaktiviert sind.

4. Bereits erfolgte Datenoffenlegung untersuchen

Falls der Profiler tatsächlich öffentlich erreichbar war, genügt es nicht, die Funktion einfach zu deaktivieren.

Es muss geprüft werden, ob sensible Informationen offengelegt wurden.

Dazu gehören beispielsweise Zugangs- und API-Schlüssel, Session-Tokens und Zugangsdaten externer Integrationen.

Möglicherweise kompromittierte Credentials sollten widerrufen beziehungsweise rotiert und relevante Zugriffe anhand vorhandener Logs untersucht werden.

Welche Bedeutung hat das für Shopware 6?

Shopware 6 basiert auf Symfony und verwendet zahlreiche Komponenten des Frameworks.

Damit ist das Thema auch für Shopware-Betreiber relevant.

Ein produktiver Shopware-Shop ist jedoch nicht automatisch gefährdet, nur weil Symfony als Framework verwendet wird.

Problematisch wird es insbesondere, wenn Entwicklungs- und Debug-Funktionen durch eine Fehlkonfiguration öffentlich zugänglich werden.

Gerade bei größeren Shops können die Auswirkungen erheblich sein. Über die Shopware-API und zusätzliche Erweiterungen sind möglicherweise ERP-, PIM-, CRM- oder andere Drittsysteme angebunden.

Eine unbeabsichtigte Offenlegung von Integrationszugangsdaten kann deshalb Auswirkungen haben, die weit über den eigentlichen Shop hinausgehen.

Fazit: Ein Debugging-Werkzeug gehört nicht ins öffentliche Internet

Der Symfony Profiler ist ein wertvolles Werkzeug für Entwickler. Bei einem produktiven System mit öffentlich zugänglichen Debug-Funktionen kann daraus jedoch ein erhebliches Sicherheitsrisiko entstehen.

Besonders problematisch ist die Kombination aus gespeicherten HTTP-Requests, möglicherweise sensiblen Integrationsdaten und fehlender Zugriffsbeschränkung.

Mit Werkzeugen wie EOS lässt sich demonstrieren, wie weitreichend die offengelegten Informationen unter ungünstigen Bedingungen sein können.

Der entscheidende Punkt: Es braucht nicht immer eine komplexe Sicherheitslücke im Anwendungscode, um ein System zu gefährden. Manchmal reicht eine einzige falsche Deployment-Konfiguration.

Deshalb sollten Debugging-Konfigurationen Bestandteil jeder technischen Sicherheitsprüfung und jeder produktiven Deployment-Pipeline sein.

Wir haben entsprechende Tools um die Sicherheit unserer Kunden zu sicherzustellen, die das Ganze auch im Nachgang monitoren und melden, sobald etwas nicht stimmt.

Weiterführende Quellen

• https://symfony.com/doc/current/profiler.html
• https://github.com/Synacktiv/eos
• https://github.com/shopware/dev-tools