OWASP top 10: Um guia prático para testes de segurança
Published: 2024-02-11 00:40:34

O que é o OWASP Top 10🤔
A Open Web Application Security Project(OWASP) é uma fundação sem fins lucrativos que trabalha para melhorar a segurança de softwares por meio de ferramentas, material técnico e capacitação de profissionais, isso tudo mantido por uma comunidade open source.

De tempos em tempos é lançado a chamada OWASP Top 10, uma lista com os 10 principais problemas de segurança que as organizações devem estar atentas ao construírem suas aplicações.

Introdução📑
Durante essa serie de publicações, falaremos sobre a OWASP top 10 de 2021, ultima lista de mapeamento de riscos de segurança disponibilizada.

Nessa primeira parte abordaremos pontos como:

Controle de acesso quebrado.
Falhas criptográficas.
Injeção.
Insecure Desing.
Configuração incorreta de segurança.
Na segunda parte abordaremos:

Componentes vulneráveis ​​e desatualizados.
Falhas de identificação e autenticação.
Falhas de integridade de software e dados.
Registro de segurança e monitoramento de falhas.
Falsificação de solicitação do lado do servidor.
Comentaremos sobre os principais problemas que os times devem estar atentos durante o ciclo de desenvolvimento, e alguma verificações básicas que podem ser realizadas.

Controle de acesso quebrado🔐
O Broken Access Control é um cenário no qual os invasores podem acessar, modificar, excluir e/ou executar ações fora das permissões pretendidas de um sistema.

Se verificarmos a lista dos principais problemas de segurança para APIs da OWASP, veremos que os 6 primeiros tem relação a controle de autenticação e autorização.

Um exemplo simples, seria um usuário que possa acessar URLs de uma aplicação, sem que possua as permissões necessárias.

Vulnerabilidades comuns🦗:
Violação do principio de privilegio mínimo.
alteração de parâmetro na URL/path ou navegação forçada.
API sem controle de acesso para POST, PUT e DELETE.
Atuar como usuário sem estar conectado ou atuar como administrador quando estiver conectado como usuário.(Elevação de privilegio).
Força a navegação em páginas autenticadas como usuário não autenticado ou em páginas privilegiadas como usuário padrão.
Pontos a serem validados💻:
Negue o acesso por padrão(exceto para recursos pensados em ser públicos).
Minimize a utilização de Cross-Origin Resource Sharing.
Sempre Verifique se o usuário que está realizando determinada ação pode: criar, ler, atualizar ou excluir qualquer registro.
Tenha um registro de falhas de controle de acesso, e alerte os administradores quando necessário.
Utilize mecanismos de rate limiting em APIs para minimizar os impactos causados por ferramentas automatizadas.
Sempre invalide IDs de sessão após o logout do usuário.
Falhas criptográficas🔑
Anteriormente, esse tipo de problema era conhecido como exposição de dados na lista da OWASP de 2017. Foi identificado que essa exposição era na verdade um sintoma, e então renomeada para a causa raiz, falhas de criptografia ou até mesmo a falta dela.

Esse é um tipo de falha responsável pela exposição e vazamento de dados de natureza crítica e sensível a algum recurso ou pessoa mal intencionada.

Vulnerabilidades comuns🦗:
Algoritmos ou protocolo criptográfico antigo ou fraco usado no projeto.
Dados sendo trafegados e armazenados em texto plano.
uso de protocolos inseguros HTTP, SMTP, FTP.
Utilização de chaves criptográficas fracas.
Diretivas de segurança de cabeçalhos HTTP (navegador) ou cabeçalhos ausentes.
Uso de hash obsoleta, Ex: MD5 SHA1.
Métodos de preenchimento criptográfico obsoletos, como PKCS v1.5.
Pontos a serem validados💻:
Identificar todos os dados sensíveis que sua aplicação utiliza.
Utilizar criptografia nos dados em repouso e transporte.
Utilizar TLS para dados em transito.
Utilizar hashes fortes para armazenamento de senhas.
Sempre use criptografia autenticada em vez de apenas criptografia.
Injeção💉
Os dados que o usuário fornece para seu sistema podem se tornar um grande vilão no fim das contas.

Se a entrada fornecida pelo usuário for implicitamente confiável, sem qualquer sanitização, filtragem ou escape, um usuário mal intencionado poderá controlar a resposta gerada pelo seu sistema, e até mesmo, controlar os servidores da sua organização!

Apesar de os ataques de injeção já serem discutidos a bastante tempo, inclusive, liderava a lista da OWASP de 2017, nunca é tarde para reforçar que: a entrada do usuário deve ser tratada com segurança.

Alguns dos métodos de injeções mais comuns são: SQL, NoSQL, comando do sistema operacional, mapeamento relacional de objeto (ORM), injeção de linguagem de expressão (EL) ou biblioteca de navegação de gráfico de objeto (OGNL) entre outras.

Vulnerabilidades comuns🦗:
Os dados fornecidos pelo usuário não são validados, filtrados ou sanitizados pelo aplicativo?
Consultas dinâmicas ou chamadas não parametrizadas sem escape sensível ao contexto são usadas diretamente no interpretador?
Os dados hostis são usados nos parâmetros de pesquisa de mapeamento objeto-relacional (ORM) para extrair registros confidenciais adicionais?
Dados hostis são usados diretamente ou concatenados?
O SQL ou comando contém a estrutura e os dados maliciosos em consultas dinâmicas, comandos ou procedimentos armazenados?
Pontos a serem validados💻:
Mantenha uma lista segura de caracteres permitidos esperados na entrada e rejeite qualquer entrada malformada ou inesperada.
Higienize, filtre e escape a entrada do usuário antes de processá-la.
Codifique (dependendo do contexto) a saída antes de enviá-la de volta.
Para quaisquer consultas dinâmicas residuais, escape de caracteres especiais usando a sintaxe de escape específica para esse interpretado
Use LIMIT e outros controles SQL nas consultas para evitar a divulgação em massa de registros em caso de injeção de SQL.
Insecure Desing 🎨
O planejamento é uma parte importante no design de software. Os problemas de Insecure Desing acontecem quando o aplicativo não é projetado com a segurança em mente.

É um novo complemento para a família OWASP Top 10. Portanto, muito pensamento deve ser colocado na fase de planejamento e projeto.

Vulnerabilidades comuns🦗:
Ausência de modelagem de ameaça
Ausência de padrões de desing seguros e arquiteturas de referencia.
Falta de comunicação entre as equipes de segurança e times de desenvolvimento.
Pontos a serem validados💻:
Estabeleça e use um ciclo de vida de desenvolvimento seguro.
Estabeleça e use bibliotecas de padrão de projeto seguros.
Use a modelagem de ameaças para autenticação crítica, controle de acesso, lógica de negócios e fluxos importantes.
Escreva testes de unidade e integração para validar se todos os fluxos críticos são resistentes ao modelo de ameaça.
Adote conceitos como secure by desing e privacity by desing.
Configuração incorreta de segurança🔨:
Problemas relacionados a configuração de uma aplicação podem se torna comuns a medida que precisamos realizar muitas configurações manualmente.

As chances de ter uma configuração incorreta, dependem diretamente do número de maneiras possíveis de errar. Quanto maior o número de mostradores e botões que o serviço/aplicativo oferece, mais chances de errar.

Vulnerabilidades comuns🦗:
Falta de proteção/segurança apropriada em qualquer parte da pilha de aplicativos ou permissões configuradas incorretamente em serviços de nuvem.
Recursos desnecessários ativos ou instalados (por exemplo, portas, serviços, páginas, contas ou privilégios desnecessários).
Contas padrão e suas senhas ainda estão habilitadas e inalteradas.
Exposição dos detalhes do erro ao usuário.
Recursos de segurança desativados ou não configurados com segurança.
Exposição de informações no cabeçalho server do HTTP.
Utilização de software desatualizado ou vulnerável.
Pontos a serem validados💻:
Siga o “Princípio do Menor Privilégio”. Atribua apenas os privilégios necessários.
Configure os cabeçalhos de segurança corretamente: eles não devem ser excessivamente permissivos, caso contrário, eles tendem a se tornar ineficazes!
Certifique-se de atualizar os serviços e pacotes que estão sendo usados.
Audite sua infraestrutura e faça testes regulares para garantir a alta segurança de seus aplicativos/serviços.
Criei um processo automatizado para verificar a eficácia das configurações e configurações em todos os ambientes.
Conclusão😃
Como podemos ver, existem inúmeros pontos que podem agregar a segurança da aplicação construída.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ras8fimcuzw4doewdxn9.jpg)