OWASP Top 10 - Exemplificando alguns cenários

O que é OWASP – Open Web Application Security Project?

Uma comunidade de devs, cientistas e especialistas em ciber segurança que trocam conhecimentos e disponibilizam gratuitamente uma lista das principais vulnerabilidades em sistemas web.

Essa lista é atualizada anualmente, segue um ranking com as 10 brechas mais críticas, mais comuns e perigosas que estão sendo mais exploradas naquele ano. E é conhecida por OWASP – TOP 10.

O material original possui tradução para o português, na versão de 2021.

Nesse artigo, por meio de exemplos tento esclarecer do que se trata cada um desses itens da lista:

Lista top 10:2021

• A01 Quebra de Controle de Acesso;
• A02 Falhas Criptográficas;
• A03 Injeção;
• A04 Design Inseguro;
• A05 Configuração Incorreta de Segurança;
• A06 Componentes Vulneráveis e Desatualizados;
• A07 Falha de Identificação e Autenticação;
• A08 Falha de Integridade de Software e Dados;
• A09 Log de Segurança e Falha de Monitoração;
• A10 Server Side Request Forgery (SSRF).

O material completo da lista vai categorizar os riscos e explicar o que é cada vulnerabilidade, como é possível prevenir-se, e também vai trazer alguns exemplos do cenário de ataque. Fazer uma aplicação que seja 100% segura, não é impossível, mas é muito difícil, porque em quase toda aplicação prática aparece uma falha de segurança, mesmo em sistema operacional, Android, Iphone, ninguém está totalmente invulnerável à falha de segurança.

1.Quebra de Controle de Acesso: O aplicativo usa dados não verificados em uma chamada SQL que está acessando informações da conta:

pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults=pstmt.executeQuery( );

Um invasor simplesmente modifica o parâmetro “acct” do navegador para enviar o número de conta que desejar. Se não for verificado corretamente, o invasor pode acessar a conta de qualquer usuário – no sistema bancário, por exemplo, descobre-se que pode colocar arbitrariamente qualquer número de conta.

https://example.com/app/accountInfo?acct=notmyacct (coloca-se outra conta, um parâmetro arbitrário e a quebra (“acct”) aceita esse parâmetro arbitrário, pois confia que o usuário não vai mexer na URL onde quebrou a segurança. Muda-se um padrão URL para uma conta arbitrária).

2.Falhas Criptográficas: um aplicativo criptografa números de cartão de crédito em um banco de dados usando criptografia automática de banco de dados. No entanto, esses dados são automaticamente descriptografados quando recuperados, permitindo que uma falha de injeção de SQL recupere números de cartão de crédito em texto não criptografado.

– Usou-se o HTTPS para transferir os dados e o banco de dados utiliza uma criptografia para armazenar e salvar o arquivo, mas alguém conseguiu fazer uma injeção de SQL e o próprio banco de dados descriptografou o dado para a outra pessoa.

3.Injeção:  um aplicativo usa dados não confiáveis na construção da chamada SQL vulnerável:

String query = “SELECT \* FROM accounts WHERE custID=’” + request. getParameter(“id”) + “’”;

4. Design Inseguro: um site de comércio eletrônico de uma rede de varejo não tem proteção contra bots executados por cambistas que compram placas de vídeo de última geração para revender sites de leilão. Isso cria uma publicidade terrível para os fabricantes de placas de vídeo e proprietários de redes de varejo, além de sofrer com os entusiastas que não podem obter essas placas a qualquer preço. O design anti-bot cuidadoso e as regras de lógica de domínio, como compras feitas dentro de alguns segundos de disponibilidade, podem identificar compras não autênticas e rejeitar tais transações.

O sistema se protege contra o usuário que está tentando ser um “cambista”. No mundo real, já acontece isso. E deixar que isso aconteça é um design falho. 

5.Configuração Incorreta de Segurança: um provedor de serviços de nuvem tem permissões de compartilhamento padrão abertas para a Internet por outros usuários de Content Security Policy header (CSP). Isso permite que dados confidenciais armazenados no armazenamento em nuvem sejam acessados – evitar que os usuários consigam fazer a manutenção..

6. Componentes Vulneráveis e Desatualizados: Se você não souber as versões de todos os componentes que usa (tanto do lado do cliente quanto do lado do servidor). Isso inclui componentes que você usa diretamente, bem como dependências aninhadas – a empresa não está fazendo gerenciamento de configuração correto. Então, há servidores desatualizados e softwares desatualizados.

7.Falhas de Identificação e Autenticação: os tempos limite da sessão do aplicativo não estão definidos corretamente. Um usuário usa um computador público para acessar um aplicativo. Em vez de selecionar “logout”, o usuário simplesmente fecha a guia do navegador e vai embora. Um invasor usa o mesmo navegador uma hora depois e o usuário ainda está autenticado

8. Falhas de Integridade de Software e Dados: um aplicativo React chama um conjunto de microsserviços Spring Boot. Sendo programadores funcionais, eles tentaram garantir que seu código fosse imutável. A solução que eles encontraram foi serializar o estado do usuário e passá-lo para frente e para trás a cada solicitação. Um invasor percebe a assinatura do objeto Java “rO0” (em base64) e usa a ferramenta Java Serial Killer para obter a execução remota de código no servidor de aplicativos.

9. Falhas de Log e Monitoramento de Segurança: O operador do site de um provedor de plano de saúde infantil não conseguiu detectar uma violação devido à falta de monitoramento e log. Uma parte externa informou ao provedor do plano de saúde que um invasor havia acessado e modificado diversos registros de saúde confidenciais de mais de 3,5 milhões de crianças. Uma revisão pós-incidente descobriu que os desenvolvedores do site não abordaram vulnerabilidades significativas. Como não houve log ou monitoramento do sistema, o vazamento de dados poderia estar em andamento desde 2013, período de mais de sete anos.

10. Falsificação de Solicitação do lado do Servidor (SSRF): exposição de dados confidenciais

– os invasores podem acessar arquivos locais ou serviços internos, para obter informações confidenciais, como:

file:///etc/passwde http://localhost:28017/

- Servidores internos de varredura de portas: Se a arquitetura de rede não for segmentada, os invasores podem mapear redes internas e determinar se as portas estão abertas ou fechadas em servidores internos a partir dos resultados da conexão ou do tempo decorrido para conectar ou rejeitar conexões de carga útil SSRF.

Referências Bibliográficas:

OSWAP Top 10:2021 (Português): https://owasp.org/Top10/pt_BR/