Endpunktüberprüfung mit dem CloudEvents 1.0-Schema

Ein Webhook ist eine der vielen Möglichkeiten, um Ereignisse aus Azure Event Grid zu empfangen. Wenn ein neues Ereignis bereit ist, sendet der Event Grid-Dienst per POST-Vorgang eine HTTP-Anforderung an den konfigurierten Endpunkt, wobei die Ereignisinformationen im Anforderungstext enthalten sind.

Wie viele andere Dienste, die Webhooks unterstützen, müssen Sie bei Event Grid nachweisen, das Sie im Besitz Ihres Webhookendpunkts sind. Vorher wird mit dem Bereitstellen von Ereignissen für diesen Endpunkt nicht begonnen. Diese Anforderung verhindert, dass ein böswilliger Benutzer Ihren Endpunkt mit Ereignissen überschwemmt.

Endpunktüberprüfung mit CloudEvents 1.0

CloudEvents 1.0 implementiert eine eigene Semantik für den Schutz vor Missbrauch über die HTTP OPTIONS-Methode. Wenn Sie das CloudEvents-Schema für die Ausgabe nutzen, verwendet Event Grid anstelle des Event Grid-Mechanismus für Überprüfungsereignisse den Missbrauchschutz von CloudEvents v1.0.

CloudEvent v1.0-Missbrauchsschutz

Jedes System, das die Registrierung und Übermittlung von Benachrichtigungen an beliebige HTTP-Endpunkte zulässt, kann potenziell missbraucht werden, indem jemand böswillig oder versehentlich die Adresse eines Systems registriert, das solche Anforderungen nicht erwartet und für das die registrierende Seite keine Berechtigung hat, eine solche Registrierung durchzuführen. In extremen Fällen könnte eine Benachrichtigungsinfrastruktur missbraucht werden, um Denial-of-Service-Angriffe auf eine beliebige Website zu starten.

Um den Absender vor einem derartigen Missbrauch zu schützen, muss ein legitimes Übermittlungsziel angeben, dass es mit der Übermittlung von Benachrichtigungen einverstanden ist.

Die Vereinbarung zur Übermittlung wird mithilfe des folgenden Validierungshandshakes getroffen. Der Handshake kann entweder unmittelbar zur Registrierungszeit oder als „Preflightanforderung“ unmittelbar vor einer Übermittlung ausgeführt werden.

Es ist wichtig zu verstehen, dass der Handshake nicht darauf abzielt, einen Authentifizierungs- oder Autorisierungskontext einzurichten. Er dient nur dazu, den Absender vor einem Push an ein Ziel zu schützen, das den Datenverkehr nicht erwartet. Auch wenn diese Spezifikation die Verwendung eines Autorisierungsmodells vorschreibt, reicht dieses Mandat nicht aus, um beliebige Websites vor unerwünschtem Datenverkehr zu schützen, wenn diese Website keine Zugriffssteuerung implementiert und daher den Authorization-Header ignoriert.

Übermittlungsziele SOLLTEN die Missbrauchsschutzfunktion unterstützen. Wenn ein Ziel das Feature nicht unterstützt, KANN sich der Absender entscheiden, überhaupt nicht oder nur mit einer sehr niedrigen Anforderungsrate an das Ziel zu senden.

Überprüfungsanforderung

Die Überprüfungsanforderung verwendet die HTTP OPTIONS-Methode. Die Anforderung wird an genau den Ressourcenziel-URI weitergeleitet, der registriert wird. Mithilfe der Überprüfungsanforderung bittet der Absender das Ziel um Erlaubnis, Benachrichtigungen zu senden, und kann dabei eine gewünschte Anforderungsrate (Anforderungen pro Minute) deklarieren. Das Übermittlungsziel antwortet mit einer Berechtigungserklärung und der zulässigen Anforderungsrate. Im Folgenden finden Sie einige der Headerfelder, die in die Validierungsanforderung aufgenommen werden.

WebHook-Request-Origin

Der WebHook-Request-Origin-Header MUSS Bestandteil der Überprüfungsanforderung sein. Er fordert die Berechtigung zum Senden von Benachrichtigungen bei diesem Absender an und enthält einen DNS-Ausdruck (Domain Name System), der das sendende System identifiziert, z. B. eventemitter.example.com. Der Wert dient dazu, alle Absenderinstanzen, die im Namen eines bestimmten Systems handeln zu identifizieren, nicht einen einzelnen Host.

Nach dem Handshake und sofern die Berechtigung erteilt wurde, MUSS der Absender den Origin-Anforderungsheader für jede Übermittlungsanforderung verwenden, wobei der Wert dem dieses Headers entspricht.

Beispiel:

WebHook-Request-Origin: eventemitter.example.com

Überprüfungsantwort

Wenn und nur wenn das Übermittlungsziel die Übermittlung der Ereignisse gestattet, MUSS es auf die Anforderung antworten, indem es die WebHook-Allowed-Origin- und WebHook-Allowed-Rate-Header mit einschließt. Wenn das Übermittlungsziel die Berechtigung per Rückruf erteilt, behält es die Antwortheader zurück.

Wenn das Übermittlungsziel die Übermittlung der Ereignisse nicht zulässt oder die Übermittlung von Ereignissen nicht erwartet und die HTTP-OPTIONS-Methode dennoch verarbeitet, sollte die vorhandene Antwort nicht als Zustimmung interpretiert werden, und der Handshake kann folglich nicht auf Statuscodes vertrauen. Wenn das Übermittlungsziel andernfalls die HTTP-OPTIONS-Methode nicht verarbeitet, SOLLTE es mit dem HTTP-Statuscode 405 reagieren, d. h. als ob OPTIONS nicht unterstützt wurden.

Die OPTIONS-Antwort SOLLTE den Allow-Header enthalten, wodurch angegeben wird, dass die POST-Methode zulässig ist. Andere Methoden sind MÖGLICHERWEISE für die Ressource zulässig, ihre Funktionen sind jedoch nicht Bestandteil dieser Spezifikation.

WebHook-Allowed-Origin

Der WebHook-Allowed-Origin-Header MUSS zurückgegeben werden, wenn das Übermittlungsziel einer Benachrichtigungsübermittlung durch den Ursprungsdienst zustimmt. Der Wert MUSS entweder der Ursprungsname, der im WebHook-Request-Origin-Header angegeben wird, oder ein einzelnes Sternchen („*“) sein, das angibt, dass das Übermittlungsziel Benachrichtigungen jeglichen Ursprungs unterstützt.

WebHook-Allowed-Origin: eventemitter.example.com

Oder

WebHook-Request-Origin: *

Zugehöriger Inhalt

Im folgenden Artikel finden Sie Informationen zur Behandlung von Problemen bei der Überprüfung von Ereignisabonnements: Problembehandlung bei der Abonnementüberprüfung für Azure Event Grid.