Como proteger webhooks: checklist de 5 passos

Segurança é uma das responsabilidades mais importantes de quem mantém aplicações online. Certa vez subi um site em WordPress e, em questão de minutos, já estava recebendo alertas de segurança sobre alguém tentando atacar a página de login. Pessoas mal-intencionadas e bots estão constantemente à espreita, esperando para explorar qualquer vulnerabilidade presente em um sistema. Todos nós precisamos ficar à frente dos atacantes, corrigindo e protegendo as brechas dos nossos sistemas.

Neste artigo, vamos percorrer o que considero os 5 principais passos para proteger seus webhooks. Vamos ver estratégias que ajudam a fechar as brechas mais comuns e mais perigosas, aquelas que os atacantes procuram explorar nos seus webhooks.

Resumo das ameaças e soluções

Problemas de segurança afetam todo mundo, e você não precisa ser especialista em segurança para começar a proteger seus webhooks contra ataques maliciosos. Abaixo estão as ameaças e soluções que você deve conhecer ao trabalhar com webhooks.

Agora que temos essa visão geral, vamos entrar em detalhes em cada um dos passos que você deve adotar imediatamente para garantir que seus webhooks estejam protegidos.

Criptografe todos os dados

Requisições de webhook são requisições HTTP comuns, e HTTP é um protocolo em texto puro. Isso significa que toda informação transmitida da origem até o destino durante uma requisição de webhook fica claramente visível e legível.

Atacantes podem interceptar essas mensagens com facilidade e se aproveitar de qualquer informação sensível contida nelas, como dados de usuários ou tokens de autenticação.

Você pode não conseguir impedir completamente a visibilidade das mensagens, mas pode impedir que sejam legíveis. Isso é feito garantindo que toda a comunicação aconteça sobre o protocolo HTTP seguro, o HTTPS.

Para isso, instale um certificado SSL no cliente e forneça uma URL de webhook segura. Isso garante segurança na camada de transporte, assegurando que todos os dados enviados sejam criptografados e, portanto, não possam ser lidos.

Verifique a origem

Uma URL de webhook é um endpoint na API do cliente. Esse endpoint é público e, por isso, pode ser chamado por qualquer aplicação. Como receptor de webhooks, você precisa verificar que as requisições que chegam ao seu endpoint vêm da origem correta.

Se não houver nenhum mecanismo para verificar a origem, atacantes podem enviar facilmente requisições maliciosas bem construídas para causar estragos no seu sistema. Por exemplo, payloads capazes de provocar SQL injection podem ser enviados ao seu endpoint para atacar o banco de dados e expor ou apagar dados importantes.

Se você é um provedor de webhooks, deve ajudar seus clientes a verificarem você. Uma das estratégias possíveis é incluir um token de autenticação em um header da requisição de webhook. O seu cliente também conhecerá esse token e vai procurá-lo nos headers de qualquer requisição recebida.

Outra forma de verificar a origem é o cliente conhecer o endereço IP do provedor de webhooks. O cliente pode então colocar esse IP em uma allowlist e rejeitar qualquer outra requisição vinda de endereços desconhecidos.

Verifique o consumidor

Como provedor de webhooks, outra medida de segurança que você deve adotar é verificar os seus consumidores.

Atacantes podem sempre interceptar requisições de webhook e redirecioná-las para outros destinos, a fim de se aproveitar dos dados transmitidos.

Uma forma de verificar o cliente é usar Mutual TLS. Em uma configuração TLS comum, apenas o cliente verifica/autentica o servidor.

Com Mutual TLS, tanto o cliente (o endpoint da sua API) quanto o servidor (o provedor de webhooks) verificam um ao outro. Ambos apresentam um certificado durante o handshake TLS, o que ajuda a provar mutuamente suas identidades.

Assim, mesmo que a requisição de webhook seja redirecionada para um destino malicioso, a autenticação vai falhar, já que o cliente não conseguirá receber as informações contidas na requisição.

Verifique a mensagem

Você recebeu a requisição de webhook e as informações contidas nela, mas como ter certeza de que a informação recebida está correta?

Atacantes podem interceptar uma requisição e substituir o payload antes que ela chegue ao seu endpoint. Dessa forma, mesmo que a mensagem esteja criptografada, ela contém o que eles (os atacantes) querem que você veja.

Isso abre mais uma brecha para que atacantes transmitam informações corrompidas para dentro do seu sistema.

Uma forma muito eficaz de verificar se as mensagens são legítimas é o provedor de webhooks e o cliente realizarem verificação de assinatura nas mensagens.

O provedor de webhooks envia ao cliente a mensagem em texto puro junto com uma assinatura gerada a partir da mensagem e do algoritmo de criptografia HMAC. Quando o cliente recebe a mensagem, ele usa o algoritmo HMAC e a mensagem recebida para deduzir a assinatura.

Em seguida, compara a assinatura deduzida com a enviada pelo provedor de webhooks. Se as assinaturas coincidirem, a mensagem é válida. Caso contrário, a mensagem foi adulterada e deve ser rejeitada.

A Stripe usa essa estratégia enviando a assinatura no header Stripe-Signature das suas requisições de webhook.

Previna replay attacks

Mesmo com as assinaturas de verificação de mensagem em uso, atacantes ainda podem encontrar um caminho para dentro do seu sistema usando uma estratégia conhecida como replay attack. Nesse tipo de ataque, um agente malicioso intercepta tanto a mensagem quanto a sua assinatura e as retransmite por conta própria.

Isso dá ao atacante a capacidade de agir como a origem da requisição de webhook no momento da retransmissão. Pense nisso como um roubo de identidade, em que outra pessoa consegue se passar por você porque obteve seu CPF ou o número do seu cartão de crédito.

A forma mais eficaz de evitar isso é adicionar um timestamp ao payload usado para criar a assinatura. O atacante não consegue alterar o timestamp sem invalidar a assinatura.

Se o atacante tentar mudar o timestamp, a sua verificação de mensagem vai detectar que a assinatura está incorreta.

Para aproveitar bem essa estratégia, garanta que o relógio do seu servidor esteja sincronizado com o do provedor de webhooks usando o Network Time Protocol (NTP).

A Stripe usa essa estratégia incluindo o timestamp no payload assinado, de modo que o timestamp também é verificado pela assinatura.

Como a Hookdeck ajuda

Percorrer este checklist para um provedor é gerenciável; fazer isso para cada origem de webhook da sua stack (e manter cada implementação correta conforme os provedores evoluem) é onde a maioria dos times acumula dívida de segurança. Um único descompasso significa rejeitar webhooks legítimos ou, pior, aceitar webhooks forjados — e o custo de manutenção cresce a cada novo provedor integrado.

O Event Gateway da Hookdeck faz a verificação de assinatura de mais de 160 provedores de webhooks de forma nativa. Você seleciona o provedor, informa o signing secret, e cada requisição recebida é verificada na borda antes de chegar à sua aplicação; requisições não verificadas são rejeitadas automaticamente. Isso significa que seus handlers podem confiar em todo payload que chega, sem que você precise manter lógica de verificação específica de cada provedor em todas as integrações do checklist. Comece a usar a Hookdeck e tire a autenticação de webhooks do seu código em poucos minutos.

Conclusão

Não existe segurança de 100%. Mesmo as maiores empresas, com os maiores orçamentos, continuam pesquisando novas formas de se proteger da maioria dos ataques. No entanto, vale lembrar que ataques também não são baratos de executar, já que os atacantes precisam investir em infraestrutura para penetrar nas redes mais seguras e roubar informações ou causar danos. Dito isso, com certas verificações em vigor, você certamente estará protegido contra a maior parte dos ataques comuns, porém devastadores, que podem ser lançados contra o seu sistema.