Server-Side Request Forgery (SSRF)

Was ist Server-Side Request Forgery (SSRF)?

Die Anwendung ruft eine vom Nutzer angegebene URL ab, ohne das Ziel zu prüfen. Die Anfrage kommt aus Ihrem eigenen Netzwerk; der Angreifer nutzt damit die Netzwerkposition des Servers. Sie richten eine Link-Vorschaufunktion auf den Cloud-Metadaten-Dienst unter seiner festen Link-Local-Adresse, lesen die Zugangsdaten der zugewiesenen Instanzrolle aus und listen damit einen Speicher voller Kundenrechnungen auf. Anschließend lösen Sie den Host auf, lehnen private, Loopback- und Link-Local-Adressen ab und prüfen das Ziel nach jeder Weiterleitung erneut. Token-pflichtige Metadaten (IMDSv2) und auf minimale Rechte beschränkte Rollen ergänzen den Schutz.

Was Sie lernen in Server-Side Request Forgery (SSRF)

• Server-Side Request Forgery erklären: Ruft eine Anwendung eine vom Nutzer angegebene URL ab, kann ein Angreifer den Server Systeme erreichen lassen, die er selbst nicht direkt erreicht
• Den Cloud-Metadaten-Service unter 169.254.169.254 als Zugangsdaten ausgebenden Endpunkt erkennen, den SSRF erreichen kann, ein externer Angreifer jedoch nicht
• Nachvollziehen, wie eine harmlose Link-Vorschaufunktion zu einer vollständigen Kette aus Diebstahl von Zugangsdaten und Datenabfluss wird, wenn das Abrufziel nie geprüft wird
• Zielprüfung (Host auflösen, private und Link-Local-Bereiche verweigern, nach Weiterleitungen erneut prüfen) von fragilen Zeichenfolgen-Denylists unterscheiden und erklären, warum nur Erstere wirksam ist
• Die Code-Behebung mit Defense in Depth ergänzen: Token-pflichtige Instanz-Metadaten (IMDSv2), Instanzrollen mit minimalen Berechtigungen und Warnungen, wenn ein Abruf-Worker auf sensiblen Speicher zugreift

Server-Side Request Forgery (SSRF) — Trainingsschritte

1. Die Vorschaufunktion

   Bei Corveil kann jeder einen Link einfügen und eine übersichtliche Vorschaukarte mit Seitentitel und Bild erhalten, die sich in eine Nachricht übernehmen lässt. Die Vorschau entsteht nicht im Browser: Corveils Server rufen den Link selbst ab. Bob öffnet die Funktion, um ihr Verhalten zu prüfen.

2. Woher die Anfrage stammt

   Ein Detail auf dieser Seite erklärt, warum Bob sich für die Funktion interessiert.

3. Die Funktion verwenden

   Beobachten Sie die Funktion im Normalbetrieb. Fügen Sie einen gewöhnlichen Nachrichtenartikel ein und erzeugen Sie eine Vorschau, damit die Seite eine echte Anfrage stellt, die Bob prüfen kann.

4. Den Endpunkt finden

   Die Anfrage wurde gesendet und der Browser hat sie aufgezeichnet. Öffnen Sie den Netzwerkbereich und prüfen Sie, wohin die Seite sie tatsächlich gesendet hat.

5. Nach innen richten

   Bob stellt die Anfrage im API-Tester nach, damit er den Parameter url auf ein beliebiges Ziel setzen kann. Der Server ruft jede von ihm angegebene Adresse ab – auch solche, die Bob selbst nie erreichen könnte. Jeder Cloud-Server hat unter einer festen internen Adresse einen Metadaten-Dienst, der die Zugangsdaten seiner zugewiesenen Rolle ausgibt. Er ist für die Nutzung durch den Server selbst vorgesehen. Bei AWS beantwortet er, solange das ältere IMDSv1 ohne Token noch erlaubt ist, wie es bei Corveils Worker der Fall ist, eine einfache GET-Anfrage, ohne zu prüfen, wer fragt. Bob muss Corveils Vorschau-Worker nur dazu bringen, den Dienst für ihn aufzurufen.

6. Den Metadaten-Service erreichen

   Stellen Sie die Vorschauanfrage im API-Tester nach, richten Sie url aber statt auf einen Nachrichtenartikel auf den Pfad für Metadaten-Zugangsdaten. Corveils Worker ruft ihn aus dem Netzwerk heraus ab und gibt die Antwort zurück.

7. Zugangsdaten erbeutet

   Die Antwort ist keine Vorschau, sondern ein Satz aktiver Zugangsdaten für die Cloud-Rolle des Vorschau-Workers.

8. Eine Anfrage mit dem gestohlenen Schlüssel signieren

   Corveils interner Speicher vertraut signierten Anfragen. Bob signiert eine mit der AccessKeyId , die er gerade vom Metadaten-Dienst erhalten hat, und listet den Bucket mit Kundenrechnungen auf – ein Ziel, das ein externer Nutzer normalerweise nicht erreichen kann.

9. Die Daten sind abgeflossen

   Namen, Beträge und Rechnungs-IDs aus über vierzigtausend Kundendatensätzen — abgerufen über eine Funktion, die nur einen Link vorschauen sollte.

10. Wissenscheck