Collection of best practices for providing and consuming webhooks
1–10 of 42 posts
Re: Collection of best practices for providing and consuming webhooks
#2Why are callback registration and async APIs now called webhooks?
Re: Collection of best practices for providing and consuming webhooks
#3Why are callback registration and async APIs now called webhooks?
[deleted]
Re: Collection of best practices for providing and consuming webhooks
#4Why are callback registration and async APIs now called webhooks?
Not sure of the evolution, but maybe because 'callbacks' exist everywhere, but 'webhooks' are specific to REST APIs.
Re: Collection of best practices for providing and consuming webhooks
#5Why are callback registration and async APIs now called webhooks?
The usual nomenclature is that regular callbacks and async API calls are made and registered in the same process space as the caller. (E.g. passing a function pointer in C, or using “await” in modern languages.)
Webhooks are callbacks received over HTTP from a public API. They may not be programmatically registered at all, e.g. the callback URL may be configured manually in an admin dashboard. So the application has less control over webhooks vs. regular callbacks or async functions.
Re: Collection of best practices for providing and consuming webhooks
#6There are some interesting attack vectors to be aware of if you run a service where users can define webhooks, and your service will will call the user-defined webhooks to notify about certain system events. In my case, a monitoring service which can send notifications by calling user-defined webhook.
* Timeouts: the user can set up a webhook receiver that takes very long to generate a response. Your service must be able to deal with that.
* Timeouts (slowloris): the webhook target could be sending back one byte at a time, with 1 second pauses inbetween. If you are using, say, the "requests" python library for making HTTP requests, the "timeout" parameter will not help here
* Private IPs and reserved IPs: you probably don't want users defining webhooks to " rel="nofollow">http://127.0.0.1: and probing your internal network. Remember about private IPv6 ranges too
* Domains that resolve to private IPs: attacker could set up foo.com which resolves to a private IP. It is not enough to just validate webhook URLs when users set them up.
* HTTP redirects to private IPs. If your HTTP client library follows HTTP redirects, the attacker can set up a webhook endpoint that redirects to a private IP. Again, it is not enough to validate the user-supplied URL.
* Excessive HTTP redirects. The attacker can set up a redirect loop - make sure this does not circumvent your timeout setting.
My current solution for all of the above is to use libcurl via pycurl. I wrote a wrapper that mimics requests API: https://github.com/healthchecks/healthchecks/blob/master/hc/... (may contain bugs, use at your own risk :-)
Re: Collection of best practices for providing and consuming webhooks
#7There are some interesting attack vectors to be aware of if you run a service where users can define webhooks, and your service will will call the user-defined webhooks to notify about certain system events. In my case, a monitoring service which can send notifications by calling user-defined webhook. * Timeouts: the user can set up a webhook receiver that takes very long to generate a response. Your service must be…
It seems like webhooks have enough corner cases for the sender to require a specialized tool to protect itself from malicious users and to stay performant.
Does anyone have suggestion for such tools/services that they might have used in production?
Re: Collection of best practices for providing and consuming webhooks
#8There are some interesting attack vectors to be aware of if you run a service where users can define webhooks, and your service will will call the user-defined webhooks to notify about certain system events. In my case, a monitoring service which can send notifications by calling user-defined webhook. * Timeouts: the user can set up a webhook receiver that takes very long to generate a response. Your service must be…
It seems like webhooks have enough corner cases for the sender to require a specialized tool to protect itself from malicious users and to stay performant. Does anyone have suggestion for such tools/services that they might have used in production?
At Slite, for all outgoing calls we use a sandboxed proxy. It has saved us a few times already.
We detailed the trick in a blog post -> https://slite-tech-blog.ghost.io/anti-ssrf-solution/
Re: Collection of best practices for providing and consuming webhooks
#9As this page makes very clear, it's actually pretty hard to make a robust webhooks implementation!
What alternatives are there? I've looked at: * Publishing AWS EventBridge events to other accounts. * /events instead of webhooks https://blog.sequin.io/events-not-webhooks/ * ???
Re: Collection of best practices for providing and consuming webhooks
#10As this page makes very clear, it's actually pretty hard to make a robust webhooks implementation! What alternatives are there? I've looked at: * Publishing AWS EventBridge events to other accounts. * /events instead of webhooks https://blog.sequin.io/events-not-webhooks/ * ???
Emails maybe ? But it means you have to regularly check your inbox. Or use a webhook called by your email provider when you receive an email :D