Tecnologias como WebAssembly (WASM), WebGPU e IndexedDB transformaram o que os navegadores podem realizar. Esta evolução expandiu a funcionalidade dos navegadores, evoluindo massivamente os casos de uso e experiências. No entanto, essa complexidade aumentada também traz uma preocupação significativa de cibersegurança: uma superfície de ataque ampliada.
Para entender onde estamos hoje, vamos fazer uma viagem pela memória.
Lembra quando você precisava do Flash Player para visualizar conteúdo multimídia rico em sites? O Adobe Flash foi revolucionário para sua época, permitindo animações, jogos e aplicações interativas. Mas também era notório por suas vulnerabilidades de segurança e atualizações frequentes.
Por exemplo, em 2015, o vazamento da controversa empresa Hacking Team revelou múltiplas vulnerabilidades de dia zero no Flash Player que foram usadas para atingir usuários em todo o mundo. Essas explorações permitiram que atacantes executassem código arbitrário nas máquinas dos usuários, levando a potencial roubo de dados, instalação de malware e muito mais. O advento do HTML5 e JavaScript marcou o início do fim para o Flash, fornecendo maneiras mais seguras e versáteis de criar conteúdo web interativo.
Os applets Java também foram atormentados por vulnerabilidades de segurança. Uma violação significativa ocorreu em 2012, quando uma vulnerabilidade de dia zero no Java SE 7 foi descoberta e rapidamente explorada. Essa exploração permitiu que atacantes contornassem restrições de segurança e executassem código arbitrário nos sistemas afetados, levando a infecções generalizadas de malware. O processo de atualização complicado e o surgimento de tecnologias web mais seguras e eficientes como HTML5, CSS3 e frameworks JavaScript modernos levaram ao declínio gradual dos applets Java.
Microsoft Silverlight é outro exemplo de 2016. A vulnerabilidade CVE-2016-0034 no Silverlight, encontrada através de dados vazados do Hacking Team. Essa exploração de dia zero, negociada por um hacker russo, poderia contornar proteções no IE e Firefox.
Um exemplo final vem da Adobe em 2012, onde uma exploração foi descoberta que era capaz de comprometer a segurança de computadores executando Adobe X e XI (Adobe Reader 10 e 11). Esta vulnerabilidade permitiu que atacantes contornassem a proteção de sandbox do Reader.
Esta é uma história antiga. Com novos progressos, vêm novos problemas.
Novas vulnerabilidades de navegador:
WASM (WebAssembly)
WASM permite que aplicações de alto desempenho sejam executadas no navegador, possibilitando tarefas como renderização 3D e computações complexas. Isso é ótimo para criar aplicações web mais interativas e visualmente atraentes.
No entanto, em 2018, pesquisadores demonstraram como o WebAssembly poderia ser usado para criar malware de cryptojacking altamente eficiente que minerava criptomoeda usando os recursos de CPU da vítima.
Um exemplo é quando o script CoinHive, que minera criptomoeda, foi inserido no serviço BrowseAloud. Isso fez com que o script fosse executado nos computadores de milhares de visitantes sem o conhecimento deles. Por causa do WebAssembly, o script operava de forma suave e secreta, usando os dispositivos dos visitantes para minerar criptomoeda.
Em 2021, outra vulnerabilidade no WASM foi encontrada. Ela permitia um estouro de pilha ao manipular o rastreamento de tamanho de pilha no Low-Level Interpreter (LLInt). Ao criar uma função WebAssembly para realizar numerosas operações push, um estouro de inteiro foi induzido, levando à execução remota de código. Essa exploração, demonstrada no Pwn2Own 2021, aproveitou vazamentos de memória e uma cadeia Return-Oriented Programming (ROP) para alcançar execução arbitrária de código. O problema foi corrigido no Safari 14.1.1 (CVE-2021-30734).
WebGPU
WebGPU oferece recursos gráficos de alto nível. Ele permite que desenvolvedores aproveitem a força da GPU diretamente do navegador. Isso é ótimo para criar aplicações gráficas detalhadas e jogos diretamente no navegador.
Isso novamente abriu um novo caminho para ataques. Em 2022, uma vulnerabilidade ocorreu quando uma página web especialmente criada acionou uma condição use-after-free, potencialmente permitindo que um atacante executasse código arbitrário. A Cisco Talos coordenou com o Google para garantir que o problema fosse corrigido nas versões 102.0.4956.0 e 99.0.4844.82 do Chrome.
Em abril de 2024, cientistas da Universidade de Graz e da Universidade de Rennes mostraram que o WebGPU poderia ser atacado. Eles preencheram o cache com seu próprio código usando JavaScript e WebGPU e então observaram quando seus dados foram removidos do cache ao serem inseridos. Este método permitiu que eles analisassem pressionamentos de teclas de forma rápida e precisa. Eles também puderam obter chaves usadas para criptografia AES baseada em GPU. Este ataque poderia até enviar dados secretamente a velocidades de até 10 Kb/s.
IndexedDB
IndexedDB é uma API de baixo nível para armazenar grandes quantidades de dados estruturados, permitindo aplicações offline complexas. Esta tecnologia suporta aplicações web avançadas que precisam funcionar offline, como progressive web apps (PWAs).
Mas novamente, a capacidade aumentada de armazenamento de dados também significa que mais dados sensíveis podem estar em risco.
Por exemplo, em 2022, uma vulnerabilidade na implementação do IndexedDB do Safari 15 permitiu que qualquer site rastreasse a atividade na internet de um usuário e potencialmente revelasse sua identidade. O problema surgiu devido a uma violação de regra. A regra diz que nomes de banco de dados devem ser mantidos separados, mas eles foram compartilhados entre diferentes sites, permitindo que esses sites vissem quais outros sites foram visitados na mesma sessão do navegador.
A Apple resolveu o problema em uma semana nas atualizações macOS Monterey 12.2 e iOS 15.3.
O cside pode proteger você nesses casos?
Na cside, protegemos seus sites contra scripts de terceiros prejudiciais ou comprometidos. Ao colocar nosso script acima de todos os outros, nós os enviamos através de nosso mecanismo de detecção e filtramos autonomamente quaisquer problemas potenciais. Você obtém visibilidade completa do que o código está fazendo, incluindo ameaças potenciais. Além disso, frequentemente otimizamos os scripts para executar mais rapidamente.
Mas podemos ajudar contra os casos mencionados acima?
É desnecessário dizer que sistemas de detecção requerem atualizações contínuas para identificar variações ou métodos completamente novos de ocultar informações. Importante saber é que preservamos o código solicitado, permitindo-nos fornecer os dados necessários para determinar o que deu errado, independentemente de termos identificado o problema ou não.
Dito isso, aqui está como podemos protegê-lo hoje dos ataques mencionados acima:
WASM (WebAssembly): o cside monitora e controla a execução de scripts de terceiros. O monitoramento específico de WASM está no roteiro para ser adicionado posteriormente e está se tornando uma superfície de ataque cada vez mais perigosa.
WebGPU: podemos rastrear e analisar o comportamento do script e o uso de recursos, incluindo padrões de acesso à GPU, para detectar anomalias indicativas de ataques de canal lateral. Ao identificar atividade suspeita antes que o navegador renderize o script, o cside pode bloquear ou sinalizar scripts potencialmente maliciosos antes que possam explorar, incluindo também recursos de GPU.
IndexedDB: monitoramos o código completo, que inclui quaisquer chamadas para APIs sensíveis como IndexedDB.
Outras melhores práticas:
- Atualizações Regulares: Mantenha todas as ferramentas instaladas atualizadas para garantir que você tenha os patches de segurança mais recentes. Remova quaisquer scripts não utilizados.
- Web Application Firewalls (WAF): Implemente WAFs para adicionar uma camada extra de segurança, protegendo aplicações web de uma variedade de ataques.
- Eduque os Usuários: Se possível, treine usuários sobre os riscos de ataques de phishing e engenharia social, que podem levar à segurança comprometida.
- Reduza scripts de terceiros: importe apenas aqueles que são cruciais e tenha um plano claro sobre em quais páginas tais scripts devem ter acesso.
- Empregue Autenticação Multifator (MFA): Use MFA para adicionar uma camada extra de segurança às contas de usuário e administrador, tornando o acesso não autorizado mais difícil.
- Content Security Policy (CSP): Implemente CSP para prevenir ataques de cross-site scripting (XSS) controlando quais recursos o navegador tem permissão para carregar. Lembre-se de que CSPs têm algumas limitações significativas por si só, sobre as quais escrevemos mais [aqui](https://cside.com/compare#:~:text=Detecting%20Scripts-,Content%20Security%20Policies%20(CSP%29,-JS%20Based).
Como será o futuro do navegador?
Os navegadores continuarão a evoluir. Pode-se argumentar meio brincando que tudo está se transformando em um navegador, dada a tendência de aplicativos móveis se transformarem em Progressive Web Apps (Um artigo detalhado sobre este tópico está atualmente em andamento). PWAs se tornarão mais integrados, oferecendo uma experiência semelhante a aplicativos nativos em todos os dispositivos. Além disso, a maior integração de IA e melhorias em privacidade e identidade online continuarão a moldar nossos navegadores.
Fique tranquilo, estamos desenvolvendo para o futuro e melhorando continuamente nossos serviços e mecanismos de detecção para cobrir uma área maior do espaço de segurança do lado do cliente.
Você pode começar e proteger seu(s) site(s) gratuitamente, atualizando para acessar mais recursos conforme desejar. Você pode monitorar nosso registro de alterações para ver atualizações e potenciais desenvolvimentos futuros.
Se você deseja falar com nossa equipe de suporte sobre qualquer problema ou preocupação específica, você pode fazê-lo aqui.
