Quanto è pericoloso consentire l'invio di URL arbitrari di webhook?

Question

Quanto è pericoloso consentire l'invio di URL arbitrari di webhook?

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)

10

Sto creando un'API Ruby on Rails che pubblica i webhook che l'utente API può creare, ogni volta che una risorsa che gestisce viene creata, aggiornata o distrutta, utilizzando gemma HTTParty . Questo mi ha fatto pensare: sto convalidando che l'url webhook è davvero un url valido, ma questo è tutto.

Cosa succede se, ad esempio, i post dell'API su un webhook che reindirizza per sempre? O, forse ancora peggio, un webhook che a sua volta comunica nuovamente con l'API, attivando più webhook, così che alla fine l'API deve gestire una quantità infinita di webhook?

Questi sono solo due esempi, ma suppongo che potrebbe accadere molto di più.

L'unica cosa che mi è venuta in mente è di mettere tutti i post ai webhook nelle attività in background, in modo che almeno il carico di lavoro sia distribuito ai lavoratori, nel caso qualcuno provi un attacco DOS (ma poi di nuovo, non sono sicuro se che mi protegge adeguatamente dagli attacchi DOS).

Ci sono altre minacce / insidie comuni quando si usano i webhook? Cosa posso fare per difendermi dai webook dannosi e come posso rilevarli?

http denial-of-service url-redirection

posta weltschmerz 23.12.2013 - 14:13

fonte

3 risposte

3

Queste preoccupazioni sono tutte molto valide e abbiamo dovuto considerarle durante la scrittura delle specifiche PubSubHubbub . Abbiamo "risolto" la maggior parte di questi con una fase di verifica che prevede l'esecuzione del webhook e l'attesa di una risposta specifica da esso. Fondamentalmente quando viene aggiunto un nuovo hook, viene chiamato con una richiesta GET e un ulteriore parametro 'hub.challenge'. Il webhook quindi DEVE rispondere con un 200 ed echeggiare l'oggetto hub.challenge nel corpo.

In generale, vorrei riconsiderare PubSubHubbub quando implemento una "API" webhooks, perché è quello che è :) Inizialmente era progettato per RSS / Atom ma ora funziona con qualsiasi tipo di risorse, incluso JSON. Fornisce inoltre meccanismi per la consegna sicura (utilizzando firme segrete e HMAC).

risposta data 26.12.2013 - 11:01

fonte

2

Riducendolo dal commento perché è importante.

Una preoccupazione per affrontare anche gli obiettivi interni. Ad esempio, un utente malintenzionato potrebbe passare un indirizzo interno alla rete che normalmente sarebbe protetto dal firewall e / o nascosto dietro NAT. Le implicazioni di questo variano selvaggiamente in base alla tua applicazione.

Considera anche la possibilità di accedere a risorse infrastrutturali come i bucket AWS S3, i database Dynamo DB o le code SQS. A seconda della configurazione, è possibile consentire scritture arbitrarie a tali risorse. A seconda della configurazione, potrebbe essere possibile per un utente malintenzionato leggere / scrivere dati da / per uno di questi servizi e quindi far sì che tali dati vengano filtrati tramite il webhook rigenerativo (innesca un altro webhook che farebbe eco a questi dati) al proprio server!

Questo è qualcosa da considerare quando convalida gli URL di webhook.

risposta data 23.02.2017 - 20:07

fonte

Leggi altre domande sui tag http denial-of-service url-redirection

Cracking del terminale PCI utilizzando un trojan basato sulla scheda SAML e Kerberos cosa usare dove [chiuso]

score 4 · Accepted Answer

Oltre a "convalidare gli URL webhook", implementa la limitazione della velocità sui tuoi endpoint API e / o chiamando i webhook.

Se hai un servizio abbastanza grande / popolare dovresti avere questo anche se non permetti agli utenti di avere URL di callback personalizzati - alla fine qualcuno tenterà di fare un milione di richieste contro un endpoint dell'API (per te) ad uso intensivo di risorse e dovresti davvero avere una protezione sul posto.

Cioè - non devi cercare accuratamente di rilevare URL "dannosi": è sufficiente disporre di una logica che blocchi l'accesso se un singolo account fa richieste X entro Y minuti (aggiungi logica più complessa se necessario).

-

Ovviamente dovresti anche:

esegui i webhook in modo asincrono (in background) in modo che la tua velocità dell'API non dipenda da una terza parte.
esegue controlli di base che impediscono infiniti loop di reindirizzamento e (per esempio) lista nera del tuo dominio (assicurati di controllare separatamente la lista nera per ciascun target di reindirizzamento).