OWASP Top 10 - Parte 2
Dando continuidade a série de posts sobre a OWASP Top 10, vimos as 3 primeiras categorias de vulnerabilidades Web mais exploradas.
Lembrando que devido a complexidade de alguns dos tópicos, este artigo se dividirá em 3 para apresentarmos da melhor forma possível os conceitos de cada um deles.
Para quem ainda não leu o primeiro post, vale visitar a página do artigo (OWASP Top 10 Pt1) para entender o que é a OWASP, as informações que são apresentadas e entender as primeiras vulnerabilidades da lista. A seguir apresentaremos as próximas 4 vulnerabilidades da lista.
Seguindo em frente então, temos:
A04 - Entidades Externas de XML (XXE)
A05 - Quebra de Controle de Acessos
A06 - Configuração de Segurança Incorreta
A07 - Cross-Site Scripting (XSS)
A04 - Entidades Externas de XML (XXE)
Já mencionada aqui em nosso Labs (http://labs.siteblindado.com/2019/02/xml-external-entity-xxe.html) a vulnerabilidade consiste na exploração de informações modificadas por meio de XML e enviadas a um servidor vulnerável. Um arquivo XML "é um tipo de Linguagem de Marcação usado para definir padrões e formatos de exibição dentro de um documento, ou seja, definem como um determinado conteúdo vai ser visualizado na tela ou como os dados serão distribuídos." (Fonte: https://canaltech.com.br/software/xml-o-que-e/). Dessa maneira, uma aplicação que se utiliza de um XML pode receber e informações por meio um tipo de "layout de documento" pré-definido. Uma das característica do XML é permitir que o desenvolvedor referencie dados armazenados local ou remotamente a um dado endereço, dessa maneira, um atacante pode modificar um arquivo XML e enviá-lo a um servidor que espera receber um XML legítimo para consulta, porém, ao processar o XML modificado, ele acaba processando elementos dos quais não deveriam ser referenciados em sua execução.
Este é o exemplo de um XML modificado de modo que a aplicação responda a requisição desse documento com o arquivo de senhas do sistema operacional Unix (/etc/passwd).
Prevenção: Em linhas gerais, a recomendação mais encontrada em documentações na internet é a não utilização de XML para este tipo de comunicação. Caso seja necessário o seu uso, a tratativa pode não ser tão simples e é necessário consultar documentações específicas das bibliotecas utilizadas para fazer o "parse" dos arquivos XML.
A05 - Quebra de Controle de Acessos
Esta seção descreve como a aplicação lida com a concessão de acesso e funcionalidades do sistema entre seus usuários', logo, ela abrange todo e qualquer tipo de ataque que possa ser usado para obter acesso a um recurso ao qual o usuário não deveria ter acesso, desde uma requisição simples sem autenticação a lista de usuários (por exemplo) até ataques de injeção que possam burlar o mecanismo de login do sistema concedendo acesso a um usuário mal-intencionado.
No exemplo a seguir vemos um usuário (ID:3347) utilizando a requisição de troca de senha e a seguir a mesma requisição sendo utilizada para ressetar a senha de um outro usuário.
Esta é a requisição e a resposta confirmando que a senha do usuário foi alterada com sucesso.
Interceptando a requisição e alterando-a para o usuário com ID 3348 recebemos a confirmação de que a senha do usuário também foi alterada com sucesso evidenciando a ausência de mecanismos de autorização.
Prevenção: Mapear de forma processual todo e qualquer perfil de acesso ao sistema antes de implementá-los. Atentar-se a falhas conhecidas em alguns mecanismos de autenticação e autorização implementados. Realizar testes periódicos e aplicar as alterações de segurança necessárias para que se diminua a possibilidade de quebra dos mecanismos de autenticação.
A06 - Configuração Incorreta de Segurança
Esta seção abrange todo tipo de configuração aplicada (ou não) que possa levar a brechas de segurança. Entram neste meio boas práticas de segurança (alterar a senha de usuário administrador, desativar contas padrões da aplicação, entre outros), a não aplicação de configurações recomendadas de segurança (aplicação desatualizada, desligar acesso a serviços que não são utilizados no servidor, entre outros) e até mesmo a aplicação de recursos que possam levar a brechas de segurança (habilitar página padrão de página com acesso negado contendo informações sensíveis de implementação do sistema, entre outros)
Esta página de erro padrão implementada pelo servidor Web contém dados como o caminho interno da aplicação e o módulo que gerou o erro, informações estas que podem ser utilizados para enumerar pastas do sistema em caso de falhas graves onde o atacante ganhe acesso ao servidor do alvo.
A página de administração do Tomcat, por exemplo, presente na porta 8080 pode levar um atacante a utilizar usuários e senhas padrões como tentativa de acesso ao servidor Web. Ainda que os usuários padrões estejam desativados e utilizem-se senhas complexas para acesso, não é interessante deixar aberto a porta 8080 para acesso aberto a internet visto que é uma console de administração e deve ser acessada por usuários específicos.
Prevenção: Encontrar e seguir toda documentação dos sistemas conhecidos que forem utilizados pela aplicação e aplicar as melhores práticas de segurança. Atentar-se as configurações padrões e modificações que devem ser realizadas na aplicação que podem levar ao vazamento de informações sobre a plataforma. Realizar testes periódicos na aplicação para diminuir o máximo possível as informações que possam estar expostas.
A07 - Cross-Site Scripting (XSS)
Essa que é uma das vulnerabilidades mais antigas em destaque na Top 10 da OWASP é muito parecida com a vulnerabilidade A01 - Injeção, porém, é específico para injeção de códigos HTML e Javascript que podem ser interpretadas e executadas pela aplicação. Existe um post aqui do labs sobre a vulnerabilidade e como explorá-la (XSS - Guia Explicativo), o guia explica os seus tipos e como podem ser exploradas. É interessante notar como um post de 2014 continua tão atual.
Abaixo apresentamos um exemplo simples de XSS Armazenado e em seguida um ataque de phishing utilizando a vulnerabilidade para roubar a sessão da vítima.
Utilizando o campo "Editar" de um recurso presente em um sistema é possível inserir qualquer tipo de texto, inclusive caracteres especiais o que também torna possível o envio de tags e linhas de código em Javascript. Lembrando que, mesmo que o sistema limite o uso de caracteres especiais no frontend, pode-se utilizar um proxy para interceptar a comunicação entre o navegador e o servidor e modificar a requisição incluindo os caracteres especiais no envio do pacote.
Confirmada a presença da falha, utilizamos um servidor externo contendo um código em PHP que captura o cabeçalho de requisições HTTP enviada a ele e com isso conseguimos obter acesso ao cookie de sessão do usuário que está logado.
Com este cookie em mãos, o atacante pode copiar o valor dele e injetá-lo em seu próprio navegador. Ao realizar qualquer requisição ao sistema com o valor deste cookie o sistema entende que aquela é a mesma sessão logada que consta em seus registros, logo, o atacante obtem acesso ao sistema com o login do usuário que foi alvo do ataque.
Vale ressaltar que o ataque foi possível pela ausência de vários mecanismos de proteção. A raiz do problema aqui é deixar de filtrar toda e qualquer informação recebida como entrada de dados do usuário, porém, existem flags de cabeçalho de requisição e proteções de cookie que podem ajudar na mitigação da vulnerabilidade.
Prevenção: As mitigações primárias e mais efetivas são validação de entrada do usuário (filtro de caracteres especiais, por exemplo), validação dos dados de entrada utilizando whitelist de palavras chave, aplicação de flags de headers de segurança (X-XSS-Protection, etc) e de proteção de cookie (httponly, secure, samesite).
Conclusão
Dando continuidade a esta série de posts sobre a OWASP vimos mais 4 outras seções que abrangem vulnerabilidades de alto risco aos sistemas WEB. Seguimos dizendo que o assunto é muito mais profundo do que o apresentado aqui, por isso recomendamos fortemente a leitura da documentação.
A propósito, a versão 2021 da OWASP já está disponível em https://owasp.org/Top10/. A maior parte das seções descritas nesta série de artigos foi mantida, algumas incorporadas a outras seções e 3 novas seções foram criadas.
De qualquer forma, após falarmos sobre todas as seções do documento de 2017, prepararemos um artigo sobre o que mudou e quais são estas novas seções incluídas no documento de 2021.
Sobre as seções apresentadas neste artigo, a mais famosa é a de XSS, mas você já conhecia as demais? Já chegou a testá-las em algum sistema? Aguardamos seu comentário.
0 comentários: