Push Notifications: O Novo Canal Silencioso para Ataques

A Ameaça Silenciosa que Passa Despercebida

As notificações Web Push fazem parte do dia a dia de muitas aplicações modernas. Elas aparecem em ferramentas de colaboração, alertas de sistemas e até em apps que precisam manter o usuário informado em tempo real. Mas e quando esse mesmo recurso vira uma brecha para ataques que ninguém vê?

É exatamente isso que acontece com a vulnerabilidade Sleeping Agent. Ela aproveita uma falha no jeito como os navegadores verificam as regras de segurança da Web Push API.

Como o Ataque Funciona

A Web Push API tem uma exigência importante: userVisibleOnly: true. Essa configuração deveria garantir que toda mensagem push gerasse uma notificação visível para o usuário.

Na prática, o navegador não verifica isso direito.

O ataque Sleeping Agent funciona assim: um Service Worker malicioso recebe um evento push e executa duas ações quase ao mesmo tempo. Primeiro ele exibe uma notificação com showNotification(). Logo em seguida, ele a fecha com notification.close().

A notificação entra e sai tão rápido que o usuário não percebe. No entanto, o navegador registra que ela foi mostrada porque consulta o banco de dados interno, não o que aparece de verdade na tela. O resultado? O canal de comunicação do atacante continua ativo, sem deixar rastro.

Por Que Isso é Preocupante

Essa falha vai além de uma simples bypass. Ela enfraquece a confiança na Web Push API como um todo:

• Persistência silenciosa: O atacante mantém um canal aberto sem o usuário saber. Basta uma visita a um site comprometido.
• Evasão de compliance: Muitos controles de segurança dependem de notificações visíveis. Esse ataque anula essa proteção.
• Impacto em vários navegadores: Chrome, Edge e até versões antigas do Safari estão expostas.
• Fácil de explorar: O ataque pode ser reproduzido em poucos minutos, sem ferramentas complexas.

Análise Técnica

O problema está no momento em que o navegador faz a verificação. Ele checa depois que o Service Worker já terminou sua execução. Na prática:

1. O evento push chega
2. O Service Worker mostra e fecha a notificação rapidamente
3. O navegador consulta o banco de dados e vê que algo foi registrado
4. A verificação passa, mesmo sem nada visível na tela

A janela de tempo é pequena, mas consistente o suficiente para ser explorada.

O Que os Entrevistadores Devem Fazer

Se você desenvolve aplicações que usam Web Push, considere essas perguntas:

• Seus Service Workers estão revisados? Um script de terceiros comprometido pode transformar sua aplicação em uma brecha.
• Você monitora as notificações? Acompanhar o comportamento de showNotification() e close() pode revelar padrões suspeitos.
• Você verifica a origem dos push messages? Usar verificação criptográfica ajuda a confirmar que as mensagens vêm de servidores legítimos.

Implicações Maiores

A vulnerabilidade mostra que a intenção da especificação nem sempre se traduz em segurança real. A W3C diz que os navegadores devem garantir que as notificações sejam visíveis, but the enforcement mechanism checks the wrong thing.

Essa discórdia entre o que o navegador deveria fazer e o que ele realmente faz é uma falha que pode ser exploitada.

Próximos Steps

Os vendors de navegadores estão cientes e estão trabalhando em patches. Para quem usa Web Push em produção:

1. Monitorar o comportamento dos Service Workers para padrões suspeitos
2. Verificar no servidor se as mensagens push vêm de fontes confiáveis
3. Atualizar os navegadores para receber os patches de segurança
4. Avaliar o threat model da sua aplicação quando usar Web Push

Web Push continua sendo um recurso útil. But like any powerful platform feature, it requires careful consideration of both its benefits and its attack surface.

The Sleeping Agent vulnerability is a wake-up call—literally—that even well-intentioned safety mechanisms can have gaps worth exploiting. Staying informed and implementing defense-in-depth practices is how we keep our applications and users protected.