Eindpuntvalidatie met CloudEvents-schema
Webhooks zijn een van de vele manieren om gebeurtenissen te ontvangen van Azure Event Grid. Wanneer een nieuwe gebeurtenis gereed is, poseert de Event Grid-service een HTTP-aanvraag naar het geconfigureerde eindpunt met de gebeurtenisgegevens in de aanvraagbody.
Net als veel andere services die webhooks ondersteunen, moet u in Event Grid het eigendom van uw Webhook-eindpunt bewijzen voordat het begint met het leveren van gebeurtenissen aan dat eindpunt. Deze vereiste voorkomt dat een kwaadwillende gebruiker uw eindpunt overspoelt met gebeurtenissen.
Eindpuntvalidatie met CloudEvents v1.0
CloudEvents v1.0 implementeert zijn eigen semantiek voor misbruikbeveiliging met behulp van de METHODE HTTP OPTIONS . Wanneer u het CloudEvents-schema voor uitvoer gebruikt, maakt Event Grid gebruik van cloudevents v1.0 misbruikbeveiliging in plaats van het Event Grid-validatiemechanisme.
Misbruikbeveiliging van CloudEvent v1.0
Elk systeem dat registratie en levering van meldingen aan willekeurige HTTP-eindpunten toestaat, kan mogelijk worden misbruikt, zodat iemand kwaadwillig of onbedoeld het adres registreert van een systeem waarvoor dergelijke aanvragen niet worden verwacht en waarvoor de registrerende partij niet gemachtigd is om een dergelijke registratie uit te voeren. In extreme gevallen kan een meldingsinfrastructuur worden misbruikt om denial-of-service-aanvallen tegen een willekeurige website te starten.
Om de afzender te beschermen tegen misbruik op een dergelijke manier, moet een legitiem leveringsdoel aangeven dat het akkoord gaat met meldingen die aan de afzender worden geleverd.
Het bereiken van de leveringsovereenkomst wordt gerealiseerd met behulp van de volgende validatiehanddruk. De handshake kan direct tijdens de registratie worden uitgevoerd of als een 'voorbereidende' aanvraag direct voorafgaand aan een levering.
Het is belangrijk om te begrijpen dat de handshake niet is bedoeld om een verificatie- of autorisatiecontext tot stand te brengen. Het dient alleen om de afzender te beschermen tegen een push naar een bestemming die het verkeer niet verwacht. Hoewel deze specificatie het gebruik van een autorisatiemodel vereist, is dit mandaat niet voldoende om willekeurige websites te beschermen tegen ongewenst verkeer als die website geen toegangsbeheer implementeert en daarom de Authorization header negeert.
Leveringsdoelen moeten de functie misbruikbeveiliging ondersteunen. Als een doel de functie niet ondersteunt, kan de afzender ervoor kiezen om helemaal niet naar het doel te verzenden of alleen te verzenden met een zeer lage aanvraagsnelheid.
Validatieaanvraag
De validatieaanvraag maakt gebruik van de HTTP OPTIONS-methode . De aanvraag wordt omgeleid naar de exacte resourcedoel-URI die wordt geregistreerd. Met de validatieaanvraag vraagt de afzender het doel om toestemming voor het verzenden van meldingen en kan deze een gewenste aanvraagsnelheid declareren (aanvragen per minuut). Het leveringsdoel reageert met een machtigingsverklaring en het toegestane aanvraagtarief. Hier volgt een aantal koptekstvelden voor opname in de validatieaanvraag.
WebHook-Request-Origin
De WebHook-Request-Origin header moet worden opgenomen in de validatieaanvraag en aanvraagmachtigingen voor het verzenden van meldingen van deze afzender en bevat een DNS-expressie (Domain Name System) die het verzendende systeem identificeert, bijvoorbeeld eventemitter.example.com. De waarde is bedoeld om alle instanties van afzenders die namens een bepaald systeem handelen samen te stellen en niet een afzonderlijke host.
Na de handshake en als er toestemming is verleend, moet de afzender de Origin aanvraagheader gebruiken voor elke leveringsaanvraag, met de waarde die overeenkomt met die van deze header.
Voorbeeld:
WebHook-Request-Origin: eventemitter.example.com
Validatieantwoord
Als en alleen als het leveringsdoel de levering van de gebeurtenissen toestaat, moet het reageren op de aanvraag door de WebHook-Allowed-Origin en WebHook-Allowed-Rate headers op te geven. Als het bezorgingsdoel ervoor kiest om toestemming te verlenen per callback, worden de antwoordheaders niet weergegeven.
Als het leveringsdoel de levering van de gebeurtenissen niet toestaat of geen levering van gebeurtenissen verwacht en toch de HTTP OPTIONS-methode verwerkt, moet het bestaande antwoord niet worden geïnterpreteerd als toestemming en kan de handshake daarom niet vertrouwen op statuscodes. Als het leveringsdoel anders de HTTP OPTIONS-methode niet verwerkt, moet deze reageren met HTTP-statuscode 405, alsof OPTIONS niet worden ondersteund.
Het ANTWOORD OPTIONS moet de Allow header bevatten die aangeeft dat de POST-methode is toegestaan. Andere methoden kunnen worden toegestaan voor de resource, maar hun functie valt buiten het bereik van deze specificatie.
WebHook-Allowed-Origin
De WebHook-Allowed-Origin header MOET worden geretourneerd wanneer het leveringsdoel akkoord gaat met de levering van meldingen door de origin-service. De waarde moet de oorsprongsnaam zijn die wordt opgegeven in de WebHook-Request-Origin koptekst of een enkel sterretje ('*'), waarmee wordt aangegeven dat het leveringsdoel meldingen van alle oorsprongen ondersteunt.
WebHook-Allowed-Origin: eventemitter.example.com
Or
WebHook-Request-Origin: *
Belangrijk
Zie Misbruikbeveiliging in de HTTP 1.1-webhook voor gebeurtenisbezorgingsspecificaties voor meer informatie over de misbruikbeveiliging.
Gerelateerde inhoud
Zie het volgende artikel voor meer informatie over het oplossen van problemen met validaties van gebeurtenisabonnementen: Problemen met validaties van gebeurtenisabonnementen oplossen.