Wie aus einer Callback-URL ein SSRF-Angriff wird

Ein Webhook-Absender ruft eine URL ab, die jemand anderes ausgesucht hat. Mehr steckt hinter Server-Side Request Forgery nicht, und eine Zahlungsplattform baut genau das mit Absicht ein, weil das System eines Händlers über einen Callback erfährt, dass eine Rechnung bezahlt ist.

Zum Angriff wird die Sache durch den Startpunkt der Anfrage. Die Zustellung läuft innerhalb der Netzgrenze des Absenders, auf einem Host mit einer Routingtabelle und einer Absenderadresse, die kein Browser im öffentlichen Internet hat. Jemand trägt ein Ziel ein, und die Plattform stellt für ihn die Verbindung dorthin her, nach Zeitplan und mit Wiederholungen.

Aufhalten lässt sich das nur durch eine Prüfung auf der aufgelösten Adresse. Sie läuft, bevor der Socket aufgeht, und sie muss überstehen, dass nach der Freigabe jemand das Ziel verschiebt. Der Rest dieses Textes handelt davon, wo diese Prüfung stehen kann und was sie den Händler am anderen Ende kostet.

Was ist Webhook-SSRF?

Die Fehlerklasse, bei der ein Angreifer das Ziel einer Anfrage bestimmt, die Ihr Server stellt — und zwar über das eine Eingabefeld, das dafür gebaut wurde.

Die bekannten SSRF-Funde sind die, die niemand bauen wollte. Ein PDF-Renderer folgt einer Bild-URL, ein Avatar-Import holt eine Datei im Auftrag des Nutzers. Hinterher liest sich das wie ein Versehen. Ein Webhook-Absender ist der beabsichtigte Fall: Das Feld ist dokumentiert, und der Worker, der die URL abruft, hat keine andere Aufgabe.

OWASP hat die Kategorie 2025 verschoben. In der Liste von 2021 hatte SSRF mit A10 einen eigenen Platz; in der Top 10 von 2025 gibt es diese Überschrift nicht mehr, und CWE-918 steht unter den bemerkenswerten Schwächen von A01, Broken Access Control.

Die neue Einordnung beschreibt den Schaden besser als der alte Name. Die Anfrage ist echt. Ihre Infrastruktur hat sie gestellt, und was sie erreicht, ist erreichbar, weil sie von dort kam.

Warum zählt die Netzwerkposition mehr als die Antwort?

Weil die Antwort den Angreifer meistens gar nicht erreicht und der Angriff trotzdem funktioniert.

Ein Zustell-Worker liest einen Statuscode und wirft den Rumpf weg. In ein Dashboard gespiegelt wird nichts davon, also erfährt der, der die URL eingetragen hat, pro Versuch ein einziges Bit: Die Verbindung kam zustande, oder sie kam nicht zustande. Das ist die blinde Variante, und wer SSRF für ein Datenleck hält, unterschätzt sie deshalb. Ein Bit, oft genug wiederholt, ergibt eine Karte des Netzes.

Der eigentliche Wert ist die Position. Innerhalb der Netzgrenze erreicht der Worker Hosts, die nie dafür gebaut wurden, jemandem von außen zu antworten. Viele davon stammen aus einer Zeit, in der das interne Netz die Authentifizierung war. Außerhalb steht die Ausgangsadresse der Plattform nicht selten auf einer Freigabeliste bei einem Partner, der Verkehr von Ihnen annimmt und sonst von niemandem.

Gefährlicher als einen PDF-Renderer macht eine Zahlungsplattform hier ihre Wiederholungsleiter. Wer nach einem Plan wiederholt, macht aus einer einzigen Eintragung einen Job, der immer wieder losläuft, auf Infrastruktur, die jemand anderes am Laufen hält.

Wo muss die Prüfung stehen?

Nach dem Auflösen des Namens und vor dem Öffnen der Verbindung, und das ist in den meisten HTTP-Bibliotheken eine unbequeme Stelle.

Der Filter auf dem rohen Text entsteht zuerst, weil er der einzige ist, den man schreiben kann, ohne den Request-Handler zu verlassen. Er scheitert aus einem strukturellen Grund: Ein Hostname ist ein Verweis, und worauf er verweist, entscheidet ein DNS-Eintrag, der demjenigen gehören kann, der die URL einträgt. Aus dem Text folgt nichts darüber, wohin das Paket geht. Die Präventionsleitlinie von OWASP sagt deshalb, die Anwendung müsse die Adressen hinter dem Namen holen, A und AAAA, und die Adressregeln auf das anwenden, was zurückkommt.

Genau diese Unbequemlichkeit erklärt, warum die naive Fassung immer wieder ausgeliefert wird. Eine Client-Bibliothek nimmt eine URL entgegen und gibt eine Antwort zurück, während der Haken, den Sie brauchen, zwischen zwei Schritten sitzt, die sie für ihre eigene Angelegenheit hält. Dort hinzukommen heißt, den Namen selbst aufzulösen oder sich in den Socket zu hängen, und beides ist mehr Arbeit als ein regulärer Ausdruck auf einem Formularfeld.

Welche Adressbereiche muss sie abweisen?

Mehr, als die meisten aus dem Kopf aufschreiben.

Loopback und die privaten Blöcke aus RFC 1918 sind die naheliegenden Einträge. Link-Local gehört dazu, denn dort antworten die Metadatendienste der Cloud-Anbieter, und wer dort ankommt, bekommt Zugangsdaten.

Zwei Einträge fehlen fast immer, und beide sind jünger als das Modell, aus dem die Liste kommt.

Der Shared Address Space, 100.64.0.0/10, wurde im April 2012 mit RFC 6598 für Carrier-Grade NAT reserviert, und der RFC hält ausdrücklich fest, dass er sich von RFC-1918-Adressraum unterscheidet, weil er für Providernetze gedacht ist.

Ein Filter, der auf 10. und 192.168. prüft, hat dazu keine Meinung und verpasst nebenbei die Hälfte von RFC 1918.

Die Unique Local Addresses, fc00::/7, stammen aus RFC 4193, und der beschreibt sie als im globalen Internet nicht routbar, innerhalb eines Standorts dagegen schon.

An ein Ziel, auf das diese Beschreibung passt, gehört kein Webhook, und eine Bereichsliste, die nur für IPv4 geschrieben wurde, erwähnt sie überhaupt nicht.

Bei Paymos deckt die Sperrliste alle diese Bereiche ab; die Tabelle am Ende führt sie einzeln auf, samt der drei Dokumentationsbereiche und 0.0.0.0/8. Eine IPv4-Adresse in IPv6-Schreibweise rutscht dabei nicht durch, weil die Adresse vor jedem Bereichstest normalisiert wird. Das ist der klassische Umgehungsversuch, und er läuft ins Leere.

Was schließt das Fenster zwischen Prüfung und Verbindung?

Zwei Mechanismen halten das Ziel fest, damit es sich nach der Freigabe nicht mehr bewegt.

Der erste betrifft die Weiterleitung. Der Worker löst einen Namen auf, bekommt eine öffentliche Adresse, gibt sie frei und öffnet die Verbindung. Der Server antwortet mit 302 und einer neuen Adresse. Folgt der HTTP-Client Weiterleitungen, wurde die zweite Anfrage nie geprüft, denn die Prüfung war ein Ereignis im Leben der ersten. Und von sich aus folgt er ihnen: HttpClient in .NET tut das ebenso wie requests in Python, solange man es nicht abschaltet.

Das Cheat Sheet erledigt diesen Punkt in einem Halbsatz: Weiterleitungen im verwendeten Client abschalten.

Grob, und richtig. Ein Endpunkt, der Callbacks entgegennimmt, hat keinen Grund, sie an eine zweite Adresse weiterzureichen, und wer seinen Endpunkt umgezogen hat, trägt die neue URL ein.

Der zweite ist leiser. Auch ohne Weiterleitung liegt zwischen der Prüfung und der Verbindung eine DNS-Antwort mit einer Gültigkeitsdauer, und freigegeben haben Sie die Antwort, die Sie gesehen haben. Bei Paymos löst der Zustell-Client den Host genau einmal auf, nimmt die erste Adresse, die besteht, und öffnet den Socket direkt auf diese Adresse. Zwischen Prüfung und Verbindung liegt keine zweite Namensauflösung, und damit bleibt für DNS-Rebinding kein Fenster offen. Automatischen Weiterleitungen folgt derselbe Client nie.

Was passiert, wenn ein Ziel abgelehnt wird?

Nichts, was Kapazität kostet. Darin liegt die zweite Hälfte der Abwehr.

Den ersten Teil trägt die Reihenfolge: Ein Ziel, das die Prüfung nicht besteht, wird abgelehnt, bevor der Worker eine Verbindung öffnet. Eine gesperrte Eintragung kostet den Absender also keine einzige ausgehende Verbindung.

Der zweite Teil sind die Grenzen, und die überliest man leicht, weil sie wie Betriebsthemen aussehen. Gebaut wurden sie bei Paymos für die Zuverlässigkeit der Zustellung, und sie begrenzen diesen Fall mit:

• Zehn Sekunden je Versuch. Ohne Frist bindet ein Ziel, das den Handshake beantwortet und danach schweigt, einen Worker so lange, bis an anderer Stelle etwas nachgibt.
• Elf Versuche schließen ein Ereignis ab: der erste plus zehn Wiederholungen, mit Abständen von einer Minute bis zu acht Stunden, insgesamt rund 16 Stunden. Ohne Obergrenze bekäme ein gewähltes Ziel eine Verkehrsquelle, die sich selbst nachlädt.
• Zehn Endpunkte je Händlerumgebung. Diese Grenze steht zwischen einem einzelnen Konto und einem unbegrenzten Anteil an der ausgehenden Kapazität.

Die Versuche begrenzen das Ereignis und nie den Endpunkt. Läuft ein Zyklus aus, gilt das Ereignis als fehlgeschlagen, die Eintragung bleibt bestehen, und ein Empfänger, der einen Tag lang weg war, findet Ereignisse vor, die sich nachsenden lassen. Wie ein Empfänger die Wiederholungen verarbeitet, ohne eine Bestellung zweimal auszuliefern, steht in der Erklärung zur Webhook-Idempotenz.

Was kostet die Abwehr den Händler?

Echte Endpunkte stolpern darüber, und der Ausfall sieht aus wie eine Störung statt wie eine Schutzmaßnahme.

Ein Callback kann nicht auf localhost und nicht auf eine Maschine im Büronetz zeigen. Die lokale Entwicklung braucht also einen Tunnel, der einen öffentlichen Namen vor den Handler stellt; das trifft jede Anbindung am ersten Nachmittag. Ebenso muss die eingetragene URL HTTPS sein. Eine http://-Adresse wird schon beim Anlegen abgewiesen und nicht erst beim Zustellen.

Weil keiner Weiterleitung gefolgt wird, muss die eingetragene URL die endgültige sein. Ein Host, der seit dem Domainwechsel auf jeden Aufruf mit 301 antwortet, oder ein Pfad, der vor einem Jahr umgezogen ist und seither weiterleitet, scheitert bei der Zustellung, während derselbe Aufruf im Browser eine gesunde Seite zeigt. Linkverkürzer und Tracking-Wrapper vor einem Callback sind derselbe Fall im anderen Gewand.

Am unauffälligsten ist ein DNS-Eintrag auf die falsche Adresse. Trägt der A-Record die Adresse, die der Router auf der Innenseite zeigt, statt derjenigen, die von außen erreichbar ist, landet das Ziel in einem gesperrten Bereich, und es geht nichts mehr hinaus. Keiner dieser Fälle meldet sich von selbst: Der Händler sieht keine Callbacks und öffnet ein Ticket, weil keine Webhooks ankommen; der erste Verdacht fällt dann auf den Handler, und die Antwort liegt in der eingetragenen URL.

Was sollten Sie einen Zahlungsanbieter dazu fragen?

Fragen Sie, wo die Prüfung läuft. Jede weitere Antwort ergibt sich daraus.

Wer auf der aufgelösten Adresse prüft, sagt das ungefragt und nennt die Bereiche. Loopback und RFC 1918 sind die leichte Hälfte; eine Antwort, die bis zum Shared Address Space und zu den Unique Local Addresses reicht, kommt von jemandem, der aktuelle RFCs gelesen hat statt eine alte Checkliste abzuschreiben. Fragen Sie, ob automatischen Weiterleitungen gefolgt wird. Fragen Sie, wie oft der Name zwischen Prüfung und Verbindung aufgelöst wird. Und fragen Sie, was ein abgelehntes Ziel mit der Zustellkapazität aller anderen Händler macht.

Lesen Sie dann die Sicherheitsseite und prüfen Sie, ob sie dort aufhört, wo die Technik aufhört. Eine Seite, die eine Abwehr breiter beschreibt als die Komponente, die sie durchsetzt, ist ein anderes Risiko als das, um das es hier geht. Dieses zweite können Sie von außen prüfen, ohne Zugriff auf eine einzige Zeile Code.

Bauen Sie selbst den Absender, liegt die eigentliche Schwierigkeit woanders: Die Prüfung schweigt, solange sie funktioniert, und sieht wie ein Fehler aus, sobald sie greift. Bauen Sie die Ablehnung deshalb so, dass sie die Regel benennt, an der sie hängen geblieben ist, und sagen Sie das dem Händler in der API-Antwort statt nur dem eigenen Log.