Kannst du diesem Webhook vertrauen? Eine Prüfliste für selbst gehostete Anwendungen

Lege fest, was du über den Webhook wissen musst

Ein eingehender Webhook verbindet einen externen Dienst mit einer Anwendung. Vor der Aktivierung solltest du nachvollziehen können, wer Anfragen senden soll, welche Ereignisse angenommen werden und welche Aktionen daraus folgen. Prüfe dafür die offiziellen Unterlagen des Anbieters und der Anwendung sowie die Konfiguration deiner eingesetzten Version.

Trenne belegte Antworten von Annahmen. Eine Aussage in einer allgemeinen Produktbeschreibung belegt nicht automatisch das Verhalten eines bestimmten Endpunkts. Wenn sich ein wichtiger Punkt weder in Primärquellen noch in der Konfiguration bestätigen lässt, notiere ihn als offen.

• Absender und Endpunkt: Welcher Dienst sendet an welche Anwendungsinstanz und Umgebung?
• Ereignisse und Daten: Welche Ereignistypen und Felder sind vorgesehen?
• Folgen: Welche Änderungen oder nachgelagerten Aktionen löst jedes Ereignis aus?
• Zuständigkeit: Welche Komponente prüft die Anfrage und wer kann diese Konfiguration ändern?

Bewerte Absenderprüfung und Ereignisumfang

Suche in der Dokumentation des externen Dienstes und der Anwendung nach einer konkreten Beschreibung, wie eingehende Anfragen dem vorgesehenen Absender zugeordnet werden. Halte fest, welche Daten oder Merkmale geprüft werden und was bei fehlenden oder ungültigen Angaben geschieht. Eine schwer zu erratende URL allein ist kein Nachweis einer Absenderprüfung.

Prüfe daneben, welche Ereignisse und Payloads die Integration annimmt und wie die Anwendung unerwartete oder fehlerhafte Eingaben behandelt. Absenderprüfung und Prüfung des Ereignisinhalts sind unterschiedliche Fragen. Behaupte keine dieser Funktionen, wenn sie für die eingesetzte Version und Konfiguration nicht belegt ist.

• Ist ein Verfahren zur Absenderprüfung dokumentiert, und ist es in der tatsächlichen Konfiguration aktiviert?
• Welche Ereignistypen sind zugelassen, und wie werden Änderungen an diesem Umfang nachvollzogen?
• Welche Felder und Formate erwartet die Integration? Gibt es dokumentierte Grenzen für die Anfragegröße?
• Wie wird geprüft, dass Kennungen oder referenzierte Daten zum erwarteten Konto, Arbeitsbereich oder Mandanten gehören?
• Kannst du nicht feststellen, wie Absender oder Eingaben geprüft werden, kennzeichne das als offene Sicherheitsfrage.

Prüfe Wiederholungen und mögliche Auswirkungen

Ermittle, ob der Absender Zeitstempel, Ereigniskennungen oder Informationen zu Wiederholungsversuchen bereitstellt. Stelle getrennt davon fest, ob der Empfänger diese verarbeitet. Ein erfolgreicher Absendercheck beantwortet nicht, wie doppelte oder verspätete Anfragen behandelt werden.

Verfolge jedes angenommene Ereignis bis zu seiner Wirkung: Welche Berechtigungen nutzt die Integration, auf welche Daten kann sie zugreifen und welche Aktionen löst sie aus? Beurteile besonders, was passieren könnte, wenn eine Anfrage unerwartet oder mehrfach verarbeitet wird.

• Wie beschreibt die Dokumentation den Umgang mit verzögerter Zustellung und wiederholten Anfragen?
• Werden bereitgestellte Zeitstempel oder Ereigniskennungen vom Empfänger tatsächlich ausgewertet?
• Welche Berechtigungen und Datenzugriffe hat die Integration laut Konfiguration?
• Welche Aktion ist jedem zugelassenen Ereignis zugeordnet, und welche Folgen hätte eine falsche Zuordnung?
• Wenn die Behandlung von Wiederholungen oder die Begrenzung von Berechtigungen ungeklärt bleibt, bewerte die Aktivierung anhand der möglichen Auswirkungen.

Schütze Zugangsdaten und prüfe Protokolle

Ermittle, wo gemeinsam verwendete Geheimnisse, Signaturschlüssel oder andere Integrationszugangsdaten abgelegt sind und wer darauf zugreifen kann. Vor einem Austausch solltest du das für die konkrete Integration dokumentierte Verfahren kennen. Leite nicht ab, dass ein bestimmter Rotationsablauf verfügbar ist, wenn er nicht belegt ist.

Untersuche außerdem, welche Anfragebestandteile in Anwendungs-, Proxy- oder Integrationsprotokollen erscheinen können. Prüfe tatsächliche Einstellungen und verfügbare Protokolle statt von Standardverhalten auszugehen. Berücksichtige Zugriffsrechte, Aufbewahrung und mögliche Kopien in Exporten oder Sicherungen.

• Welche Personen und Systeme können die verwendeten Geheimnisse einsehen oder ändern?
• Wie werden Zugangsdaten laut Dokumentation ersetzt und der Wechsel überprüft?
• Können Protokolle Header mit Geheimnissen, vollständige Payloads oder sensible Anfragewerte enthalten?
• Wer kann Protokolle einsehen, und welche Aufbewahrungs- und Löschregeln gelten?
• Falls diese Punkte nicht feststellbar sind, behandle sie als offene Fragen und vermeide, nicht geprüfte Inhalte als unbedenklich einzustufen.

Ordne Zuständigkeiten zu und entscheide über die Freigabe

Erstelle für die geprüften Kontrollen eine einfache Zuständigkeitstabelle: Anwendung, externer Anbieter, Proxy, Integrationsschicht oder Administration. Notiere für jede Funktion, wo sie dokumentiert ist und wer sie ändern oder überprüfen kann. Die konkrete Aufteilung hängt von deiner Anwendung und Bereitstellung ab.

Als praktische Freigabehilfe: Aktiviere den Endpunkt erst, wenn du die vorgesehene Absenderprüfung, den Ereignisumfang, die möglichen Folgen und die Zuständigkeit für offene Punkte nachvollziehen kannst. Fehlt für eine wesentliche Kontrolle ein Nachweis, lasse sie nicht als vorhanden gelten. Kläre die Lücke, begrenze die Integration soweit belegbar oder verzichte auf den Webhook, bis die Risiken angemessen beurteilt sind.

Zu den ausdrücklich genannten Hosting-Funktionen von Airbip gehören der Betrieb von Anwendungsinstanzen als Docker-Workloads auf Airbip-Cloudservern sowie die Automatisierung von Routing und TLS-Zertifikaten über Traefik und Let's Encrypt. Diese Angaben belegen nicht, welche Prüfungen ein bestimmter Webhook-Endpunkt auf Anwendungsebene vornimmt.

• Wer ist für Absenderprüfung, Anwendungslogik, externe Erreichbarkeit und Geheimnisse jeweils zuständig?
• Welche Komponente weist eine Anfrage zurück, wenn eine dokumentierte Prüfung fehlschlägt?
• Wer darf Endpunkt, Zugangsdaten, Ereignisumfang und nachgelagerte Aktionen ändern?
• Welche Punkte bleiben ungeklärt, und wer entscheidet, ob die Integration bis zur Klärung deaktiviert bleibt?

Primärquellen und Grenzen der Prüfliste

Nutze offizielle Dokumentation als Ausgangspunkt und prüfe anschließend die Unterlagen der konkreten Anwendung und des Webhook-Anbieters. Die folgenden Links führen zu offiziellen Dokumentations- oder Referenzseiten. Sie sind keine Bestätigung, dass eine bestimmte Anwendung die hier genannten Kontrollen unterstützt oder aktiviert hat.

Für eine Aussage über einen konkreten Endpunkt brauchst du Belege, die zu dessen Anwendung, Version und Konfiguration passen. Fehlen solche Belege, bleibt die Aussage ungeklärt.

• OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/
• Docker-Dokumentation: https://docs.docker.com/
• Traefik-Dokumentation: https://doc.traefik.io/traefik/
• Let's Encrypt-Dokumentation: https://letsencrypt.org/docs/
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework