Validação de endpoint com esquema CloudEvents
Webhooks são uma das muitas maneiras de receber eventos da Grade de Eventos do Azure. Quando um novo evento está pronto, o serviço de Grade de Eventos POSTA uma solicitação HTTP para o ponto de extremidade configurado com as informações do evento no corpo da solicitação.
Como muitos outros serviços que suportam webhooks, a Grade de Eventos exige que você prove a propriedade do seu ponto de extremidade Webhook antes que ele comece a entregar eventos para esse ponto de extremidade. Esse requisito impede que um usuário mal-intencionado inunde seu ponto de extremidade com eventos.
Validação de endpoint com CloudEvents v1.0
O CloudEvents v1.0 implementa sua própria semântica de proteção contra abuso usando o método HTTP OPTIONS . Quando você usa o esquema CloudEvents para saída, a Grade de Eventos usa a proteção contra abuso do CloudEvents v1.0 no lugar do mecanismo de eventos de validação da Grade de Eventos.
Proteção contra abuso do CloudEvent v1.0
Qualquer sistema que permita o registro e a entrega de notificações para pontos de extremidade HTTP arbitrários pode ser potencialmente abusado de tal forma que alguém maliciosamente ou inadvertidamente registre o endereço de um sistema que não espera tais solicitações e para o qual a parte registradora não está autorizada a realizar tal registro. Em casos extremos, uma infraestrutura de notificação pode ser utilizada abusivamente para lançar ataques de negação de serviço contra um sítio Web arbitrário.
Para proteger o remetente de ser abusado dessa forma, um alvo de entrega legítimo precisa indicar que concorda com as notificações que lhe são entregues.
Chegar ao contrato de entrega é realizado usando o seguinte handshake de validação. O aperto de mão pode ser executado imediatamente no momento do registro ou como um pedido de "comprovação" imediatamente antes de uma entrega.
É importante entender que o handshake não visa estabelecer um contexto de autenticação ou autorização. Serve apenas para proteger o remetente de ser avisado para um push para um destino que não está esperando o tráfego. Embora essa especificação exija o uso de um modelo de autorização, essa exigência não é suficiente para proteger qualquer site arbitrário de tráfego indesejado se esse site não implementar o controle de acesso e, portanto, ignorar o Authorization cabeçalho.
Os alvos de entrega DEVEM suportar o recurso de proteção contra abuso. Se um destino não suportar o recurso, o remetente PODE optar por não enviar para o destino, de todo, ou enviar apenas a uma taxa de solicitação muito baixa.
Pedido de validação
A solicitação de validação usa o método HTTP OPTIONS . A solicitação é direcionada para o URI de destino exato do recurso que está sendo registrado. Com a solicitação de validação, o remetente pede permissão ao alvo para enviar notificações e pode declarar uma taxa de solicitação desejada (solicitações por minuto). O alvo de entrega responderá com uma declaração de permissão e a taxa de solicitação permitida. Aqui estão alguns dos campos de cabeçalho para inclusão na solicitação de validação.
WebHook-Request-Origin
O WebHook-Request-Origin cabeçalho DEVE ser incluído na solicitação de validação e solicita permissão para enviar notificações desse remetente e contém uma expressão DNS (Sistema de Nomes de Domínio) que identifica o sistema de envio, por exemplo eventemitter.example.com. O valor destina-se a identificar sumariamente todas as instâncias do remetente que atuam em nome de um determinado sistema, e não de um host individual.
Após o handshake e se a permissão tiver sido concedida, o remetente DEVE usar o Origin cabeçalho da solicitação para cada solicitação de entrega, com o valor correspondente ao desse cabeçalho.
Exemplo:
WebHook-Request-Origin: eventemitter.example.com
Resposta de validação
Se e somente se o destino de entrega permitir a entrega dos eventos, ele DEVE responder à solicitação incluindo os WebHook-Allowed-Origin cabeçalhos e WebHook-Allowed-Rate . Se o destino de entrega optar por conceder permissão por retorno de chamada, ele retém os cabeçalhos de resposta.
Se o destino de entrega não permitir a entrega dos eventos ou não esperar a entrega de eventos e, no entanto, manipular o método HTTP OPTIONS, a resposta existente não deve ser interpretada como consentimento e, portanto, o handshake não pode depender de códigos de status. Se o destino de entrega não manipular o método HTTP OPTIONS, ele DEVE responder com o código de status HTTP 405, como se OPTIONS não fosse suportado.
A resposta OPTIONS DEVE incluir o Allow cabeçalho indicando o método POST que está sendo permitido. Outros métodos PODEM ser permitidos no recurso, mas sua função está fora do escopo desta especificação.
WebHook-Allowed-Origin
O WebHook-Allowed-Origin cabeçalho DEVE ser devolvido quando o destino de entrega concorda com a entrega da notificação pelo serviço de origem. Seu valor DEVE ser o nome de origem fornecido no WebHook-Request-Origin cabeçalho ou um caractere de asterisco singular ('*'), indicando que o destino de entrega suporta notificações de todas as origens.
WebHook-Allowed-Origin: eventemitter.example.com
Ou
WebHook-Request-Origin: *
Importante
Para obter mais informações sobre a proteção contra abuso, consulte Proteção contra abuso nos Web Hooks HTTP 1.1 para especificações de entrega de eventos.
Conteúdos relacionados
Consulte o seguinte artigo para saber como solucionar problemas de validações de assinatura de eventos: Solucionar problemas de validações de assinatura de eventos.