2022 APIsecure_Making webhook APIs secure for enterprise

Editor's Notes

• #2: Hi, thanks and great to be speaking at API Secure! Previously I’ve spoken at Api days about why webhook APIs or event APIs are going to become prominent in Enterprise. Today I’m going to cover the most important requirement of using webhook APIs in enterprise… security. (slide: x seconds, total = x seconds)
• #3: But let me first introduce myself, my name is Liam Forde, I’m most recently a co-founder of webhookie - an open-source webhook API platform. Prior to that I’ve spent a significant portion of my career as an Integration architect and developer. As I just mentioned I also spoke recently at API days Helsinki and North about why webhook Api’s are REST APIs perfect side kick. If you want to learn more about webhook APIs I suggest checking that out. (slide: x seconds, total = x min x seconds)
• #4: I ‘ll start the talk with a quick recap of what is a webhook API and why are they important to talk about. All of us here would be familiar with a REST API. REST APIs are great. They have democratized access to data using some clean, simple and accessible technologies – primarily JSON and HTTP. REST APIs are what you would call request-driven APIs in that the API consumers need to call them.
• #5: Webhook APIs are like REST APIs, in that they use JSON and HTTP but they are different in that the API consumer receives the data without having to call them. Rather the API consumer sets up a subscription and the API provider pushes the data to the API consumers when the event occurs. This makes Webhook APIs perfect for data integration needs, synchronising data and automating processes. They are also known by many names And just like REST APIs you describe them with an API specification (OAS or ASYNC API specification) and make them discoverable and self-service. It’s the discoverability, self-service and use of accessible and simple technologies that make them a game changer for Enterprise integration. But if they are going to become more prominent within Enterprise then security is the first thing to address. After all many of the webhook solutions we know today would not pass the security checks of large enterprise.
• #6: The Discord webhook as a good example of this. Discord is a community platform Perhaps some saw this hack in the news earlier in the year. ”Discord hacking is the new newest threat for NFT Buyers.” Read in... It’s about thieves targetting a feature known as a webhook! Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later.
• #7: Explain the hack - Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later. Don’t put token in the URL - URLs can generally end up in all sorts of unexpected places (analytics platforms, logs, history etc) that can be easily accessed. In the discord hack they had written a bot that scanned public github repo. URL’s are not treated with the same security processes as passwords and secrets. Conclusion don’t rely on unique URLs as your only form of security for callbacks.
• #8: Explain the hack - Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later. Don’t put token in the URL - URLs can generally end up in all sorts of unexpected places (analytics platforms, logs, history etc) that can be easily accessed. In the discord hack they had written a bot that scanned public github repo. URL’s are not treated with the same security processes as passwords and secrets. Conclusion don’t rely on unique URLs as your only form of security for callbacks.
• #9: Slack webhooks has the same vulnerability. Repeat again – don’t rely on unique URLs to secure your webhooks
• #10: When it comes to normal REST APIs , the topic of API security is mostly directed towards the API Provider. The API provider is the one that Layers of an onion REST API only is one-sided security I’m not going to talk too much about these layers but
• #11: Webhook security is two sided. So for the rest of this presentation I’m going to take a look at the security concerns from both an API provider and an API consumer perspective.
• #13: Discoverable APIs are a game changer for enterprise and ultimately give comes speed and agility however the downside is that you advertise your capabilities to also unwanted eyes. Therefore, it’s important that you try to restrict making your API’s discoverable to the communities of developers who should now about them. This is particularly important for enterprise. This applies to Events. In many webhook implementations you will have a subscriptions endpoint with the list of events that can be subscribed to. Again the slack events API is an example. If you applied this same pattern to enterprise it would mean that if you got access to this subscriptions API, you could view all the possible events in the enterprise to subscribe to. https://api.slack.com/events
• #14: A better approach is to group your events into APIs allowing you to setup authorizations rules that allow only certain groups of developers to discover them. To describe your APIs you can check out the ASYNC API specification Event APIs can be assigned to consumer groups and you can use identity platforms to manage those groups.
• #15: The great thing with webhooks and in general the pub/sub pattern is that you can quickly and easily setup multiple subscriptions to a feed. So in a normal use case you might want to setup one subscription to push events to your test system and another to push to your production system. Related to over-exposure – this benefit is also a risk. If you give access to a developer to a webhook API which enables them to setup subscriptions well then you also open up the possibility for them to take that data to unauthorized locations. Now admittedly you can’t prevent this completely from happening but you can minimize the risk by at least ensuring that each subscription is approved by the API provider.
• #16: This one is a quick one and in the majority of cases most webhook implementations meet this requirement. TLS is probably the most prominent security technique and ensures that we are delivering our messages to the right server in an encrypted connection. It should always be enforced in enterprise solutions.
• #17: And the primary job of this gateway will be to manage the guaranteed delivery to the subscribers and what subscribers generally demand from a webhook service is that it will be: (click) Be resilient to intermittent outages (click) Recover from downtimes (click) Replay messages when required. This includes a bunch of requirements and concerns that need to considered including: (click) retry strategies – for example how often and for how long should retries occur to be resilient to intermittent outages. (click) time-to-live – is there a time-limit for when this message is relevant. If it is not delivered today is there any point delivering it tomorrow (click) Fifo – is the order of delivery important (click) Recovery strategies – so if my system was down for a while and I want to automatically recover any messages which stopped retrying when i start up – what capabilities does the webhook API service have. (click) Re-send functionality – sometimes downstream systems need to have it sent again because of an issue they ran into on their side. (click) Throttling – different subscribers will have different capabilities. (slide: 40 seconds, total = 12 min 15 seconds)
• #18: Knowing what data your subscribers have received is becoming more important. Not only because of regulations like GDPR but also because it builds trust in your webhook solution.
• #20: Yep, just like the API providers need to know their consumers, API consumers need to know their API providers. (Unlike the picture here, I’m not referring to who the developer was but knowing the API providers severs) When it comes to REST APIs implementing Mutual TLS is tricky, because the client is often a web browser with a user at the end and asking the for an SSL certificate is a jarring experience. However with webhook APIs, we are in the context of system to system integrations, and mutual TLS is not only achievable but also good practice. If mutual TLS can not be achieved then using allow-lists is a solid brute force technique to ensure only those API provider servers can talk to your servers.
• #21: Next up as an API consumer is that you don’t want to unexpectedly receive events to a URL not intended for those events. If subscriptions are not validated then this is a good way for hackers to setup a denial of service account. Find a webhook API that has a high volume of events and send them towards to a URL that they want to take down. Therefore it is good practice to validate a subscripiton. With the provider sending a request to the consumer with a secret and for the consumer to respond with a 200 and the same secret in the header.
• #22: As referenced in the Discord Hack, don’t rely on a unique URL as your only security mechanism. An API consumers callback URL should not be treated differently to a normal REST API endpoint. There should be some authorization security. Even if you have mutual TLS in place many enterprises will look to add another layer of security. The use of a secret that is retrieved from a vault adds another layer. Technologies like Oauth 2.0 client credentials flow or the use of HMAC signature.
• #26: And that is the reason why we have started webhookie – an open source webhook API platform – that can be quickly added to any product, platform or integration architecture. Come and join the project. Thank you. (slide: 15 seconds, total = 15 min 45 seconds) .