Improved security for webhooks

[mwarkentin]

I love this project, it's a nice demonstration of what you can do with SAR.

I'm curious if you have any ideas on how security could be improved for these webhook endpoints? It seems like if the URL for the webhook receiver ends up in someone's hands they could send any payload they want.

Some options I'm thinking of:

• support for shared secrets somehow (like Github's)
• IP whitelisting if you have static IPs where you expect these webhooks to arrive from

[stojanovic]

Good ideas! Both suggestions make sense. Let me think what's the best and easiest way to handle security, and I'll get back in the next day or two.

[stojanovic]

@mwarkentin we have the following options here:

1. Manage shared secrets in the Lambda function (both API and functions will be triggered anyway).
2. Create another SAR app that uses REST API instead of HTTP API, because it supports API key out of the box.
3. Wait a bit longer, HTTP API is in beta, and I am sure they'll add some helpful new features soon.

I am not a big fan of doing things in-house if I know they'll release something that solves the same problem soon, so I think options 2 and 3 are better then option 1. What do you think?

[mwarkentin]

@stojanovic thanks for looking into it! A couple of thoughts:

1. This seems like the only way that would work today, but seems like it might be quite complicated - different services are going to have different formats (eg. github, stripe). Here's an example lambda which checks for the github secret and another for stripe (which seems to have signature verification in it's own library). It feels like if we wanted to go this way it might make sense to make multiple SAR apps - a dedicated app per popular service in addition to the existing generic webhook handler w/o auth?
2. I don't think switching to REST API out of the box would work since the webhook services wouldn't be setting the API key the way that API Gateway would expect it - REST APIs do support custom lambda authorizers which would probably be the way it would have to go
3. Agreed - it's possible that they add some improvements that would allow us to handle this in HTTP APIs (eg. enabling custom lambda authorizers)

I am realizing as we look into it that this is a very complicated request. 😓

[shihrer]

Would a lambda authorizer be able to help with this?

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html

[stojanovic]

Sorry for delayed answer @shihrer. That's a great idea, however HTTP API does not support custom authorizers.
I am still for option 3, as I am sure there will be some AWS feature that will give us more options, soon.

[wolverian]

This is still a sticking issue I think. 😄 Lambda Authorizers (for both HTTP and REST APIs) can't look at the whole request body, but that's exactly how you're supposed to validate GitHub webhooks - by hashing the request body with the shared secret, and checking the hash matches the input header. I think, for the moment, this needs to be implemented in the same Lambda that does the actual ingesting.

This is particularly annoying because you could also wire API Gateway to send the webhook payload directly to SQS or EventBridge, skipping the Lambda completely. But we need the Lambda to validate the payload, and we can't use authorisers for it.