No nosso primeiro artigo sobre webhooks, apontamos, para além de todas as vantagens do uso desse recurso, o desafio da segurança. Nesse contexto, a preocupação girava, principalmente, em torno da origem dos dados. Ao ser configurado para receber os dados, o endpoint vai receber. Com isso, a verificação da fonte desses dados torna-se crítica para a segurança com webhooks.

O mesmo se aplica com o destino: como garantir que os dados, mesmo que corretos, estão indo para o lugar certo? 

São essas as questões que também tornam a segurança com webhooks tão diferente, por exemplo, da segurança com APIs.

Sendo um importante tópico em integração, neste post vamos nos aprofundar nesse tema, compreendendo melhor onde está a fragilidade dos webhook e quais as principais medidas para mitigá-las.

Por que webhooks são mais vulneráveis a ataques

A compreensão da vulnerabilidade passa pelo fato de que webhooks usam uma URL publicamente disponível e acessível pela internet, ou seja, fora do domínio de um SSL. Com isso, ao usar uma conexão HTTPS não há criptografia no binômio mensagem enviada – mensagem recebida.

Onde quer que haja uma requisição a essa URL, ela vai atender. Daí a importância de garantir que a requisição realmente venha de uma fonte esperada.

Como lidar com a segurança com webhooks

Em segurança como um todo e em segurança com webhooks em especial, não há uma estratégia só para todos os casos. Podemos falar de alguns métodos considerados padrão nas iniciativas.

Veremos na sequência quais são eles.

Tokens de autenticação

Como o endpoint de API para onde o webhook envia seus eventos é disponível publicamente, qualquer um pode enviar eventos para ele.

A maneira mais simples e básica de garantir que o endpoint está recendo apenas eventos legítimos é por meio dos tokens de autenticação. Uma vez enviados, eles são verificados pelo destinatário antes de processar o evento.

A autenticação básica, com login e senha, também se inclui nessa abordagem. Nesse caso, o endpoint é associado a um único usuário. Para autenticar o webhook, é preciso configurar as informações de acesso durante a implementação do webhook.

Hash-based message authentication code – HMAC

O HMAC vem sendo a abordagem mais popular em segurança de webhooks. Ele protege especificamente contra ataques que forjam uma requisição a um endpoint definido no webhook, para fazer com que pareça que ele vem da aplicação origem. Quando bem-sucedidos, esses ataques enviam dados falsos, por exemplo.

É para suprir esse gap que a HMAC vem, sendo a abordagem mais popular em segurança de webhooks. Ela protege especificamente contra ataques que forjam uma requisição a um endpoint definido no webhook, para fazer com que pareça que ele vem da aplicação origem. Quando bem-sucedidos, esses ataquem enviam dados falsos, por exemplo.

No HMAC, origem e destino dos dados compartilham o mesmo segredo para assegurar que a mensagem enviada e recebida é verdadeira. Então, ambos os sistemas têm uma função hash comum, que usam para a assinatura e verificação da assinatura dessa mensagem.

A assinatura é incluída na requisição da aplicação de origem. A aplicação destino verifica essa assinatura. Feito o match, a mensagem é considerada verdadeira e recriada, aplicando o segredo compartilhado sobre ela.

Algumas observações interessantes. O HMAC assegura que o remetente e o destinatário são verificados um para o outro, dado que só a origem autenticada pode saber o segredo com que o HMAC foi gerado. Se uma falsa origem está tentando transferir dados falsos, ela não será capaz de recriar o HMAC correto, já que o segredo compartilhado não faz parte da requisição.

Carimbo do tempo

Essa é uma abordagem fundamental em ataques de repetição, ou seja, em que a requisição é enviada várias vezes seguidas.

O carimbo do tempo inclui uma marca temporal na assinatura feita com o HMAC. Assim, se o conteúdo é enviado em sua completude mas o carimbo do tempo é muito antigo, a aplicação de destino pode rejeitar essa requisição.

A segurança desse método está na impossibilidade de alterar o carimbo, sem invalidá-lo completamente. No case de uma falha, na entrega, um conteúdo pode ser gerado, com uma nova assinatura.

TSL mútuo

Assim como a origem pode ser alvo de ataques, o destino também pode, sendo a mensagem enviada para outro lugar. Aqui entra o TSL mútuo como uma opção para garantir a segurança de webhooks.

Por que mútuo? Porque na solução padrão, a validação é unidirecional, ou seja, é a aplicação destino que valida a identidade da aplicação de origem. Mas no caso de webhooks a origem também precisa ter certeza de que está enviando dados para o destino correto. Então a validação precisa ser nos dois sentidos.

Nesse cenário, a aplicação de origem é configurada não apenas para enviar um certificado à aplicação de destino, mas também para requisitar uma resposta com seu próprio certificado, que ela validará em sua lista de certificados confiáveis.

Não enviar dados via webhook

Essa é a abordagem mais conservadora em segurança com webhooks, mas a ideal para informações sensíveis.

Nesse caso, em vez de enviar via webhook o evento completo para o endpoint de destino, ele apenas notificará que um evento importante aconteceu na aplicação de origem, que está esperando por ser chamada.

Para ter todos os dados do evento, a aplicação destino precisa fazer uma chamada de API propriamente dita.

Segurança com webhooks: você tem opções

Os webhooks são recursos poderosos, e devem ser usados. Ainda assim, segurança deve se manter um tema constante.

Vimos algumas opções que as organizações podem implementar em vários pontos da cadeia para garantir a segurança de integrações com webhooks. De fato, há ferramentas pensadas para a aplicação de origem, para a aplicação de destino e até para a mensagem. Todas são recomendas.  

E você? Tem cuidado bem da segurança de webhooks em operação?