Tecnologias como WebAssembly (WASM), WebGPU e IndexedDB transformaram o que os navegadores conseguem alcançar. Esta evolução expandiu a funcionalidade dos navegadores. No entanto, esta maior complexidade traz também uma preocupação significativa de cibersegurança: uma superfície de ataque ampliada.
Para percebermos onde estamos hoje, vamos fazer uma viagem pela memória.
Lembra-se de quando era preciso o Flash Player para ver conteúdo multimédia rico nos sites? O Adobe Flash foi revolucionário para a sua época, permitindo animações, jogos e aplicações interativas. Mas também era conhecido pelas suas vulnerabilidades de segurança e atualizações frequentes.
Por exemplo, em 2015, a fuga da controversa empresa Hacking Team revelou múltiplas vulnerabilidades de dia zero no Flash Player que foram usadas para atingir utilizadores em todo o mundo. Estas explorações permitiram que os atacantes executassem código arbitrário nas máquinas dos utilizadores, levando a um potencial roubo de dados, instalação de malware, entre outros. O advento do HTML5 e do JavaScript marcou o início do fim do Flash, fornecendo formas 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 em ambiente real. Esta exploração permitiu que os atacantes contornassem restrições de segurança e executassem código arbitrário nos sistemas afetados, levando a infeções generalizadas de malware. O processo de atualização complicado e o surgimento de tecnologias web mais seguras e eficientes, como o HTML5, o CSS3 e as frameworks modernas de JavaScript, levaram ao declínio gradual dos applets Java.
O Microsoft Silverlight é outro exemplo de 2016. A vulnerabilidade CVE-2016-0034 no Silverlight foi encontrada através de dados divulgados do Hacking Team. Esta exploração de dia zero, negociada por um hacker russo, conseguia contornar as proteções do IE e do Firefox.
Um último exemplo vem da Adobe, em 2012, onde foi descoberta uma exploração capaz de comprometer a segurança de computadores a correr o Adobe X e XI (Adobe Reader 10 e 11). Esta vulnerabilidade permitiu que os atacantes contornassem a proteção de sandbox do Reader.
Esta é uma história tão antiga quanto o tempo. Com novos progressos, vêm novos problemas.
Novas vulnerabilidades dos navegadores:
WASM (WebAssembly)
O WASM permite que aplicações de alto desempenho sejam executadas no navegador, possibilitando tarefas como renderização 3D e cálculos complexos. Isto é ótimo para criar aplicações web mais interativas e visualmente atraentes
No entanto, em 2018, investigadores demonstraram como o WebAssembly podia 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. Isto fez com que o script fosse executado nos computadores de milhares de visitantes sem o seu conhecimento. Graças ao WebAssembly, o script funcionava de forma fluida e secreta, usando os dispositivos dos visitantes para minerar criptomoeda.
Em 2021, foi encontrada outra vulnerabilidade no WASM. Esta permitia um stack overflow, através da manipulação do rastreio de tamanho da pilha no Low-Level Interpreter (LLInt). Ao criar uma função WebAssembly que realizava numerosas operações push, era induzido um overflow de inteiro, levando à execução remota de código. Esta exploração, demonstrada na Pwn2Own 2021, tirou partido de fugas de memória e de 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
O WebGPU oferece funcionalidades gráficas de alto nível. Permite que os programadores aproveitem a potência da GPU diretamente a partir do navegador. Isto é ótimo para criar aplicações gráficas detalhadas e jogos diretamente no navegador.
Isto abriu, mais uma vez, um novo caminho para ataques. Em 2022, ocorreu uma vulnerabilidade quando uma página web especialmente criada desencadeou uma condição use-after-free, permitindo potencialmente que um atacante executasse código arbitrário. A Cisco Talos coordenou-se com a 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 podia ser atacado. Preencheram a cache com o seu próprio código usando JavaScript e WebGPU e, depois, observaram quando os seus dados eram removidos da cache ao serem introduzidos. Este método permitiu-lhes analisar as teclas premidas de forma rápida e precisa. Também conseguiram obter chaves usadas para encriptação AES baseada em GPU. Este ataque conseguia até enviar dados secretamente para o exterior a velocidades de até 10 Kb/s.
IndexedDB
O 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 de funcionar offline, como as progressive web apps (PWAs).
Mas, mais uma vez, a maior capacidade 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 permitia que qualquer site rastreasse a atividade de um utilizador na internet e potencialmente revelasse a sua identidade. O problema surgiu devido à violação de uma regra. A regra diz que os nomes das bases de dados devem ser mantidos separados, mas estes eram partilhados entre diferentes sites, permitindo que esses sites vissem que outros sites tinham sido visitados na mesma sessão do navegador.
A Apple resolveu o problema no espaço de uma semana, nas atualizações do macOS Monterey 12.2 e do iOS 15.3.
O cside pode protegê-lo nestes casos?
Na cside, protegemos os seus sites contra scripts de terceiros prejudiciais ou comprometidos. Ao colocar o nosso script acima de todos os outros, encaminhamo-los através do nosso motor de deteção e filtramos autonomamente quaisquer problemas potenciais. Você obtém visibilidade total sobre o que o código está a fazer, incluindo ameaças potenciais. Também otimizamos frequentemente os scripts para que corram mais depressa.
Mas conseguimos ajudar contra os casos mencionados acima?
Os sistemas de deteção exigem atualizações contínuas para identificar variações totalmente novas ou métodos de ocultar informação. Nós preservamos o código solicitado, para que tenha os dados necessários para determinar o que correu mal, quer tenhamos detetado o problema ou não.
Eis como o protegemos hoje contra os ataques mencionados acima:
WASM (WebAssembly): o cside monitoriza e controla a execução de scripts de terceiros. A monitorização específica de WASM está no roteiro para ser adicionada mais tarde, e está a tornar-se uma superfície de ataque cada vez mais perigosa.
WebGPU: conseguimos monitorizar e analisar o comportamento dos scripts e a utilização de recursos, incluindo padrões de acesso à GPU, para detetar anomalias indicativas de ataques de canal lateral. Ao identificar atividade suspeita antes de o navegador renderizar o script, o cside consegue bloquear ou assinalar scripts potencialmente maliciosos antes que estes possam explorar vulnerabilidades, incluindo também recursos da GPU.
IndexedDB: monitorizamos todo o código, o que inclui quaisquer chamadas a APIs sensíveis como o IndexedDB.
Outras boas práticas:
- Atualizações regulares: Mantenha todas as ferramentas instaladas atualizadas para garantir que tem 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 as aplicações web de uma variedade de ataques.
- Eduque os utilizadores: Se possível, forme os utilizadores sobre os riscos de ataques de phishing e engenharia social, que podem comprometer a segurança.
- Reduza os scripts de terceiros: mantenha apenas os que são necessários e tenha um plano claro sobre a quais páginas cada script pode aceder.
- Utilize a Autenticação Multifator (MFA): Use MFA para adicionar uma camada extra de segurança às contas de utilizadores e administradores, dificultando o acesso não autorizado.
- Content Security Policy (CSP): Implemente CSP para prevenir ataques de cross-site scripting (XSS), controlando quais os recursos que o navegador tem permissão para carregar. Lembre-se de que as CSPs têm, por si só, algumas limitações significativas, 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 vão continuar a evoluir. Poder-se-ia argumentar, meio a brincar, que tudo está a transformar-se num navegador, dada a tendência das aplicações móveis se transformarem em Progressive Web Apps (Um artigo detalhado sobre este tema está atualmente em preparação). As PWAs tornar-se-ão mais fluidas, oferecendo uma experiência semelhante à de uma aplicação nativa em todos os dispositivos. Além disso, a maior integração de IA e as melhorias em privacidade e identidade online continuarão a mudar os nossos navegadores.
Estamos a melhorar continuamente os nossos serviços e motores de deteção, para cobrir uma área maior do espaço de segurança do lado do cliente.
Você pode começar e proteger o(s) seu(s) site(s) gratuitamente, atualizando para aceder a mais funcionalidades conforme desejar. Você pode acompanhar o nosso registo de alterações para ver as atualizações e o que está para vir.
Se desejar falar com a nossa equipa de suporte sobre qualquer problema ou preocupação específica, pode fazê-lo aqui.
