Proteção contra bombing de SMS e OTP

O bombing de SMS e OTP designa ataques em que um bot aciona repetidamente um formulário OTP ou de registo no seu website para gerar SMS em massa. Os motivos típicos são o assédio a terceiros ("SMS flood" sobre um número alvo), o esgotamento do seu saldo e, sobretudo, a fraude IRSF (International Revenue Share Fraud), em que os atacantes enviam SMS para números premium internacionais de custo elevado dos quais eles próprios recebem uma parte.

Nenhuma funcionalidade isolada protege contra esta classe de ataques. Só uma proteção em camadas é eficaz: primeiro na sua aplicação, depois na sua conta seven.

Onde está a verdadeira falha

Na maioria dos casos de bombing, o formulário OTP está desprotegido: sem captcha, sem limite de frequência, sem tempo de espera. O atacante chama o endpoint de envio centenas ou milhares de vezes por minuto e cada chamada gera uma SMS real. A seven pode limitar os danos, mas o gatilho tem de ser fechado por si na sua aplicação.

Medidas de proteção na sua aplicação

Estes pontos pertencem ao seu frontend e backend, não à seven:

• Captcha antes do botão de envio. reCAPTCHA, hCaptcha, Cloudflare Turnstile ou uma deteção de bots comparável. É a medida individual mais eficaz.

• Limite de frequência por IP, por sessão e por número de destinatário. Exemplo: no máximo 3 OTP por cada 10 minutos por número de telemóvel e no máximo 10 OTP por hora por IP.

• Tempo de espera entre cliques de reenvio. Primeiro reenvio após 60 segundos e, depois, backoff exponencial (2, 4, 8 minutos).

• Pré-validação de números. Verifique o formato e o operador através do Lookup antes de acionar a SMS. Assim filtra números inválidos e destinos premium exóticos antes de surgirem custos.

• Campos honeypot e análise comportamental. Registe e bloqueie campos de formulário ocultos preenchidos, submissões invulgarmente rápidas e user agents atípicos.

Medidas de proteção na sua conta seven

Estas medidas limitam os danos caso a camada da aplicação ceda apesar de tudo.

Ativar as restrições por países

De longe a alavanca mais importante contra o IRSF. Se o seu serviço OTP serve apenas clientes de alguns países, bloqueie tudo o resto. Os ataques a números premium ficam assim sem efeito, porque a seven nem sequer entrega a SMS.

Configuração em Definições > Mensagens > Restrições por países. Para mais detalhes, consulte Restrições geográficas.

Ativar e impor a assinatura de pedidos

A seven suporta a assinatura de pedidos HMAC-SHA256 para a API REST. Cada pedido à API pode ser assinado com uma chave de assinatura separada, atribuída independentemente da chave de API. Uma chave de API roubada torna-se assim inútil por si só, desde que ative a obrigatoriedade da assinatura.

Funcionamento:

• Três cabeçalhos acompanham o pedido: X-Signature, X-Timestamp, X-Nonce.

• Com HMAC-SHA256 é assinada uma cadeia composta pelo timestamp, nonce, método HTTP, URL completo e hash MD5 do corpo (separados por quebras de linha).

• O timestamp pode ter no máximo 30 segundos (proteção contra repetição). O nonce é único por pedido.

• Configure a chave de assinatura em Developer > Settings. Na mesma secção ativa a obrigatoriedade da assinatura, para que os pedidos não assinados ou com assinatura inválida sejam rejeitados.

Documentação completa com exemplos em Bash e PHP: docs.seven.io/en/rest-api/signing.

Lista branca de IP de servidor para a API

Além da assinatura de pedidos, restrinja o acesso à API a IP de origem conhecidos: só são aceites pedidos dos IP dos seus servidores de aplicação; todos os outros são rejeitados com o erro 903. Isto também trava ataques em que a chave de assinatura e a chave de API são divulgadas em conjunto.

Configuração em Developer > Settings > REST API. Para mais detalhes, consulte Lista branca para aceder à API.

Uma chave de API própria por serviço

Não utilize a mesma chave para envios de marketing, SMS transacionais e OTP. Uma chave por serviço significa que uma única chave divulgada pode ser desativada de imediato sem interromper outros canais de envio. Consulte Onde encontro a minha chave de API? e Desativação de chaves de API não utilizadas.

Subconta apenas como teto rígido, não com o carregamento automático ativo

Uma subconta para o serviço OTP separa o saldo e os relatórios. No entanto, só funciona como teto de danos se o carregamento automático estiver desativado e a alimentar manualmente. Caso contrário, com um limiar baixo o carregamento é simplesmente feito com mais frequência e o dano total é o mesmo ou superior.

Configuração recomendada:

• uma subconta própria "OTP" com a sua própria chave de API

• carregamento automático desativado

• carregamento manual com um orçamento mensal fixo (p. ex. 50 EUR)

• quando a subconta fica vazia, o envio para automaticamente

Detalhes sobre a configuração: Subcontas.

Notificação de saldo baixo para vários destinatários

Uma vaga de envios invulgar leva inevitavelmente a uma rápida descida do saldo. Defina um limiar e pelo menos dois endereços de destinatários (técnico e faturação), para que o alerta chegue também quando uma pessoa estiver de férias. Consulte Notificação de saldo baixo.

Segurança da conta

• Imponha a 2FA a todos os membros da conta, para que uma palavra-passe roubada não seja suficiente. Consulte Autenticação de dois fatores (2FA) e Impor autenticação de dois fatores (2FA).

• Lista branca de IP para o login além da lista branca da API, caso trabalhe a partir de IP fixos de escritório. Consulte Lista branca de IP para login.

• Desative as chaves de API não utilizadas e reveja-as regularmente.

Se já houver um ataque em curso

1. Rode ou desative de imediato a chave de API nas definições de programador. Assim, qualquer envio adicional para de imediato.

2. Reforce as restrições por países e bloqueie todos os países que não sejam de destino.

3. Contacte o suporte através de support@seven.io, indicando o ID da sua conta e o intervalo de tempo. Ajudamos a analisar os padrões de envio e a conter o ataque. Tenha em atenção: os custos de SMS acionadas por uma aplicação desprotegida do cliente não são, em regra, reembolsados.

4. Proteja o lado da aplicação antes de reativar o envio. Integre um captcha, ative o limite de frequência e analise os registos.

O nosso suporte terá todo o gosto em ajudar em incidentes concretos.