Why salt HTTP callbacks

Some cloud services want two-way communication for notifications: tell your backend about the completion of a long operation, show the errors that have occurred, warn about the low balance of paid services - the whole story. And if we are accustomed to using HTTP requests to communicate with services, then there are many options in the opposite direction: from status checks every ten minutes to permanent WebSocket or HTTP / 2 connections with real-time notifications. The easiest way is HTTP callbacks. You specify the URL of your backend in the admin panel, and the cloud service in case of interesting events makes an HTTP request to this URL with additional information in the request body. The flip side of simplicity is security. How to make sure that the request was made exactly by the cloud service, and not by the malicious hacker Vasya? Several ways under the cut.

Token transfer and verification

The easiest way is inside the easiest way: in the admin panel you set or generate a token (for example, a GUID) that the cloud service transmits in each request. And on the side of your backend just check this token.

The obvious disadvantage is that if an attacker overhears traffic between your services, he will recognize the token and be able to make requests on behalf of the service. HTTPS is well protected from this, but there are nuances. For example, traffic between servers may not be encrypted to speed up the work. Or you can debug your backend on a local machine, sitting in Starbucks without VPN. It sounds crazy, but anything can happen in life.

HTTP authorization on the side of your backend

It differs from a token only in that the verification is transferred from your code to the level of the web server that you use for processing requests. You specify a login plus a password in nginx / expressjs / Django / Rails / whatever, in the admin service of the cloud service, after which all checks are done automatically. But it is possible to overhear a login with a password in the same way, and HTTPS has an unpleasant feature of disconnecting "for a moment I can only debug locally."
')

IP filtering

If requests for the URL for the http callback are allowed only from a specific IP address, then the hacker will have big problems organizing such a request. Not that this was impossible (if the answer is not required, then the necessary sequence of TCP packets can be organized), but it is technically difficult. The ambush is different here - a cloud service can have many IP addresses from which it sends requests, which makes such protection too unreliable in a simple implementation and too complicated if reliability is needed.

MD5-signature with salt

A good balanced way with the shared secret that we use in Voximplant. An arbitrary text string is set in the admin panel (“cryptographic salt”, in the role of which the GUID is well suited), after which for each request the Voximplant cloud counts the MD5 hash from the account, request and salt data. On the side of the backend, knowing the salt, you can also calculate the hash and compare it with the one specified in the request. If it coincided, then everything is fine. And if not, then you can accept congratulations in the creation of a truly popular service, which even hackers visit.

More ways?

I told only a few simple ways to protect, which are used in practice in the HTTP API of large projects. Have you seen something else interesting? Share in the comments, I will be grateful!