FlawOpen

flawopen.com/SSRF/Cloud-Metadaten und SSRF

Wie kann SSRF Cloud-Metadaten erreichen und wann sind Zugangsdaten gefährdet?

Referenzseite
Einfach erklärt

Stellen Sie sich den Metadatendienst als verschlossenen internen Serviceschalter in einer Cloud-Maschine vor. SSRF kann Ihre Anwendung zum Boten an diesen Schalter machen. Was sie dort abrufen kann, hängt aber von den Anfrageregeln des Anbieters, den Instanzeinstellungen und dem Netzwerkpfad der Anwendung ab. Ein erreichbarer Endpunkt bedeutet nicht automatisch, dass Zugangsdaten offengelegt werden.

Warum der Metadaten-Endpunkt gefährlich sein kann

AWS EC2, Azure und Google Compute Engine dokumentieren Instanzmetadatendienste, die aus unterstützten VM-Umgebungen erreichbar sind. 169.254.169.254 ist eine häufige Link-Local-Adresse, doch Anfrageformate und Kontrollen unterscheiden sich. Metadaten können sensible Instanzdetails enthalten; AWS kann temporäre Rollen-Zugangsdaten bereitstellen, wenn Instanzprofil und Anfragepfad dies zulassen. SSRF wird relevant, wenn Angreifer eine Serveranfrage beeinflussen können, die diesen Dienst erreicht. Erreichbarkeit allein belegt keinen Zugang zu Zugangsdaten: erforderliche Header oder Tokens, HTTP-Methode, Proxy, Netzwerkposition und Instanzkonfiguration spielen eine Rolle.

Wie die Wirkungskette entsteht

Für die Auswirkung müssen mehrere Bedingungen zusammenkommen: Eine Eingabe beeinflusst eine Serveranfrage; diese erreicht den Metadatendienst; der Dienst akzeptiert sie gemäß den Anbieterregeln; und die Antwort gewährt nutzbaren Zugriff. Die mögliche Reichweite hängt von den Rechten der Workload-Identität ab. Unterbrechen Sie die Kette mit festen Zielen, strikten Egress-Kontrollen, Metadatenschutz des Anbieters und Identitäten mit minimalen Rechten.

Häufige Fragen

Verwenden alle Cloud-Anbieter dieselbe Adresse oder dieselbe Zugriffskontrolle?

Nein. Adressen, Header, Methoden, Tokenpflicht und verfügbare Daten unterscheiden sich. AWS IMDSv2 verlangt bei HttpTokens=required ein Sitzungstoken zum Abruf von Metadaten; Azure verlangt den Header Metadata: true; Google dokumentiert Metadata-Flavor: Google. Diese Kontrollen können manche SSRF-Pfade erschweren, ersetzen aber weder das Verhindern benutzergesteuerter Ziele noch das Sperren unnötiger ausgehender Verbindungen. Prüfen Sie die genaue VM- und Containerkonfiguration in der Anbieterdokumentation.

Quellen und ergänzende Analysen

Siehe auch Serverseitige Anfragefälschung (SSRF, CWE-918): Funktionsweise und Schutz in jeder Sprache — flawopen.com KI-PR-Bots: SSRF-Schutz — flawopen.com Node.js fetch() und SSRF: URLs sicher abrufen