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)