Error-Tracking-Telemetrie beschreibt Ihre Architektur für jeden mit einem Browser

TL;DR: Error Tracking löste ein Engineering-Problem und schuf einen Recon-Kanal: Der Telemetrie-Endpunkt akzeptierte unauthentifizierte Ereignisse, und die Payloads beschrieben meine Drei-Stufen-Architektur. Ich erkläre den Fix an der Edge.

Ausgangslage

Ich habe das Ziel als Black-Box geprüft: keine Zugangsdaten, nur die öffentlich sichtbare Fläche. Das ist, was ich sah, bevor ich etwas angefasst habe.

Ein Plattform- und Infrastrukturanbieter mit einer mehrstufigen Landschaft: äußerer Reverse Proxy, innerer Applikationsserver, zusätzliches Gateway für einen Dienst und ein Komponenten-Frontend. Geprüft wurden Header-Status über alle Stufen, Telemetrie-Freigabe, Fehlerbehandlung und Versionsangabe.

Ich habe alle identifizierenden Informationen entfernt. Das Ziel wird ausschließlich nach Branche und Technologieklasse beschrieben, damit das Muster übertragbar bleibt.

Das Muster

Das Muster, das ich erkannt habe — und das ich in ähnlichen Landschaften immer wieder finde:

Error Tracking löst ein reales Problem und schafft ein spezifisches. Um eine Ausnahme zu melden, braucht der Browser einen Endpunkt und einen Projekt-Schlüssel. Beides steckt im ausgelieferten Bundle, weil das Front End den Fehler sammelt. Dieser Schlüssel ist kein Credential im klassischen Sinn, aber eine Einladung: damit kann jeder Ereignisse einreichen und je nach Konfiguration auch wieder auslesen.

Der Folgeeffekt ist architektonisch. Frontend-Fehler tragen Request-Kontext, und Request-Kontext trägt Hostnamen, interne Kennungen und gelegentlich Sitzungskennungen. Die Telemetrie beschrieb deshalb alle drei Stufen, während die öffentliche Fläche eine beschrieb.

Deshalb gehört Observability in dasselbe Bedrohungsmodell wie Authentifizierung: Infrastruktur, einmal vom Installateur konfiguriert, meist ohne Authentifizierungsanforderung und nie wieder betrachtet.

Befunde

Der Angriffspfad

Reproduktion im Labor

Jeder Befehl unten zielt auf einen Lab-Container, den ich selbst kontrolliere. Nichts davon ist auf ein laufendes System gerichtet.

Telemetrie-Endpunkte in einem eigenen Bundle finden

$ for f in $(curl -s https://example.org/ | grep -oE '/assets/[A-Za-z0-9._-]+\.js' | sort -u); do
    curl -s "https://example.org$f"
  done > /tmp/bundle.txt

$ grep -oiE 'sentry|datadog|bugsnag|newrelic|rollbar|raygun|glitchtip' /tmp/bundle.txt | sort | uniq -c
$ grep -oE 'https://[a-z0-9.-]*(sentry|ingest|observe|collect)[a-z0-9./-]*' /tmp/bundle.txt | sort -u | head
$ grep -oE '[a-f0-9]{32}' /tmp/bundle.txt | sort -u | head

Erkennung in eigener Infrastruktur

Die Stufenstruktur aus den eigenen Error-Payloads lesen

# einen harmlosen Fehler auslösen und prüfen, was Ihre Telemetrie aufzeichnen würde
$ curl -so /dev/null -w '%{http_code}\n' 'https://example.org/api/does-not-exist'

# die Proxy-Kette lesen
$ curl -sI https://example.org/ | grep -iE '^(via|x-powered-by|x-generator|server|x-aspnet|front-end)'

# jeden Host der Kette über den Zertifikatsnamen auflisten
$ echo | openssl s_client -connect example.org:443 -servername example.org 2>/dev/null \
  | openssl x509 -noout -text | grep -i 'subject alternative name' -A1

Behebung

Telemetrie-Eingang an der Edge absichern und Client-Kontext nie vertrauen

# einen Ingestion-Key an der Edge verlangen, nicht nur im SDK
location = /monitoring/client-api/{project}/envelope/ {
    if ($http_x_telemetry_key != "<serverseitig gehaltener Key>") { return 403; }
    proxy_pass http://telemetry-backend;
    proxy_hide_header Set-Cookie;
}

# und die Kette nicht mehr verraten
server_tokens off;
proxy_hide_header X-Powered-By;

Fazit — was ich daraus mitnehme

• Der Exception-Handler ist der Teil einer Anwendung, der am ehesten ein Geheimnis rendert.
• Ein Telemetrie-Projektkey ist eine Einladung, kein ignorierbares Credential.
• Fehlerkontext beschreibt genau die Stufen, die Ihre Proxies verbergen sollten.
• Observability braucht dieselbe Review-Taktung wie Authentifizierung.