OWASP TOP 10 Flashcards
Conceito OWASP TOP 10
O OWASP Top 10 é um documento de conscientização padrão para desenvolvedores e segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos da web.
Reconhecido globalmente pelos desenvolvedores como o primeiro passo para uma codificação mais segura.
As empresas devem adotar este documento e iniciar o processo de garantir que suas aplicações web minimizem esses riscos. Usar o OWASP Top 10 talvez seja o primeiro passo mais eficaz para mudar a cultura de desenvolvimento de software em sua organização para uma que produza um código mais seguro.
Lista OWASP TOP 10
A01:2021 - Quebra de Controle de Acesso
Descrição
Restrição de ações com base em suas permissões
Falhas nesse processo levam a divulgação, modificação ou destruição não autorizadas da informação
A01:2021 - Quebra de Controle de Acesso
Vulnerabilidades
1 - Violação do princípio de privilégio mínimo ou negação por padrão
2 - Ignorando as verificações de controle de acesso modificando a URL (alteração de parâmetro ou navegação forçada), o estado interno do aplicativo ou a página HTML, ou usando uma ferramenta de ataque modificando solicitações de API.
3 - Permitir a visualização ou edição da conta de outra pessoa
4 - Acessando API com controles de acesso ausentes para POST, PUT e DELETE.
5 - Elevação de privilégio. Atuar como usuário sem estar conectado ou atuar como administrador quando estiver conectado como usuário.
6 - reproduzir ou adulterar um token de controle de acesso JSON Web Token (JWT)
7 - A configuração incorreta do Cross-Origin Resource Sharing - CORS - permite o acesso à API de origens não autorizadas/não confiáveis.
8 - 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.
A02:2021 - Falhas criptográficas
Descrição
Falhas relacionadas à criptografia ou falta dela
Exposição de dados sensíveis ou confidenciais
Necessidade de determinação de segurança de dados em trânsito ou repouso
Destaques a dados privados suscetíveis a regulações próprias
A01:2021 - Quebra de Controle de Acesso
Prevenção
1 - Exceto para recursos públicos, negar por padrão.
2 - Implemente mecanismos de controle de acesso uma vez e reutilize-os em todo o aplicativo,
inclusive minimizando o uso do Cross-Origin Resource Sharing (CORS).
- Os controles de acesso do modelo devem impor a propriedade do registro em vez de
aceitar que o usuário possa criar, ler, atualizar ou excluir qualquer registro. DAC
4 - Os requisitos exclusivos de limite de negócios do aplicativo devem ser impostos por modelos de domínio.
5 - Desative a listagem de diretórios do servidor web e certifique-se de que os metadados do
arquivo (por exemplo, .git) e os arquivos de backup não estejam presentes nas raízes da web.
6 - Registre falhas de controle de acesso, alerte os administradores quando apropriado (por exemplo, falhas repetidas).
7 - Taxa de limite de acesso à API e ao controlador para minimizar os danos das ferramentas de ataque automatizadas.
8- Os identificadores de sessão com estado devem ser invalidados no servidor após o logout. Os tokens JWT sem estado devem ser de curta duração para que a janela de oportunidade para um invasor seja minimizada. Para JWTs de vida mais longa, é altamente recomendável seguir os padrões OAuth para revogar o acesso.
A02:2021 - Falhas criptográficas
Vulnerabilidades
1 - Algum dado é transmitido em texto simples? Isso diz respeito a protocolos como HTTP, SMTP, FTP também usando atualizações TLS como STARTTLS
2 - criptográfico antigo ou fraco é usado por padrão ou em código mais antigo
3 - as chaves criptográficas fracas são geradas ou reutilizadas ou o gerenciamento ou rotação de chaves está ausente? As chaves criptográficas são verificadas nos repositórios de código-fonte? PAM?
4 - A criptografia não é aplicada. Por exemplo, há alguma diretiva de segurança de cabeçalhos HTTP (navegador) ou cabeçalhos ausentes
5 - O certificado do servidor recebido e a cadeia de confiança estão devidamente validados?
6 - Os vetores de inicialização são ignorados, reutilizados ou não gerados suficientemente seguros para o modo de operação criptográfico? Está em uso um modo de operação inseguro, como o BCE? A criptografia é usada quando a criptografia autenticada é mais apropriada?
7 - As senhas estão sendo usadas como chaves criptográficas na ausência de uma função de derivação de chave de base de senha?
8 - A aleatoriedade é usada para fins criptográficos que não foram projetados para atender aos requisitos criptográficos? Mesmo que a função correta seja escolhida, ela precisa ser propagada pelo desenvolvedor e, caso contrário, o desenvolvedor sobrescreveu a funcionalidade de propagação forte incorporada a ela com uma semente que não possui entropia/imprevisibilidade suficiente?
9 - As funções de hash obsoletas, como MD5 ou SHA1, estão em uso ou as funções de hash não criptográficas são usadas quando as funções de hash criptográficas são necessárias?
10 - Estão em uso métodos de preenchimento criptográfico obsoletos, como PKCS número 1 v1.5?
11 - As mensagens de erro criptográficas ou informações de canal lateral podem ser exploradas, por exemplo, na forma de ataques oracle de preenchimento?
A02:2021 - Falhas criptográficas
prevenção
1 - Classifique os dados processados, armazenados ou transmitidos por um aplicativo. Identifique quais dados são confidenciais de acordo com as leis de privacidade, requisitos regulatórios ou necessidades de negócios.
2 - Não armazene dados confidenciais desnecessariamente. Descarte-o o mais rápido possível ou use tokenização compatível com PCI DSS ou até mesmo truncamento. Os dados que não são retidos não podem ser roubados.
3 - Certifique-se de criptografar todos os dados confidenciais em repouso.
4 - Garantir que algoritmos, protocolos e chaves padrão atualizados e fortes estejam em vigor; use o gerenciamento de chaves adequado.
5 - Criptografe todos os dados em trânsito com protocolos seguros, como TLS com cifras de sigilo de encaminhamento (FS), priorização de cifras pelo servidor e parâmetros seguros. Imponha a criptografia usando diretivas como HTTP Strict Transport Security (HSTS).
6 - Desabilite o armazenamento em cache para respostas que contenham dados confidenciais.
7 - Aplique os controles de segurança necessários de acordo com a classificação dos dados.
8 - Não use protocolos legados, como FTP e SMTP, para transportar dados confidenciais.
9 - Armazene senhas usando funções de hashing adaptáveis e Salt com um fator de trabalho (fator de atraso), como Argon2, scrypt, bcrypt ou PBKDF2.
10 - Os vetores de inicialização devem ser escolhidos de acordo com o modo de operação. Para muitos modos, isso significa usar um CSPRNG (gerador de números pseudo- aleatórios criptograficamente seguro). Para modos que exigem um nonce, o vetor de inicialização (IV) não precisa de um CSPRNG. Em todos os casos, o IV nunca deve ser usado duas vezes para uma chave fixa.
11 - Sempre use criptografia autenticada em vez de apenas criptografia.
12 - As chaves devem ser geradas criptograficamente (TLS - chave assimétrica antes) aleatoriamente e armazenadas na memória como arrays de bytes. Se uma senha for usada, ela deverá ser convertida em
uma chave por meio de uma função de derivação de chave de base de senha apropriada.
13 - Certifique-se de que a aleatoriedade criptográfica seja usada quando apropriado e que não tenha sido propagada de maneira previsível ou com baixa entropia. A maioria das APIs
modernas não exige que o desenvolvedor semeie o CSPRNG para obter segurança.
14 - Evite funções criptográficas obsoletas e esquemas de preenchimento, como MD5, SHA1,
PKCS número 1 v1.5
15 - Verifique de forma independente a eficácia da configuração e configurações.
A03:2021 - Injeção
Descrição
Congrega diversas técnicas de ataque, incluindo XSS e CSRF, por exemplo, além dos clássicos SQL Injection
A revisão constante dos códigos e scripts é fundamental para tentar identificar as vulnerabilidades
Pode-se utilizar ferramentas como SAST, DAST e IAST
A03:2021 - Injeção
Vulnerabilidades
I Os dados fornecidos pelo usuário não são validados, filtrados ou higienizados pelo aplicativo.
II. Consultas dinâmicas ou chamadas não parametrizadas sem escape sensível ao contexto são usadas diretamente no interpretador.
III. Dados hostis são usados em parâmetros de pesquisa de mapeamento relacional de objeto (ORM) para extrair registros confidenciais adicionais.
IV. 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.
A03:2021 - Injeção
Vulnerabilidades
I. Manter os dados separados de comandos e consultas
II. A opção preferencial é usar uma API segura, que evite totalmente o uso do interpretador,
forneça uma interface parametrizada ou migre para Object Relational Mapping Tools (ORMs).
i. Nota: Mesmo quando parametrizados, os procedimentos armazenados ainda podem introduzir injeção de SQL se PL/SQL ou T-SQL concatenar consultas e dados ou executar dados hostis com EXECUTE IMMEDIATE ou exec().
III. Use validação de entrada positiva do lado do servidor. Essa não é uma defesa completa, pois muitos aplicativos exigem caracteres especiais, como áreas de texto ou APIs para aplicativos móveis.
IV. Para quaisquer consultas dinâmicas residuais, escape caracteres especiais usando a sintaxe de escape específica para esse interpretador.
i. Nota: Estruturas SQL, como nomes de tabelas, nomes de colunas e assim por diante, não podem ser escapadas e, portanto, os nomes de estrutura fornecidos pelo usuário são perigosos. Este é um problema comum em software de redação de relatórios.
V. Use LIMIT e outros controles SQL nas consultas para evitar a divulgação em massa de registros em caso de injeção de SQL.
A04:2021 - Design inseguro
Descrição
Trata-se de uma nova categoria.
- Foca nos aspectos voltados a problemas de arquitetura e design (desenho) do produto
- Possui foco na pré codificação, isto é, antes do código ser desenvolvido
- Pode-se ter problemas de ausência de controles ou este ser ineficaz durante o período de design
- Deve-se fortalecer as ações associadas ao proecsso de coleta de requisitos e ao Ciclo de Desenvolvimento Seguro
A04:2021 - Design inseguro
Prevenção
I. Estabeleça e use um ciclo de vida de desenvolvimento seguro com profissionais da AppSec para ajudar a avaliar e projetar controles relacionados à segurança e privacidade
II. Estabeleça e use uma biblioteca de padrões de projeto seguros ou componentes prontos para uso de estradas pavimentadas
III. Use a modelagem de ameaças para autenticação crítica, controle de acesso, lógica de negócios e fluxos de chaves
IV. Integre linguagem e controles de segurança em histórias de usuários
V. Integre verificações de plausibilidade em cada camada do seu aplicativo (do front-end ao
back-end)
VI. Escreva testes de unidade e integração para validar se todos os fluxos críticos são
resistentes ao modelo de ameaça. Compile casos de uso e casos de uso indevido para
cada camada de seu aplicativo.
VII. Segregar camadas de camadas no sistema e nas camadas de rede, dependendo das necessidades de exposição e proteção
VIII. Separe os locatários de forma robusta por design em todas as camadas
A05:2021 - Configuração incorreta de segurança
Descrição
Envolve a configuração de ambientes e servidores, bem como ausências de baselines seguras e ferramentas de compliance.
Importante reforçar o conceito de baseline, que trata justamente daquela configuração de referência que poderá ser incorporada e espelhada, com todas as diretrizes e padrões de segurança já conhecidos e mapeados.
A05:2021 - Configuração incorreta de segurança
Vulnerabilidades
I. Falta de proteção de segurança apropriada em qualquer parte da pilha de aplicativos ou permissões configuradas incorretamente em serviços de nuvem.
II. Recursos desnecessários são ativados ou instalados (por exemplo, portas, serviços, páginas, contas ou privilégios desnecessários).
III. As contas padrão e suas senhas ainda estão habilitadas e inalteradas.
IV. O tratamento de erros revela rastreamentos de pilha ou outras mensagens de erro excessivamente informativas aos usuários.
V. Para sistemas atualizados, os recursos de segurança mais recentes são desabilitados ou não configurados com segurança.
VI. As configurações de segurança nos servidores de aplicativos, estruturas de aplicativos (por exemplo, Struts, Spring, ASP.NET), bibliotecas, bancos de dados etc., não são definidas para valores seguros.
VII. O servidor não envia cabeçalhos ou diretivas de segurança ou eles não estão configurados para valores seguros.
VIII. O software está desatualizado ou vulnerável (consulte A06:2021-Componentes vulneráveis e desatualizados ).Importante termos em mente, como principal característica, as vulnerabilidades associadas a entrada de dados diretamente nas páginas, por parte de áreas dinâmica e chamadas diversas ao código por parte do usuário.
