Aqui no blog muito se fala sobre a OWASP, mas afinal, o que é a OWASP? Onde vive? O que come? Como se reproduz? 

Segundo a própria organização em seu documento oficial (https://owasp.org/www-pdf-archive/OWASP_Top_10-2017-pt_pt.pdf), a "OWASP - Open Web Application Security Project" é uma comunidade aberta dedicada a permitir que as organizações desenvolvam, adquiram e mantenham aplicações e APIs confiáveis.

A OWASP disponibiliza de forma livre e aberta:

Ferramentas e normas de segurança aplicacional;

Livros completos sobre testes de segurança aplicacional, desenvolvimento de código seguro e revisão de código focada em segurança;

Apresentações e vídeos;

Cheat sheets sobre assuntos diversos;

Controles e bibliotecas de segurança standard;

Capítulos locais espalhados por todo o mundo;

Investigação de ponta;

Múltiplas conferências a nível mundial;

Listas de discussão

Podemos ver então que a OWASP é diferente do que muita gente pensa. Ela não é um framework de segurança, não é um documento de padronização de relatório e nem é um checklist de vulnerabilidades (apesar de conter documentação em tópicos sobre possíveis testes de segurança). 

 

As informações apresentadas pela OWASP estão em constante evolução e traz dados muito concisos sobre as vulnerabilidades que existem e que estão surgindo, como elas funcionam e como podem ser exploradas apresentando também seu grau de risco e complexidade de exploração. Por isso as documentações apresentadas são utilizadas por grande parte das empresas e organizações que priorizam a segurança de suas aplicações, desde o processo de escrita do código, até as empresas que a utilizam como guia para execução de testes e análises de vulnerabilidades em aplicações Web.

A Site Blindado enaltece o trabalho da comunidade e a utiliza como base para argumentações ligadas aos testes de invasão realizados. Por isso, apresentamos a seguir a lista Top 10 das vulnerabilidades mais comumente encontradas, e exploradas, segundo a OWASP. Para tal, utilizamos o documento publicado em 2017 já referenciado no início deste artigo. São eles:

 

A01 - Injeção

A02 - Quebra de Autenticação

A03 - Exposição de Dados Sensíveis

A04 - Entidades Externas de XML (XXE)

A05 - Quebra de Controle de Acessos

A06 - Configuração de Segurança Incorreta

A07 - Cross-Site Scripting (XSS)

A08 - Desserialização Insegura

A09 - Utilização de Componentes Vulneráveis

A10 - Registro e Monitoração Insuficiente 

 

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.

Acontece quando através de um campo de entrada pelo usuário um código malicioso é enviado e o interpretador do mesmo "entende" o dado enviado como parte do seu código executando-o. 

Qualquer dado externamente pela aplicação pode ser um vetor de injeção, desde variáveis de ambiente e parâmetros até entradas de usuário na Web.

A injeção mais comum é a de consulta a de banco de dados (SQLi) onde ao entrar com um termo a ser buscado pela aplicação, a aplicação sem tratamento de entrada, envia ao banco de dados códigos maliciosos de consulta enviados pelo usuário mal intencionado.

É interessante mencionar que o XSS (Cross-Site Scripting) mesmo tendo uma sessão única destinada a ela também pode ser considerado uma injeção visto que o interpretador da aplicação executa códigos enviados à aplicação.

Exemplo:

No exemplo a seguir a busca disponibilizada na aplicação permite que se envie chamadas que são interpretadas internamente pelo servidor enviando informações de sua implementação como resposta.

Uma vez evidenciada a resposta da aplicação é necessário conhecer seu funcionamento para obter informações mais profundas sobre sua implementação, obtenção de dados e etc.

A implementação incorreta de meios de autenticação e gestão de sessão expõem a aplicação a permissionamentos incorretos, acessos indevidos e possibilidade de não-repúdio (se passar por outra pessoa).

Ataques de força bruta, permitir o uso de senhas fracas pelos usuários, permitir palavras chaves conhecidas em nomes de usuários e senhas e implementação de tokens que não expiram são exemplos de testes realizados para a quebra da autenticação.

Exemplo:

Esta imagem demonstra um ataque de força bruta evidenciando que a aplicação não trata a quantidade de requisições a um único usuário. O atacante manipula os dois últimos dígitos de sua própria senha entre 00 e 99 para verificar se seu teste será barrado depois de uma quantidade estipulada de tentativas.

Seja por injeção, quebra de autenticação ou qualquer outro meio de burlar a segurança de uma aplicação chegar até um dado sensível é bem ruim, mas é ainda pior quando esses dados não possuem camadas extras de segurança e o atacante consegue acesso diretamente ao dado legível. É necessário incluir então camadas de criptografia forte tanto no seu armazenamento quanto no seu tráfego.

Exemplo:

Esta requisição possui um ID de usuário para retorno de informações

A chamada retorna uma foto do usuário e dados pessoais do mesmo

...Obtém-se as informações de outro usuário cadastrado na aplicação a que não deveríamos ter acesso

Esta série de posts sobre a OWASP será divida em 3 partes, porém, com apenas estas primeiras três categorias de falhas já é possível identificar diversas aplicações que não possuem mecanismos de mitigação para elas. O assunto é muito mais profundo do que o apresentado aqui, por isso recomendamos fortemente a leitura da documentação. Conta pra gente se você já conhece a OWASP e como você aplica ela ao seu trabalho/dia-a-dia hoje. Aguardamos seu comentário.