Segurança de aplicativos de alerta: como validar notificações

Um aplicativo de alerta de emergência não pode tratar uma notificação como verdade só porque ela chegou pelo canal oficial. Segundo o BBC News, moradores da Ucrânia e da Rússia receberam alertas falsos — inclusive sobre radiação e ataques nucleares — após incidentes que as autoridades atribuíram a interferências ou invasões. O problema técnico vai além de um servidor comprometido: quando a confiança no alerta falha, o sistema pode provocar pânico ou fazer as pessoas ignorarem um aviso legítimo.

Na minha experiência com sistemas distribuídos, a pergunta mais importante não é apenas “como impedir o invasor de enviar uma notificação?”. É também “como o usuário distingue um alerta autêntico de um falso quando a infraestrutura está sob ataque?”. Essa diferença muda a arquitetura: segurança, redundância, comunicação de incidentes e comportamento do aplicativo precisam ser projetados em conjunto.

O que aconteceu com os aplicativos de alerta na Ucrânia e na Rússia

De acordo com o BBC News, por volta das 22h47 no horário local, o aplicativo ucraniano Air Alarm começou a enviar alertas de nível vermelho. Alguns moradores de Kiev receberam avisos sobre ameaça de radiação, além de mensagens relacionadas a ataques químicos e agitação civil. Depois, uma mensagem no Telegram afirmou que o aplicativo provavelmente havia sofrido interferência hostil e que não existia ameaça radiológica.

Horas mais tarde, autoridades russas também disseram que o aplicativo de alertas do país havia sido hackeado. Um grupo ucraniano secreto na Crimeia alegou que usuários na Rússia tinham recebido alertas falsos sobre ataques nucleares. A fonte não detalha como os sistemas foram comprometidos; portanto, não dá para concluir se houve invasão do backend, abuso de credenciais, problema no provedor de notificações ou outra falha.

Essa distinção importa. “O aplicativo foi hackeado” descreve o impacto percebido pelo público, não necessariamente a causa técnica. Sem análise forense divulgada, qualquer explicação sobre o vetor de ataque seria especulação. Para quem desenvolve, o caso é um exercício concreto de desenho de sistemas críticos: como manter autenticidade, disponibilidade e clareza quando usuários e operadores já estão sob pressão?

Por que uma notificação push não é prova de autenticidade

Um push pode passar por diversos componentes: painel administrativo, API, fila, serviço de envio, plataforma móvel e, por fim, o dispositivo. TLS protege conexões entre etapas, mas não garante que a mensagem foi aprovada por uma autoridade legítima. Se uma conta administrativa ou um serviço de backend for comprometido, o canal criptografado pode entregar uma mensagem falsa com eficiência.

Também é importante separar entrega de confiança. Apple Push Notification service e Firebase Cloud Messaging ajudam a encaminhar notificações, mas não certificam que o conteúdo representa uma decisão oficial de emergência. A plataforma de push é parte do transporte. A autorização do alerta precisa ser verificada pela aplicação e, idealmente, por outros canais independentes.

Uma assinatura digital no conteúdo do alerta ajuda a responder uma pergunta específica: “esta mensagem foi assinada por uma chave autorizada?”. Ela não prova que a informação é verdadeira, nem impede que um operador legítimo com credenciais comprometidas assine um alerta incorreto. Por isso, sistemas de alto impacto precisam combinar controles técnicos e operacionais, como aprovação por mais de uma pessoa e trilhas de auditoria.

Assinatura digital, validade e prevenção de replay

Uma arquitetura possível é assinar o conteúdo do alerta no servidor com uma chave privada protegida e embutir a chave pública correspondente no aplicativo. O app verifica a assinatura antes de apresentar a mensagem como oficial. Para reduzir risco, o alerta também deve incluir horário de emissão, expiração, público ou região de destino e um identificador único.

O identificador ajuda a detectar repetição de mensagens antigas, mas só funciona se o cliente ou o backend mantiver um registro de alertas já processados. A expiração limita a janela de uso de um alerta, embora dependa de relógios razoavelmente corretos. A região de destino evita, por exemplo, apresentar como local um aviso destinado a outra área.

O exemplo abaixo usa Node.js e a API nativa de criptografia para verificar uma assinatura Ed25519. O payload é transmitido como Base64URL e a assinatura cobre exatamente os bytes decodificados; assim, não dependemos de uma serialização JSON “canônica” diferente entre servidor e cliente. A chave pública é apenas ilustrativa e deve ser substituída por uma chave distribuída e gerenciada com segurança.

import { createPublicKey, verify } from "node:crypto";

const publicKeyPem = `-----BEGIN PUBLIC KEY-----
COLOQUE_AQUI_A_CHAVE_PUBLICA_ED25519
-----END PUBLIC KEY-----`;

function base64urlToBuffer(value) {
  return Buffer.from(value, "base64url");
}

export function verifyAlert(envelope, now = Date.now()) {
  const { payload, signature } = envelope;

  if (typeof payload !== "string" || typeof signature !== "string") {
    throw new Error("Envelope de alerta inválido");
  }

  const payloadBytes = base64urlToBuffer(payload);
  const signatureBytes = base64urlToBuffer(signature);
  const publicKey = createPublicKey(publicKeyPem);

  const validSignature = verify(
    null,
    payloadBytes,
    publicKey,
    signatureBytes
  );

  if (!validSignature) {
    throw new Error("Assinatura do alerta inválida");
  }

  const alert = JSON.parse(payloadBytes.toString("utf8"));

  if (alert.audience !== "ua:kyiv") {
    throw new Error("Alerta destinado a outra região");
  }

  if (!Number.isInteger(alert.expiresAt) || alert.expiresAt <= now) {
    throw new Error("Alerta expirado ou sem validade definida");
  }

  if (typeof alert.id !== "string" || alert.id.length === 0) {
    throw new Error("Alerta sem identificador");
  }

  return alert;
}

Esse código valida a assinatura, a região, a expiração e a presença de um identificador. Ele não implementa persistência de IDs já vistos, rotação de chaves, sincronização de relógio nem aprovação humana. Em produção, eu trataria esses itens como parte do protocolo, não como melhorias opcionais. A chave privada deve ficar fora do aplicativo e protegida por um serviço de gerenciamento de chaves ou hardware seguro.

Redundância: aplicativo, cell broadcast, rádio e canais oficiais

Um aplicativo conectado à internet é útil, mas não deveria ser o único caminho para uma instrução crítica. Push pode atrasar, ser bloqueado por configurações do aparelho, depender de conectividade ou não aparecer em primeiro plano. O app também pode estar desatualizado ou indisponível justamente quando a rede está congestionada.

Dependendo do país e da infraestrutura, alternativas incluem transmissão celular de emergência (cell broadcast), sirenes, rádio, televisão e páginas ou canais oficiais independentes. O cell broadcast não depende de o usuário instalar um app ou cadastrar um número, mas também exige infraestrutura e governança próprias. Rádio e sirenes têm limitações de alcance e detalhe. Nenhum canal resolve tudo sozinho.

O Common Alerting Protocol (CAP) é um padrão usado para estruturar e distribuir alertas por diferentes meios. A vantagem de um formato comum é reduzir divergências entre mensagens enviadas a aplicativos, sites e outros sistemas. Ainda assim, padronizar o formato não autentica automaticamente a origem: assinatura, autorização e procedimentos de publicação continuam necessários.

Na Prática: como projetar um fluxo de alerta mais resiliente

Defina quem pode emitir cada classe de alerta. Separe permissões para teste, aviso informativo e ordem urgente. Uma única conta com acesso irrestrito transforma uma credencial comprometida em um risco sistêmico.
Exija aprovação proporcional ao impacto. Para alertas de alto risco, aplique dupla aprovação ou uma regra equivalente. O fluxo precisa ser rápido, mas velocidade não deve significar que uma conta isolada publique uma mensagem irreversível.
Assine o conteúdo e valide no cliente. Inclua identificador, área, horário de emissão, expiração e versão do protocolo. O aplicativo deve recusar alertas com assinatura inválida ou campos incompatíveis.
Projete a resposta para falhas de conectividade. Mantenha canais alternativos e mensagens de estado previamente definidas. Se a integridade do serviço estiver em dúvida, o app precisa informar isso claramente, sem inventar uma conclusão sobre a ameaça.
Prepare uma correção e um canal de status. A equipe deve conseguir revogar um alerta, publicar uma correção e explicar o incidente por canais independentes. Um aviso “ignore a mensagem” precisa alcançar as mesmas pessoas, ou mais, que receberam o aviso inicial.
Teste abuso e confusão, não só disponibilidade. Simule alertas duplicados, expirados, destinados a outra região e assinados por uma chave antiga. Faça exercícios com operadores para observar se o processo humano resiste à pressão e a mensagens ambíguas.

Na interface, eu evitaria uma tela que mostre apenas um grande indicador vermelho sem contexto. O usuário precisa ver quem emitiu o alerta, a região, o horário, a validade e o que fazer. Em situações de risco, texto claro e ações objetivas são parte da segurança do produto, não um detalhe de design.

Erros comuns ao criar sistemas de alerta

Confiar apenas no TLS. TLS protege o tráfego em trânsito, mas não impede um sistema autorizado comprometido de enviar conteúdo incorreto.
Colocar segredos dentro do aplicativo. Um segredo compartilhado embutido no cliente pode ser extraído. Para verificar alertas, distribua uma chave pública; mantenha a chave de assinatura no lado protegido do sistema.
Usar uma única conta administrativa. A ausência de separação de funções facilita erros e aumenta o impacto de phishing ou roubo de credenciais. Use autenticação forte, privilégios mínimos e registros auditáveis.
Tratar a entrega do push como garantida. Notificações móveis podem atrasar ou não aparecer. Não prometa que todo usuário receberá a mensagem em tempo real.
Não prever rotação e revogação de chaves. Uma assinatura digital só ajuda enquanto a gestão da chave é confiável. O cliente precisa entender versões de chave e como receber uma atualização segura se uma chave for comprometida.
Usar mensagens de teste indistinguíveis das reais. Testes devem ser claramente identificados e isolados. Um teste mal configurado pode gerar pânico; uma mensagem de teste frequente demais pode ensinar usuários a ignorar alertas.
Corrigir sem explicar. Apagar uma notificação ou publicar uma retratação vaga não restaura confiança. Informe o que se sabe, o que ainda está sendo investigado e qual fonte deve ser acompanhada.

O impacto para quem desenvolve software

O caso descrito pelo BBC News lembra que disponibilidade não é sinônimo de segurança. Um serviço pode estar online e, ainda assim, entregar informação perigosa. Em aplicações financeiras, médicas e de infraestrutura, a mesma lógica se aplica: a integridade do dado e a capacidade de comunicar falhas são tão importantes quanto manter a API respondendo.

Eu usaria esse tipo de incidente como base para revisar o modelo de ameaças. Perguntaria quem consegue criar, aprovar e distribuir uma mensagem; o que acontece se o provedor de push estiver indisponível; como o usuário valida um aviso; e qual procedimento reduz o dano depois de uma publicação indevida. Essas perguntas são mais úteis do que simplesmente adicionar mais uma camada de autenticação sem rever o fluxo inteiro.

Perguntas frequentes sobre segurança de aplicativos de alerta

Uma assinatura digital impediria completamente alertas falsos?

Não. Ela permite verificar se o conteúdo foi assinado por uma chave autorizada e se não foi alterado depois da assinatura. Não garante que o operador tomou uma decisão correta, que a chave não foi comprometida ou que o alerta descreve a realidade.

O FCM ou o APNs autenticam o conteúdo de uma notificação?

Esses serviços participam do transporte da mensagem para dispositivos. Eles não substituem a validação da origem e da autorização do conteúdo pelo sistema que emite o alerta. A aplicação precisa definir como reconhece uma mensagem legítima.

Qual é a melhor alternativa a um aplicativo de alerta?

Não existe um canal único ideal para todos os cenários. Cell broadcast, sirenes, rádio e canais digitais oficiais têm vantagens e limitações diferentes. Para alertas críticos, a estratégia mais resiliente combina canais independentes e informa ao público como confirmar a mensagem.

Como evitar que um alerta antigo seja reutilizado?

Inclua expiração e identificador único no conteúdo assinado. Depois da validação, mantenha um registro dos identificadores processados e rejeite repetições. Em sistemas distribuídos, esse registro precisa ser persistente e sincronizado conforme o nível de risco.

O que o aplicativo deve mostrar quando não consegue confirmar um alerta?

Deve dizer que a autenticidade não pôde ser verificada e orientar o usuário a consultar fontes oficiais alternativas. É mais seguro comunicar a incerteza do que apresentar uma mensagem suspeita como verdadeira ou descartá-la sem explicação.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.