Walidacja punktu końcowego przy użyciu schematu CloudEvents

Elementy webhook są jednym z wielu sposobów odbierania zdarzeń z usługi Azure Event Grid. Gdy nowe zdarzenie jest gotowe, usługa Event Grid poSTs żądanie HTTP do skonfigurowanego punktu końcowego z informacjami o zdarzeniu w treści żądania.

Podobnie jak wiele innych usług obsługujących elementy webhook, usługa Event Grid wymaga potwierdzenia własności punktu końcowego elementu webhook przed rozpoczęciem dostarczania zdarzeń do tego punktu końcowego. To wymaganie uniemożliwia złośliwemu użytkownikowi zalanie punktu końcowego zdarzeniami.

Walidacja punktu końcowego za pomocą rozwiązania CloudEvents w wersji 1.0

Rozwiązanie CloudEvents w wersji 1.0 implementuje własną semantyka ochrony przed nadużyciami przy użyciu metody HTTP OPTIONS . W przypadku używania schematu CloudEvents dla danych wyjściowych usługa Event Grid używa ochrony przed nadużyciami cloudEvents w wersji 1.0 zamiast mechanizmu zdarzeń weryfikacji usługi Event Grid.

Ochrona przed nadużyciami w usłudze CloudEvent w wersji 1.0

Każdy system, który umożliwia rejestrację i dostarczanie powiadomień do dowolnych punktów końcowych HTTP, może być potencjalnie nadużywany, tak aby ktoś złośliwie lub przypadkowo zarejestrował adres systemu, który nie oczekuje takich żądań i dla którego strona rejestru nie jest upoważniona do przeprowadzenia takiej rejestracji. W skrajnych przypadkach infrastruktura powiadomień może być nadużywana w celu uruchomienia ataków typu "odmowa usługi" na dowolną witrynę internetową.

Aby chronić nadawcę przed nadużyciami w taki sposób, legalny cel dostawy musi wskazywać, że zgadza się z dostarczeniem do niego powiadomień.

Osiągnięcie umowy dostawy jest realizowane przy użyciu następującego uzgadniania weryfikacji. Uzgadnianie można wykonać natychmiast w czasie rejestracji lub jako żądanie "wstępne" bezpośrednio przed dostarczeniem.

Ważne jest, aby zrozumieć, że uzgadnianie nie ma na celu ustanowienia kontekstu uwierzytelniania ani autoryzacji. Służy tylko do ochrony nadawcy przed powiadomieniem o wypchnięciu do miejsca docelowego, które nie oczekuje ruchu. Chociaż ta specyfikacja nakazuje korzystanie z modelu autoryzacji, ten mandat nie jest wystarczający, aby chronić dowolną witrynę internetową przed niechcianym ruchem, jeśli ta witryna internetowa nie implementuje kontroli dostępu i dlatego ignoruje Authorization nagłówek.

Cele dostarczania POWINNY obsługiwać funkcję ochrony przed nadużyciami. Jeśli obiekt docelowy nie obsługuje tej funkcji, nadawca MOŻE zdecydować, że nie wysyłać do obiektu docelowego, w ogóle lub wysyłać tylko przy bardzo niskiej szybkości żądań.

Żądanie weryfikacji

Żądanie weryfikacji używa metody HTTP OPTIONS . Żądanie jest kierowane do dokładnego identyfikatora URI docelowego zasobu, który jest rejestrowany. W przypadku żądania weryfikacji nadawca obiekt docelowy o uprawnienie do wysyłania powiadomień i może zadeklarować żądaną częstotliwość żądań (żądania na minutę). Element docelowy dostarczania odpowie instrukcją uprawnień i dozwoloną stawką żądań. Oto kilka pól nagłówka do dołączenia do żądania weryfikacji.

Element WebHook-Request-Origin

WebHook-Request-Origin Nagłówek MUSI być uwzględniony w żądaniu weryfikacji i żąda uprawnień do wysyłania powiadomień od tego nadawcy i zawiera wyrażenie systemu nazw domen (DNS), które identyfikuje system wysyłania, na przykład eventemitter.example.com. Wartość jest przeznaczona do podsumowania identyfikowania wszystkich wystąpień nadawcy, które działają w imieniu określonego systemu, a nie pojedynczego hosta.

Po uścisku dłoni i udzieleniu uprawnień nadawca MUSI użyć Origin nagłówka żądania dla każdego żądania dostarczenia z wartością zgodną z tym nagłówkiem.

Przykład:

WebHook-Request-Origin: eventemitter.example.com

Odpowiedź na walidację

Jeśli i tylko wtedy, gdy element docelowy dostarczania zezwala na dostarczanie zdarzeń, MUSI odpowiedzieć na żądanie, dołączając WebHook-Allowed-Origin nagłówki i WebHook-Allowed-Rate . Jeśli element docelowy dostarczania zdecyduje się na udzielenie uprawnień przez wywołanie zwrotne, wstrzymuje nagłówki odpowiedzi.

Jeśli cel dostarczania nie zezwala na dostarczanie zdarzeń lub nie oczekuje dostarczenia zdarzeń i mimo to obsługuje metodę HTTP OPTIONS, istniejąca odpowiedź nie powinna być interpretowana jako zgoda, a zatem uzgadnianie nie może polegać na kodach stanu. Jeśli element docelowy dostarczania w przeciwnym razie nie obsługuje metody HTTP OPTIONS, powinien odpowiadać przy użyciu kodu stanu HTTP 405, tak jakby OPCJE nie były obsługiwane.

Odpowiedź OPTIONS POWINNA zawierać Allow nagłówek wskazujący dozwoloną metodę POST. Inne metody MOGĄ być dozwolone w zasobie, ale ich funkcja wykracza poza zakres tej specyfikacji.

Element WebHook-Allowed-Origin

WebHook-Allowed-Origin Nagłówek MUSI zostać zwrócony, gdy element docelowy dostarczania zgadza się na dostarczanie powiadomień przez usługę pochodzenia. Jego wartość MUSI być nazwą źródła podaną w nagłówku WebHook-Request-Origin lub pojedynczą gwiazdką ('*'), wskazującą, że element docelowy dostarczania obsługuje powiadomienia ze wszystkich źródeł.

WebHook-Allowed-Origin: eventemitter.example.com

Or

WebHook-Request-Origin: *

Ważne

Aby uzyskać więcej informacji na temat ochrony przed nadużyciami, zobacz Ochrona przed nadużyciami w temacie Web Hooks 1.1 dla specyfikacji dostarczania zdarzeń.

Powiązana zawartość

Zapoznaj się z następującym artykułem, aby dowiedzieć się, jak rozwiązywać problemy z weryfikacjami subskrypcji zdarzeń: Rozwiązywanie problemów z walidacją subskrypcji zdarzeń.