Validation de point de terminaison avec un schéma CloudEvents

Un Webhook constitue l’un des nombreux moyens de recevoir des événements provenant d’Azure Event Grid. Lorsqu'un nouvel événement est prêt, le service Event Grid POST une requête HTTP au point de terminaison configuré avec les informations d'événement dans le corps de la requête.

Comme de nombreux autres services qui prennent en charge les Webhooks, Event Grid vous demande de prouver que vous êtes propriétaire de votre point de terminaison Webhook avant de démarrer la diffusion d'événements vers ce point de terminaison. Cette condition empêche tout utilisateur malveillant d'inonder votre point de terminaison d'événements.

Validation de point de terminaison avec CloudEvents v1.0

CloudEvents v1.0 implémente sa propre sémantique de protection contre les abus en utilisant la méthode HTTP OPTIONS. Lorsque vous utilisez le schéma CloudEvents pour la sortie, Event Grid l’utilise avec la protection contre les abus CloudEvents v1.0 à la place du mécanisme d’événement de validation Event Grid.

Protection contre les abus CloudEvent v1.0

Tout système qui autorise l’inscription et la remise de notifications à des points de terminaison HTTP arbitraires peuvent potentiellement être abusés, de sorte qu’une personne malveillante ou inadvertance inscrit l’adresse d’un système qui ne s’attend pas à de telles demandes et pour laquelle la partie d’inscription n’est pas autorisée à effectuer une telle inscription. Dans les cas extrêmes, une infrastructure de notification peut être abusée pour lancer des attaques par déni de service contre un site web arbitraire.

Pour protéger l’expéditeur contre l’abus d’une telle façon, une cible de remise légitime doit indiquer qu’elle est d’accord avec les notifications qui lui sont remises.

L’atteinte du contrat de livraison est réalisée à l’aide de l’établissement d'une liaison de validation suivante. L’établissement d’une liaison peut être exécuté immédiatement au moment de l’inscription ou sous la forme d’une requête de « préversion » précédant immédiatement une remise.

Il est important de comprendre que l’établissement d’une liaison ne vise pas à établir un contexte d’authentification ou d’autorisation. Il sert uniquement à protéger l’expéditeur d’être informé d’une transmission vers une destination qui ne s’attend pas au trafic. Bien que cette spécification impose l’utilisation d’un modèle d’autorisation, ce mandat n’est pas suffisant pour protéger tout site web arbitraire contre le trafic indésirable si ce site web n’implémente pas le contrôle d’accès et ignore donc l’en-tête Authorization.

Les cibles de livraison DOIVENT prendre en charge la fonctionnalité de protection contre les abus. Si une cible ne prend pas en charge la fonctionnalité, l’expéditeur PEUT choisir de ne pas envoyer à la cible, du tout ou d’envoyer uniquement à un taux de requêtes très faible.

Requête de validation

La requête de validation utilise la méthode HTTP OPTIONS. La requête est dirigée vers l’URI cible de ressource exact inscrit. Avec la requête de validation, l’expéditeur demande à la cible l’autorisation d’envoyer des notifications et peut déclarer un taux de requête souhaité (demandes par minute). La cible de remise répond avec une instruction d’autorisation et le taux de requête autorisé. Voici quelques champs d’en-tête à inclure dans la requête de validation.

WebHook-Request-Origin

L’en-tête WebHook-Request-Origin DOIT être inclus dans la requête de validation et demande l’autorisation d’envoyer des notifications de cet expéditeur, et contient une expression DNS (Domain Name System) qui identifie le système d’envoi, par exemple eventemitter.example.com. La valeur est destinée à identifier sommairement toutes les instances d’expéditeur qui agissent au nom d’un certain système, et non à un hôte individuel.

Une fois l’établissement d'une liaison accordé et si l’autorisation a été accordée, l’expéditeur DOIT utiliser l’en-tête de demande Origin pour chaque demande de remise, avec la valeur correspondant à celle de cet en-tête.

Exemple :

WebHook-Request-Origin: eventemitter.example.com

Réponse de validation

Si et seulement si la cible de diffusion autorise la diffusion des événements, elle DOIT répondre à la requête en incluant les en-têtes WebHook-Allowed-Origin et WebHook-Allowed-Rate. Si la cible de remise choisit d’accorder l’autorisation par rappel, elle conserve les en-têtes de réponse.

Si la cible de remise n’autorise pas la remise des événements ou ne s’attend pas à recevoir des événements et gère néanmoins la méthode HTTP OPTIONS, la réponse existante ne doit pas être interprétée comme un consentement, et par conséquent, l’établissement d'une liaison ne peut pas compter sur les codes d’état. Si la cible de remise ne gère pas la méthode HTTP OPTIONS, elle DOIT répondre avec le code d’état HTTP 405, comme si OPTIONS n’était pas prise en charge.

La réponse OPTIONS DOIT inclure l’en-tête Allow indiquant que la méthode POST est autorisée. D’autres méthodes PEUVENT être autorisées sur la ressource, mais leur fonction est en dehors de l’étendue de cette spécification.

WebHook-Allowed-Origin

L’en-tête WebHook-Allowed-Origin DOIT être retourné lorsque la cible de remise accepte la remise de notification par le service d’origine. Sa valeur DOIT être le nom d’origine fourni dans l’en-tête WebHook-Request-Origin , ou un caractère astérisque singulier (’*’), indiquant que la cible de remise prend en charge les notifications de toutes les origines.

WebHook-Allowed-Origin: eventemitter.example.com

Or

WebHook-Request-Origin: *

Important

Pour plus d’informations sur la protection contre les abus, consultez protection contre les abus dans http 1.1 Web Hooks pour les spécifications de remise d’événements.

Contenu connexe

Consultez l’article suivant pour savoir comment dépanner les validations d’abonnement aux événements : Dépanner les validations d’abonnement aux événements.