Top 10 vulnerabilidades encontradas em pentests de aplicações web

Muitas empresas utilizam soluções web para interagir com os seus clientes. No entanto, esta exposição na web pode ser explorada por atacantes para se infiltrarem em redes corporativas e obterem informações sensíveis. Para evitar esta situação, a segurança das aplicações web deve ser uma preocupação central e uma das melhores formas de a assegurar é através de testes de penetração (pentesting). 

Os testes de penetração são concebidos para replicar o cenário real dos atacantes, testando a postura de segurança das aplicações web e atacando todas as vulnerabilidades conhecidas antes de os adversários reais terem oportunidade de o fazer.

Abaixo listamos as 10 principais vulnerabilidades web encontradas durante os nossos testes de penetração, acompanhadas por uma breve explicação sobre como podem ser exploradas e atenuadas.

1) Cross-Site Scripting (XSS) – armazenado e refletido

As vulnerabilidades XSS permitem que os atacantes injetem scripts maliciosos em páginas web, potencialmente afetando todos os utilizadores que visualizam ou interagem com essas páginas. Os XSS mais comuns são:

• XSS refletido: Quando um utilizador clica num URL malicioso criado pelo atacante, o código JavaScript dentro do URL é executado. Como o código não está armazenado no servidor, o atacante tem de encorajar as pessoas a clicar num link, utilizando, por exemplo, engenharia social.
• XSS armazenado: O código malicioso é armazenado na base de dados e executado sempre que um utilizador acede a uma página que o utiliza.

Exploração: No caso de um ataque XSS armazenado, um atacante pode inserir código malicioso num comentário ou num campo de formulário, que é executado quando outro utilizador visualiza o conteúdo. O XSS refletido ocorre quando um atacante cria um URL que contém código malicioso e engana um utilizador para que este clique nele.

Recomendação: Implementar uma validação rigorosa dos inputs e uma codificação dos outputs para evitar o XSS. Higienizar todos os inputs do utilizador e escapar dos outputs. Além disso, utilizar Políticas de Segurança de Conteúdos (CSP – Content Security Policies) para reduzir o risco de execução de scripts não autorizados.

2) Cross-Site Request Forgery (CSRF)

O CSRF pode ser utilizado para enganar os utilizadores verificados, levando-os a realizar ações indesejadas numa aplicação web, tais como completar transações ou alterar informações da conta. Este ataque explora a incapacidade da aplicação web para verificar a origem do pedido e a sessão autorizada do utilizador.

Exploração: Um atacante cria um formulário ou uma ligação maliciosa. Quando a vítima utiliza a ligação ou o formulário, envia um pedido à aplicação web vulnerável, utilizando os cookies da vítima. Este pedido pode realizar todas as ações que o utilizador pode realizar na aplicação, o que pode comprometer a sua conta.

Recomendação: Existem vários métodos para mitigar o risco de CSRF, pelo que recomendamos a utilização do maior número possível deles. Os métodos mais populares são os tokens anti-CSRF, a utilização de cabeçalhos personalizados e a utilização de cookies de sessão com o atributo SameSite=Strict.

3) Configuração incorreta do CORS

Por defeito, as aplicações não podem comunicar em JavaScript com aplicações de outros domínios. O Cross-Origin Resource Sharing (CORS) pode ser utilizado para modificar este comportamento. Uma configuração incorreta pode tornar a aplicação vulnerável ao acesso não autorizado de outros domínios.

Exploração: Os erros de configuração mais frequentes são a configuração incorreta de “Access-Control-Allow-Origin”, que, se for demasiado permissivo, utiliza um wildcard (*), ou o valor nulo, e permite a realização de pedidos a partir de domínios não controlados. Se, além disso, a aplicação utilizar “Access-Control-Allow-Credentials: True”, então um atacante pode fazer pedidos a partir das sessões dos utilizadores, roubando assim as suas contas, porque, ao contrário dos ataques CSRF, o atacante pode ler os resultados destes pedidos.

Recomendação: Evitar a utilização de wildcards ou “null” no cabeçalho “Access-Control-Allow-Origin”. Restringir os pedidos CORS a domínios fiáveis e evitar pedidos credenciados de origens não fiáveis.

4) Insecure Direct Object References (IDOR)

O IDOR ocorre quando uma aplicação expõe referências internas a objetos, como chaves de bases de dados ou caminhos de ficheiros. Os atacantes podem manipular estas referências para aceder a dados não autorizados.

Exploração: Se um utilizador tiver acesso ao documento 123, pode tentar modificar o URL ou o corpo do pedido para aceder aos documentos de outros utilizadores. Por exemplo, pode procurar o documento 122.

Recomendação: Implementar verificações de controlo de acesso do lado do servidor para garantir que os utilizadores só podem aceder a dados autorizados. Evitar expor identificadores sensíveis nos URL e utilizar referências indiretas ou tokens de acesso.

5) Vulnerabilidades no upload de ficheiros

Permitir que os utilizadores carreguem ficheiros pode acarretar riscos de segurança, se não for devidamente gerido. Muitas aplicações dependem da validação do lado do cliente, que é facilmente contornada.

Exploração: Os atacantes podem fazer upload de ficheiros maliciosos, como um ficheiro HTML que contenha JavaScript ou um script do lado do servidor, como PHP, ganhando potencialmente o controlo do servidor. Podem também carregar ficheiros muito grandes para saturar o armazenamento do servidor, ou ficheiros que, uma vez descarregados, são perigosos, como ficheiros DOCM ou EXE.

Recomendação: Efetuar uma validação rigorosa do lado do servidor dos ficheiros carregados, verificando o tipo de ficheiro, o tamanho e o conteúdo. Armazenar os ficheiros num diretório não executável e utilizar nomes de ficheiro aleatórios.

6) Redirecionamento aberto

Uma vulnerabilidade de redirecionamento aberto ocorre quando uma aplicação permite que os utilizadores sejam redirecionados para URL externos sem a devida validação, muitas vezes com base na entrada do utilizador.

Exploração: Um atacante pode criar um URL de aspeto legítimo que redireciona os utilizadores para um website malicioso, podendo levá-los a visitar sites nocivos, como páginas de phishing. Em alguns redirecionamentos, também é possível adicionar código JavaScript em vez do URL.

Recomendação: Evitar redirecionamentos abertos sempre que possível. Se necessário, validar e colocar na lista branca os domínios permitidos, ou limitar os redirecionamentos a um conjunto predefinido de URL fiáveis.

7) Vulnerabilidades JWT

Os JSON Web Tokens (JWT) são amplamente utilizados para autenticação em aplicações web, mas uma implementação incorreta pode conduzir a riscos de segurança.

Exploração: Se uma aplicação não conseguir verificar a assinatura de um JWT, os atacantes podem manipular o token para alterar declarações, como a identidade ou a função do utilizador. Assim, mesmo sem uma conta na aplicação, o atacante pode obter um token de administrador que nunca expira.

Recomendação: Verificar sempre as assinaturas JWT, utilizando algoritmos seguros (por exemplo, HS256, RS256), e garantir que os tokens são assinados com uma chave secreta forte. Impor tempos de expiração rigorosos.

8) Componentes com vulnerabilidades conhecidas

As aplicações web dependem frequentemente de bibliotecas externas, que podem ter vulnerabilidades de segurança. Se determinados componentes não forem atualizados, a aplicação pode tornar-se vulnerável.

Exploração: Os atacantes podem explorar vulnerabilidades conhecidas em componentes desatualizados para comprometer o sistema.

Recomendação: Atualizar regularmente bibliotecas e frameworks de terceiros. Aplicar imediatamente patches de segurança e remover as dependências não utilizadas.

9) Armazenamento inseguro de tokens de sessão

O armazenamento de tokens de sessão em locais inseguros, como o armazenamento local ou de sessão, expõe-nos ao potencial roubo por parte de agentes maliciosos. Estes tokens são essenciais para manter as sessões dos utilizadores e, se forem comprometidos, um atacante pode desviar a sessão, fazer-se passar pelo utilizador e obter acesso a informações sensíveis.

Exploração: Os atacantes podem explorar vulnerabilidades XSS (cross-site scripting) para roubar tokens de sessão armazenados no armazenamento do navegador. Além disso, os tokens armazenados nestas localizações são vulneráveis a ataques baseados no browser, tais como malware do lado do cliente ou extensões do browser.

Recomendação: Preferir cookies com sinalizadores Secure, HttpOnly e SameSite em vez de outros mecanismos de armazenamento, para torná-los inacessíveis ao JavaScript e, por conseguinte, protegidos de ataques XSS.

10) Injeção de SQL (SQLi)

As vulnerabilidades de injeção de SQL permitem aos atacantes executar queries maliciosos através da injeção de código SQL nos campos de input.

Exploração: Os atacantes podem inserir comandos SQL maliciosos para aceder, modificar ou eliminar dados, contornar a autenticação ou executar comandos no servidor.

Recomendação: Utilizar instruções preparadas e consultas parametrizadas para evitar a injeção de SQL. Validar e higienizar todos os inputs, e evitar construir queries SQL ao concatenar os inputs do utilizador.