DEV Community

Marlo Henrique
Marlo Henrique

Posted on

OWASP top 10: Um guia prático para testes de segurança - Parte 1

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:

  • Broken Acess Control.
  • Cryptographic Failures.
  • Injection.
  • Insecure Desing.
  • Security Misconfiguration.

Na segunda parte abordaremos:

  • Vulnerable and outdated components.
  • Identification and authentication failures.
  • Software and data integrity failures.
  • Security logging and monitoring failures.
  • Server-side request forgery.

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.

Broken Acess Control🔐

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.

Cryptographic Failures🔑

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.

Injection💉

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.

Security Misconfiguration🔨:

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.

Espero que tenham gostado do conteúdo, e estejam ansiosos pela parte 2
😊!

Sintam-se a vontade para me acompanhar nos links abaixo:
📩 linkedin
🐱‍👤 github

Top comments (0)