Skip links

As vulnerabilidades mais comuns em aplicações Web: detecção e mitigação

As vulnerabilidades em aplicações web têm se tornado uma preocupação crescente no mercado, especialmente após os incidentes de exploração e ameaças cibernéticas que marcaram o último ano. Um caso que exemplifica este cenário é o ataque recente ao Microsoft Teams, em que criminosos implementaram malwares na aplicação através de uma vulnerabilidade de IDOR.

Tais falhas no sistema frequentemente decorrem da falta de validação das entradas nos formulários, configurações inadequadas dos servidores web e deficiências no design da aplicação. Por meio dessas portas de entrada, um ator mal-intencionado pode comprometer o sistema todo, expondo informações confidenciais de uma organização e causando indisponibilidade na aplicação.

Os danos causados às organizações exploradas por indivíduos mal-intencionados são diversos. Portanto, é fundamental que sejam implementadas medidas que verifiquem o estado da aplicação, como a realização regular de pentests.

Ao compreender a situação do ambiente, torna-se possível identificar os pontos de melhoria que demandam maior atenção e as implementações de segurança necessárias. A execução de um pentest pode revelar potenciais portas de entrada, formulários que não estão realizando as devidas validações, falhas nos controles de segurança e configurações inadequadas nos servidores web.

Vulnerabilidades mais comuns encontradas

A OWASP (Open Web Application Security Project) é uma organização sem fins lucrativos dedicada à listagem e análise de vulnerabilidades exploradas com frequência em aplicações web. A seguir, serão apresentadas as vulnerabilidades mais comuns identificadas e documentadas pela OWASP.

SQL Injection

A vulnerabilidade de Injeção de SQL ocorre quando um indivíduo mal-intencionado consegue acessar e manipular a base de dados de uma aplicação explorando uma falha nos campos de formulários. Isso se manifesta através da inserção de comandos SQL que são interpretados de forma equivocada pela aplicação e executados no banco de dados. Com essa capacidade de manipulação, o atacante pode obter acesso a informações críticas, como o nome das tabelas do banco de dados, seus conteúdos e a interação entre elas. Além de expor dados sensíveis, a falha pode levar a um comprometimento da base de dados e até mesmo a um ataque de negação de serviço (DoS – Denial Of Service).

Além da implementação de um Web Application Firewall (WAF), outras medidas de segurança são fundamentais para minimizar o risco de exploração dessa vulnerabilidade, tais como:

  • Prepared Statements: O banco de dados distinguirá entre código e dados, independentemente da entrada do usuário. Assim, um atacante não pode alterar a intenção de uma consulta. Por exemplo, se o comando tom’ or ‘1’=’1 for inserido no campo de usuários em uma página de login, a query parametrizada procurará um usuário com o nome “tom’ or ‘1’=’1′”, ou retornará apenas o erro de usuário não encontrado.
  • Lista de inputs permitidos: Os valores mapeados dos parâmetros garantem que apenas os nomes de tabela ou coluna esperados sejam utilizados, evitando a inserção maliciosa de dados por parte do usuário. Isso garante que os valores sejam interpretados apenas pelo código, e não por inputs fornecidos pelo usuário.

Teste de Injeção de SQL em Aplicação de Busca

Para avaliar a vulnerabilidade de uma aplicação web responsável pela busca de usuários cadastrados, a equipe de Red Team da Redbelt realizou um teste de Injeção de SQL. Inicialmente, foi inserido o nome de um usuário válido na aplicação, constatando-se que o sistema retornava seu nome e endereço de e-mail. Em seguida, uma série de comandos SQL foi inserida após o nome do usuário, permitindo assim a obtenção de informações sobre os usuários cadastrados, a versão do banco de dados em uso e as tabelas presentes na base de dados.

Figura 1 – Página inicial
Figura 2 – Busca pelo usuário
Figura 3 – Comando SQL inserido extraindo os usuários
Figura 4 – Comando SQL extraindo a versão
Figura 5 – Comando SQL extraindo as tabelas

Em seguida, fizemos um teste em uma aplicação de busca por produtos de uma loja.

Figura 6 – Pesquisa inicial

No momento em que inserimos comandos SQL com o objetivo de o sistema retornar com informações sensíveis da aplicação, essas requisições foram interceptadas por um proxy.

Figura 7 – Comando SQL extraindo informação sensível
Figura 8 – Requisição interceptada pelo proxy

Selecionamos a requisição e a colamos em um arquivo .txt para conduzir a exploração do SQL Injection usando uma ferramenta automatizada chamada sqlmap. A partir disso, instruímos a ferramenta a utilizar as informações contidas no arquivo .txt para executar o script e nos fornecer informações da tabela que armazena os dados de usuário e senha.

Figura 9 – Arquivo .txt com a requisição
Figura 10 – Execução da ferramenta sqlmap
Figura 11 – Tabela extraída

Cross-Site-Scripting (XSS)

A vulnerabilidade de Cross-Site Scripting (XSS) ocorre quando um ator mal-intencionado consegue explorar um campo de inserção de dados que não possui as devidas validações de segurança, permitindo a execução de códigos JavaScript na aplicação. Isso possibilita que o atacante manipule a aplicação para enviar códigos maliciosos aos usuários legítimos, comprometendo suas contas.

Existem 3 tipos de XSS:

  • Reflected XSS: A aplicação recebe dados em uma solicitação HTTP e os inclui na resposta sem validação. Por exemplo, ao acessar uma URL maliciosa, um script pode ser executado no navegador do usuário, permitindo ao atacante obter informações de sessão.
  • Stored XSS: Nesse caso, os códigos maliciosos são inseridos nos campos de entrada e armazenados pela aplicação, como em postagens de blog. Quando um usuário acessa esses comentários, sua segurança é comprometida.
  • DOM-based XSS: Ocorre quando a aplicação processa dados do lado do cliente de forma insegura, geralmente escrevendo esses dados de volta para o DOM.

A seguir, listamos algumas medidas de segurança necessárias para a mitigação do risco de exploração:

  • Validação dos Parâmetros: Filtrar os caracteres permitidos nos campos de entrada para evitar a injeção de comandos JavaScript.
  • Encodar o Output dos Dados: Quando é necessário exibir os dados exatamente como foram inseridos pelos usuários, a codificação dos dados de saída é essencial para evitar que variáveis sejam interpretadas como código ao invés de texto.
  • Flags dos cookies: Embora os atributos de configuração dos cookies não corrijam a vulnerabilidade de XSS, eles oferecem uma camada adicional de segurança para mitigar seu impacto.

Teste de Cross-Site-Scripting em aplicação

Para demonstrar essa prova de conceito (PoC), utilizamos a extensão “Multi Account Containers” para segmentar as guias que seriam empregadas para verificar o sucesso da exploração. Em uma guia, realizamos o envio do payload malicioso, enquanto na outra guia acessamos o painel administrativo onde o payload malicioso seria recebido.

Figura 12 – Configuração dos containers
Figura 13 – Página do Administrador

Na página do usuário que envia o ticket, foi inserido um payload malicioso, permitindo que o atacante receba o cookie da vítima ao receber o ticket.

Figura 14 – Inserção de payload malicioso

Após o envio do ticket, a página do administrador foi recarregada, indicando o sucesso do envio do payload malicioso. Posteriormente, ao acessar a página designada para receber a captura do cookie, que funciona como um webhook, observamos que o cookie foi extraído com sucesso pelo payload.

Figura 15 – Ticket malicioso recebido no painel administrativo
Figura 16 – Cookies capturados

Cross-Site-Request-Forgery (CSRF)

A vulnerabilidade de Cross-Site Request Forgery (CSRF) é explorada através de técnicas de engenharia social, em que um agente mal-intencionado manipula a vítima para realizar ações não intencionais. Por exemplo, o atacante pode enviar uma URL que redireciona a vítima para alterar seu e-mail. Ao clicar na URL, o e-mail previamente cadastrado é substituído pelo e-mail do atacante, concedendo ao mesmo acesso total à conta do usuário legítimo. Para evitar esse ataque, é importante implementar medidas de segurança, tais como:

  • Token Anti-CSRF: Esse token é único, secreto e seu valor é gerado de forma server-side a fim de ser imprevisível, e então compartilhado com o usuário. Dessa forma, ao enviar um formulário, o token do usuário precisa ser o mesmo para ser efetuada a ação.
  • SameSite Cookies: Esse atributo determina quando os cookies de um site são incluídos em solicitações originadas de outros sites. Dessa forma, auxilia na mitigação de possíveis ataques de CSRF.

Teste de Cross-Site-Request-Forgery na aplicação

O primeiro passo para demonstrar essa PoC foi realizar o login na página e interceptar a requisição por meio de um proxy.

Figura 17 – Login legítimo na página
Figura 18 – Requisição interceptada

Após capturar a requisição, identificamos o campo de formulário responsável pela alteração do e-mail. A partir disso, desenvolvemos um código HTML que possibilitaria a atualização automática do e-mail, caso o usuário legítimo acessasse o link malicioso enviado a ele.

Figura 19 – PoC CSRF

Ao abrir o arquivo HTML malicioso, o e-mail da vítima foi atualizado para o e-mail do atacante.

Figura 20 – Alteração de e-mail com sucesso

Security Misconfiguration

A vulnerabilidade de Security Misconfiguration se trata de quando um ator mal-intencionado consegue explorar uma brecha de segurança resultante de uma configuração implementada de maneira incorreta. Por exemplo, se a listagem de diretórios não estiver desabilitada no servidor, o atacante pode efetuar essa listagem e possivelmente obter acesso a arquivos da aplicação.

Sendo assim, é importante realizar a implementação de medidas de segurança, como:

  • Fortificação dos ambientes: Efetuar de forma constante a verificação das implementações de segurança nos ambientes da aplicação.
  • Atualizações: Aplicar as devidas atualizações de todas as notas de segurança.
  • Verificação de acessos: Garantir que nenhuma página de login, como por exemplo uma página administrativa, estejam utilizando credenciais padrão.

               Teste de Security Misconfiguration em aplicação

Para demonstrar essa PoC, acessamos o index /admin da aplicação e, como demonstrado abaixo, foi possível visualizar a listagem dos arquivos presentes nesse ambiente e baixá-los na máquina.

Figura 21 – Listagem de arquivo
Figura 22 – Arquivo acessado

Em outra demonstração, acessamos a aplicação por meio de credenciais padrão.

Figura 23 – Credenciais Padrão
Figura 24 – Login realizado

Broken Access Control

A vulnerabilidade de Broken Access Control (Controle de Acesso Quebrado) ocorre quando um ator mal-intencionado consegue acessar informações de outros usuários e realizar ações para as quais não tem permissão. Isso é possível quando uma aplicação não implementa adequadamente as restrições de acesso às ações dos usuários. O atacante pode explorar essas falhas para manipular tokens de sessão e burlar verificações de permissão. Além disso, ele pode realizar uma escalação de privilégios, comprometer toda a aplicação e causar a indisponibilidade da mesma.

Sendo assim, é importante realizar a implementação de medidas de segurança, como:

  • Mapear as permissões: Realizar a implementação de permissões mapeadas para diferentes tipos de usuários, de forma que seja bem segmentado o que cada tipo poderá realizar. Caso um usuário tente obter acesso a um recurso do qual não é permitido a ele, deve ser redirecionado a uma página de erro.
  • Segurança nos Tokens de Sessão: Certifique-se de que tokens de autenticação sejam gerados de forma segura e não possam ser facilmente manipulados por atacantes para assumir identidades de outros usuários.
  • Princípio do Menor Privilégio: Atribua aos usuários apenas as permissões mínimas necessárias para realizar suas funções. Isso reduz o potencial de acesso não autorizado a recursos sensíveis.

Teste de Broken Access Control em aplicação

Para a demonstração da PoC, foram utilizadas as requisições POST/PUT/GET da aplicação.

Figura 25 – Requisições da API

Ao abrir o terminal, inicializamos a sessão com o usuário Jeremy para obter o token JWT correspondente. Em seguida, repetimos o processo para o usuário Jessamy.

Figura 26 – Login com o usuário Jeremy
Figura 27 – Login com o usuário Jessamy

Com os tokens JWT obtidos para ambos os usuários, acessamos a biografia de Jessamy e a atualizamos. No entanto, para realizar essa atualização, utilizamos o token JWT do usuário Jeremy e inserimos o nome de Jessamy no campo “username”. Como resultado, identificamos que a aplicação permite que um usuário modifique as informações de outro usuário.

Figura 28 – Alteração da biografia
Figura 29 – Alteração bem-sucedida

Data Exposure

A vulnerabilidade de Data Exposure (Exposição de informações sensíveis) se trata de quando um ator mal-intencionado consegue obter acesso a informações sensíveis da aplicação que estavam sendo armazenadas, trafegadas ou manipuladas de forma inadequada, resultando em sua exposição. Essa vulnerabilidade pode ocorrer quando uma aplicação está armazenando e transmitindo as informações sem criptografia, ou até mesmo quando há um vazamento de informações por APIs expostas.

Um atacante pode explorar essas vulnerabilidades para causar uma série de impactos adversos à organização, incluindo violações de privacidade dos usuários, roubo de identidade e interrupções operacionais. Todas essas situações comprometem a integridade e a confiabilidade dos dados da organização aos olhos dos usuários.

Sendo assim, é importante realizar as implementações de medidas de segurança, como:

  • Criptografia dos dados: Dessa forma, os dados em repouso ou em trânsito ficam protegidos de fatores externos.
  • Utilizar HTTPS: Certifique-se de que todas as comunicações entre o cliente e o servidor sejam realizadas por meio de HTTPS, garantindo assim a segurança da transmissão de dados pela internet.
  • Controles de Acessos Adequados: Garanta que apenas usuários autorizados tenham acesso aos dados sensíveis e que as políticas de controle de acesso sejam rigorosamente aplicadas.

Teste de Data Exposure em aplicação

Conforme demonstrado na PoC de Security Misconfiguration, ao acessar o index /admin da aplicação, foi possível realizar a listagem dos arquivos presentes nesse ambiente e baixá-los na máquina. A partir disso, ocorre uma extração de dados expostos da aplicação.

Figura 30 – Listagem de arquivo
Figura 31 – Arquivo acessado

Conclusão

Ao longo deste artigo, foram demonstradas formas de exploração das vulnerabilidades comumente encontradas em aplicações web, bem como as técnicas para detecção e mitigação dessas ameaças. É crucial enfatizar a importância contínua da segurança cibernética no ambiente digital em constante evolução.

Ao considerar os pontos mencionados, uma metodologia a ser seguida é a integração de segurança desde o início do ciclo de vida do desenvolvimento de software, incluindo treinamentos sobre práticas de codificação segura aos desenvolvedores. A conscientização sobre as vulnerabilidades mais comuns é essencial para implementar medidas preventivas adequadas.

Além disso, os testes de segurança em aplicações web são fundamentais para identificar e corrigir vulnerabilidades antes que elas possam ser exploradas por agentes maliciosos. Sendo assim, a execução de Pentests nos ambientes web ajudam a fortificar e garantir um nível elevado de segurança à aplicação.

Em resumo, a detecção e mitigação de vulnerabilidades em aplicações web são processos contínuos e colaborativos que exigem comprometimento e conhecimento especializado. Ao adotar práticas de desenvolvimento seguro, realizar testes regulares e utilizar ferramentas adequadas, as organizações podem fortalecer sua postura de segurança cibernética e proteger seus sistemas e dados contra ameaças emergentes.

Tarsila Mazzutti, consultora Pentester na Redbelt Security

This website uses cookies to improve your web experience.
Explore
Drag