How dangerous is it to allow arbitrary webhook urls to post to?

Question

I am building a Ruby on Rails API that posts to webhooks that the API user can create, whenever a resource that he manages is created, updated or destroyed, using the HTTParty gem. This got me thinking: I am validating that the webhook url is indeed a valid url, but that's it.

What if, for example, the API posts to a webhook that redirects forever? Or, maybe even worse, a webhook that in turn communicates with the API again, triggering more webhooks, so that eventually the API has to handle an infinite amount of webhooks?

These are just two examples, but I guess a lot more could happen.

The one thing I have come up with is to put all posts to webhooks in background tasks, so that at least the workload is distributed to workers, in case someone tries a DOS attack (but then again, I am not sure if that properly protects me from DOS attacks).

Are there any other common threats/pitfalls when using webhooks? What can I do to defend against harmful webhooks and how can I detect them?

Answer 1

In addition to "validating webhook URLs", implement rate limiting on your API endpoints and/or calling webhooks.

If you have a big/popular enough service you should have this even if you don't allow users to have custom callback URLs — eventually somebody will attempt to make a million requests against a resource-intensive (for you) API endpoint, and you really should have protection in place.

That is — you don't have to thoroughly try to detect "malicious" URLs — just have logic in place that would cut off access if a single account makes X requests within Y minutes (add more complex logic as needed).

——

Of course you should also:

• run webhooks asynchronously (in the background) so your API speed does not depend on a 3rd party.
• run basic checks that prevent infinite redirect loops, and (for example) blacklist your own domain (make sure to check the blacklist for each redirect target separetely).

Answer 2

These concerns are all very valid and we've had to consider them when writing the PubSubHubbub spec. We 'solved' most of them by having a verification step which involves executing the webhook and expecting a specific answer from it. Basically when a new hook is added, it's called with a GET request and an additional 'hub.challenge' param. The webhook then MUST respond with a 200 and echo the hub.challenge in the body.

Generally, I would recommand looking at PubSubHubbub when implementing a webhooks "API", because that's what it is :) Initially it was designed for RSS/Atom but now works with any type of resources, including JSON. It also provides mechanisms for secure delivery (using secret and HMAC signatures).

Answer 3

Bringing this down from comment because it's important.

A concern to address as well is internal targets. For example, an attacker could pass an address that is internal to your network that would normally be firewalled off and/or hidden behind NAT. The implications of this vary wildly based on your application.

Consider also the possibility of accessing infrastructure resources like AWS S3 buckets, Dynamo DB databases, or SQS queues. Depending on your configuration, you could be allowing arbitrary writes to these resources. Depending on your setup, it may be possible for an attacker to read/write data to/from one of these services, and then have that data exfiltrated via regenerative webhook (trigger another webhook that would echo this data) back to his/her own server!

This is something to consider when validating webhook URLs.

Answer 4

One other thing to be aware of that I haven't seen in this thread is webhook calls being purposely slow and using up threads which would be a problem for php based applications, that way you could take an application down by making very few requests.