Validación de puntos de conexión con el esquema CloudEvents
Los webhooks son una de las muchas maneras de recibir eventos de Azure Event Grid. Cuando un nuevo evento está preparado, el servicio EventGrid publica una solicitud HTTP en el punto de conexión configurado con el evento en el cuerpo de la solicitud.
Al igual que muchos otros servicios que admiten webhooks, EventGrid requiere que demuestre la propiedad de su punto de conexión de Webhook antes de que comience a entregar eventos a ese punto de conexión. Este requisito evita que un usuario malintencionado sature el punto de conexión con eventos.
Validación de puntos de conexión con CloudEvents v1.0
CloudEvents v1.0 implementa su propia semántica de protección contra abusos mediante el método HTTP OPTIONS. Cuando usa el esquema de CloudEvents para la salida, Event Grid usa la protección contra abusos de CloudEvents v1.0 en lugar del mecanismo de eventos de validación de Event Grid.
Protección contra abusos de CloudEvent v1.0
Cualquier sistema que permita el registro y la entrega de notificaciones a puntos de conexión HTTP arbitrarios puede ser abusado de tal forma que alguien registre de forma malintencionada o involuntaria la dirección de un sistema que no espera dichas solicitudes y para las que el usuario registrado no esté autorizado para realizar este registro. En casos extremos, se podría abusar de una infraestructura de notificación para iniciar ataques por denegación de servicio contra un sitio web arbitrario.
Para proteger al remitente de ser abusado de tal manera, un destino de entrega legítimo debe indicar que está de acuerdo con las notificaciones que se le entregan.
El contrato de entrega se realiza mediante el siguiente protocolo de enlace de validación. El protocolo de enlace se puede ejecutar inmediatamente en el momento del registro o como una solicitud "preparatoria" inmediatamente anterior a una entrega.
Es importante comprender que el protocolo de enlace no pretende establecer un contexto de autenticación o autorización. Solo sirve para proteger al remitente de que se le indique que envíe un mensaje a un destino que no espera el tráfico. Aunque esta especificación exige el uso de un modelo de autorización, esta orden no es suficiente para proteger ningún sitio web arbitrario contra el tráfico no deseado si ese sitio web no implementa el control de acceso y, por tanto, omite el encabezado Authorization.
Los destinos de entrega DEBEN admitir la característica de protección contra abusos. Si un destino no admite la característica, el remitente PUEDE optar por no enviar al destino, en absoluto o enviar solo a una tasa de solicitudes muy baja.
Solicitud de validación
La solicitud de validación usa el método HTTP OPTIONS. La solicitud se dirige al URI exacto de destino del recurso que se está registrando. Con la solicitud de validación, el remitente solicita al destino permiso para enviar notificaciones y puede declarar una tasa de solicitudes deseada (solicitudes por minuto). El destino de entrega responderá con una instrucción de permiso y la tasa de solicitudes permitidas. Estos son un par de los campos de encabezado que se van a incluir en la solicitud de validación.
WebHook-Request-Origin
El encabezado WebHook-Request-Origin DEBE incluirse en la solicitud de validación y solicitar permiso para enviar notificaciones desde este remitente y contiene una expresión del sistema de nombres de dominio (DNS) que identifica el sistema de envío, por ejemplo, eventemitter.example.com. El valor está pensado para identificar de forma resumida todas las instancias de remitente que actúan en nombre de un sistema determinado y no en un host individual.
Una vez concedido el protocolo de enlace y si se ha concedido el permiso, el remitente DEBE usar el encabezado de solicitud Origin para cada solicitud de entrega, con el valor que coincide con el de este encabezado.
Ejemplo:
WebHook-Request-Origin: eventemitter.example.com
Respuesta de validación
Solo si el destino de entrega permite la entrega de los eventos, DEBE responder a la solicitud incluyendo los encabezados WebHook-Allowed-Origin y WebHook-Allowed-Rate. Si el destino de entrega elige conceder permiso mediante devolución de llamada, se retienen los encabezados de respuesta.
Si el destino de entrega no permite la entrega de los eventos o no espera la entrega de eventos y, sin embargo, controla el método HTTP OPTIONS, la respuesta existente no debe interpretarse como consentimiento y, por tanto, el protocolo de enlace no puede basarse en códigos de estado. Si el destino de entrega no controla el método HTTP OPTIONS, DEBE responder con el código de estado HTTP 405, como si no se admitiera OPTIONS.
La respuesta OPTIONS DEBE incluir el encabezado Allow que indica que se permite el método POST. Se PUEDEN permitir otros métodos en el recurso, pero su función está fuera del ámbito de esta especificación.
WebHook-Allowed-Origin
El encabezado WebHook-Allowed-Origin DEBE devolverse cuando el destino de entrega acepta la notificación por parte del servicio de origen. Su valor DEBE ser el nombre de origen proporcionado en el encabezado WebHook-Request-Origin o un carácter asterisco singular ("*"), lo que indica que el destino de entrega admite notificaciones de todos los orígenes.
WebHook-Allowed-Origin: eventemitter.example.com
Or
WebHook-Request-Origin: *
Importante
Para obtener más información sobre la protección contra abusos, consulte Protección contra abusos en HTTP 1.1 Web Hooks para la especificación de entrega de eventos.
Contenido relacionado
Consulte el siguiente artículo para obtener información sobre cómo solucionar problemas de validaciones de suscripciones de eventos: Solución de problemas de validacionesde suscripciones de eventos.