Convalida degli endpoint con lo schema CloudEvents
I webhook sono uno dei molti modi per ricevere eventi da Griglia di eventi di Azure. Quando un nuovo evento è pronto, il servizio Griglia di eventi esegue il POST di una richiesta HTTP nell'endpoint configurato con le informazioni sull'evento nel corpo della richiesta.
Analogamente a molti altri servizi che supportano i webhook, Griglia di eventi richiede la dimostrazione della proprietà dell'endpoint del webhook prima dell'inizio del recapito di eventi a tale endpoint. Questo requisito impedisce a un utente malintenzionato di sovraccaricare l'endpoint con eventi.
Convalida degli endpoint con CloudEvents v1.0
CloudEvents v1.0 implementa la propria semantica di protezione dall'uso improprio tramite il metodo HTTP OPTIONS. Quando si usa lo schema CloudEvents per l'output, Griglia di eventi usa la protezione dall'uso improprio di CloudEvents v1.0 al posto del meccanismo di eventi di convalida di Griglia di eventi.
Protezione dall'uso improprio di CloudEvent v1.0
Qualsiasi sistema che consente la registrazione e il recapito di notifiche a endpoint HTTP arbitrari può essere potenzialmente soggetto a uso improprio nella misura in cui un utente malintenzionato o un qualsiasi utente involontariamente registri l'indirizzo di un sistema che non prevede tali richieste e per cui la parte responsabile della registrazione non è autorizzata a eseguire tale registrazione. In casi estremi, un'infrastruttura di notifica potrebbe essere soggetta a uso improprio per lanciare attacchi Denial of Service contro un sito Web arbitrario.
Per proteggere il mittente da questo tipo di uso improprio, un obiettivo di recapito legittimo deve indicare che accetta che le notifiche vengano recapitate.
Il raggiungimento del contratto di consegna viene realizzato usando l'handshake di convalida seguente. L'handshake può essere eseguito immediatamente in fase di registrazione o come richiesta "preliminare" subito prima di un recapito.
È importante comprendere che l'handshake non mira a stabilire un contesto di autenticazione o autorizzazione. Serve solo per proteggere il mittente dalla notifica push a una destinazione che non prevede il traffico. Anche se questa specifica impone l'uso di un modello di autorizzazione, questo mandato non è sufficiente per proteggere qualsiasi sito Web arbitrario dal traffico indesiderato se tale sito Web non implementa il controllo di accesso e quindi ignora l'intestazione Authorization.
Le destinazioni di consegna DOVREBBERO supportare la funzionalità di protezione dall'uso improprio. Se una destinazione non supporta la funzionalità, il mittente PUÒ scegliere di non effettuare invii alla destinazione, o di effettuarli solo a una frequenza di richiesta molto bassa.
Richiesta di convalida
La richiesta di convalida usa il metodo HTTP OPTIONS. La richiesta viene indirizzata all'URI di destinazione esatto della risorsa che viene registrato. Con la richiesta di convalida, il mittente chiede alla destinazione l'autorizzazione per l'invio di notifiche e può dichiarare una frequenza di richiesta desiderata (richieste al minuto). La destinazione di recapito risponderà con un'istruzione di autorizzazione e la frequenza di richiesta consentita. Ecco alcuni campi di intestazione da includere nella richiesta di convalida.
WebHook-Request-Origin
L'intestazione WebHook-Request-Origin DEVE essere inclusa nella richiesta di convalida e richiede l'autorizzazione per inviare notifiche da questo mittente, inoltre contiene un'espressione DNS (Domain Name System) che identifica il sistema di invio, ad esempio eventemitter.example.com. Il valore è progettato per identificare in maniera riepilogativa tutte le istanze del mittente che agiscono per conto di un determinato sistema e non un singolo host.
Dopo l'handshake e se è stata concessa l'autorizzazione, il mittente DEVE usare l'intestazione della richiesta Origin per ogni richiesta di recapito, con il valore corrispondente a quello dell'intestazione.
Esempio:
WebHook-Request-Origin: eventemitter.example.com
Risposta di convalida
Se e solo se la destinazione di recapito consente il recapito degli eventi, DEVE rispondere alla richiesta includendo le intestazioni WebHook-Allowed-Origin e WebHook-Allowed-Rate. Se la destinazione di recapito sceglie di concedere l'autorizzazione tramite callback, restituisce le intestazioni di risposta.
Se la destinazione di recapito non consente il recapito degli eventi o non prevede il recapito degli eventi e gestisce comunque il metodo HTTP OPTIONS, la risposta esistente non deve essere interpretata come consenso e pertanto l'handshake non può basarsi sui codici di stato. In caso contrario, se la destinazione di recapito non gestisce il metodo HTTP OPTIONS, DOVREBBE rispondere con il codice di stato HTTP 405, come se OPTIONS non fosse supportata.
La risposta OPTIONS DEVE includere l'intestazione Allow che indica il metodo POST consentito. Altri metodi POSSONO essere consentiti nella risorsa, ma la relativa funzione non rientra nell'ambito di questa specifica.
WebHook-Allowed-Origin
L'intestazione WebHook-Allowed-Origin DEVE essere restituita quando la destinazione di recapito accetta il recapito delle notifiche dal servizio di origine. Il valore DEVE essere il nome dell'origine fornito nell'intestazione WebHook-Request-Origin o un carattere asterisco singolo ('*'), che indica che la destinazione di recapito supporta le notifiche da tutte le origini.
WebHook-Allowed-Origin: eventemitter.example.com
O
WebHook-Request-Origin: *
Importante
Per altre informazioni sulla protezione dall'uso improprio, vedere Protezione dall'uso improprio nelle specifiche Webhook HTTP 1.1 per la distribuzione di eventi.
Contenuto correlato
Per informazioni su come risolvere i problemi relativi alle convalide delle sottoscrizioni di eventi, vedere l'articolo seguente: Risolvere i problemi di convalida delle sottoscrizioni di eventi.