Pular para o conteúdo principal

Knowledge Source Personalizado de Boas Práticas de Segurança OWASP

Você está desenvolvendo uma aplicação e deseja garantir que as melhores práticas de segurança sejam seguidas. Para isso, você pode criar um Knowledge Source personalizado na StackSpot AI, onde poderá armazenar e compartilhar as boas práticas de segurança baseadas no OWASP com sua equipe. Esse Knowledge Source pode ser utilizado em:

  • Code Review
  • Refatoração de código
  • Análise de vulnerabilidades de segurança
  • Retirada de dúvidas sobre as boas práticas
  • Criação de agentes de segurança

Passos para criar o Knowledge Source

Passo 1. Acessar o Portal da StackSpot AI

Passo 2. Criar um novo Knowledge Source

  • No menu principal, clique em ‘Contents > Knowledge Sources’;
  • Clique no botão ‘Criar’ para adicionar um novo Knowledge Source;
  • Selecione a opção ‘Personalizado’ para criar um Knowledge Source customizado;

Passo 3. Preencher as informações do Knowledge Source

  • Nome: adicione um nome descritivo, como "Boas Práticas de Angular".
  • Identificação (Slug): defina um slug único, como "boas-praticas-seguranca-owasp".

Você não pode alterar o slug posteriormente.

  • Descrição: adicione uma descrição clara, como:

"Este Knowledge Source contém boas práticas de segurança baseadas no OWASP, focando em controle de acesso, prevenção de vulnerabilidades e exemplos de cenários de ataque"

  • Clique em ‘Salvar’.

Passo 4: Adicionar o Conteúdo de Boas Práticas

  • Na aba ‘Knowledge Objects’, clique em ‘Adicionar Arquivo’;
  • Escolha a opção ‘Manualmente’ para copiar e colar o conteúdo diretamente. Cole o seguinte conteúdo de boas práticas de Angular:
# A01:2021 – Broken Access Control

## Fatores
- **CWEs Mapeados:** 34
- **Taxa Máxima de Incidência:** 55.97%
- **Taxa Média de Incidência:** 3.81%
- **Exploração Média Ponderada:** 6.92
- **Impacto Médio Ponderado:** 5.93
- **Cobertura Máxima:** 94.55%
- **Cobertura Média:** 47.72%
- **Total de Ocorrências:** 318,487
- **Total de CVEs:** 19,013

### **Visão Geral**
Subindo da quinta posição, 94% das aplicações foram testadas para algum tipo de controle de acesso quebrado, com uma taxa média de incidência de 3.81%, e tem o maior número de ocorrências no conjunto de dados contribuído, com mais de 318k. As Common Weakness Enumerations (CWEs) notáveis incluídas são:
- **CWE-200:** Exposição de Informações Sensíveis para um Ator Não Autorizado
- **CWE-201:** Inserção de Informações Sensíveis em Dados Enviados
- **CWE-352:** Cross-Site Request Forgery

### **Descrição**
O controle de acesso impõe políticas para que os usuários não possam agir fora de suas permissões pretendidas. Falhas geralmente levam à divulgação não autorizada de informações, modificação ou destruição de dados, ou à execução de uma função de negócios fora dos limites do usuário. Vulnerabilidades comuns de controle de acesso incluem:

- Violação do princípio do menor privilégio ou negação por padrão, onde o acesso deve ser concedido apenas para capacidades, funções ou usuários específicos, mas está disponível para qualquer pessoa.
- Bypass de verificações de controle de acesso modificando a URL (manipulação de parâmetros ou navegação forçada), estado interno da aplicação ou a página HTML, ou usando uma ferramenta de ataque para modificar solicitações de API.
- Permitir a visualização ou edição da conta de outra pessoa, fornecendo seu identificador exclusivo (referências diretas inseguras a objetos).
- Acessar API sem controles de acesso para POST, PUT e DELETE.
- Elevação de privilégio. Agir como um usuário sem estar logado ou agir como um administrador quando logado como um usuário.


- Manipulação de metadados, como reproduzir ou adulterar um token de controle de acesso JWT (JSON Web Token), ou um cookie ou campo oculto manipulado para elevar privilégios ou abusar da invalidação de JWT.
- Configuração incorreta de CORS permite acesso à API de origens não autorizadas/não confiáveis.
- Navegação forçada para páginas autenticadas como um usuário não autenticado ou para páginas privilegiadas como um usuário padrão.

### **Como Prevenir**
- O controle de acesso só é eficaz em código confiável no lado do servidor ou API sem servidor, onde o atacante não pode modificar a verificação de controle de acesso ou metadados.
- Exceto para recursos públicos, negue por padrão.
- Implemente mecanismos de controle de acesso uma vez e reutilize-os em toda a aplicação, incluindo a minimização do uso de 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 pode criar, ler, atualizar ou excluir qualquer registro.
- Requisitos de limite de negócios exclusivos da aplicação devem ser aplicados por modelos de domínio.
- Desative a listagem de diretórios do servidor web e certifique-se de que metadados de arquivos (por exemplo, .git) e arquivos de backup não estejam presentes nas raízes da web.
- Registre falhas de controle de acesso, alerte os administradores quando apropriado (por exemplo, falhas repetidas).
- Limite a taxa de acesso à API e ao controlador para minimizar os danos de ferramentas de ataque automatizadas.
- Identificadores de sessão com estado devem ser invalidados no servidor após o logout. Tokens JWT sem estado devem ser de curta duração para que a janela de oportunidade para um atacante seja minimizada. Para JWTs de longa duração, é altamente recomendável seguir os padrões OAuth para revogar o acesso.

### **Exemplos de Cenários de Ataque**
- **Cenário #1:** A aplicação usa dados não verificados em uma chamada SQL que acessa informações da conta:
```java
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();


Um atacante simplesmente modifica o parâmetro 'acct' do navegador para enviar qualquer número de conta que desejar. Se não for verificado corretamente, o atacante pode acessar a conta de qualquer usuário.
https://example.com/app/accountInfo?acct=notmyacct


Cenário #2: Um atacante simplesmente força a navegação para URLs de destino. Direitos de administrador são necessários para acessar a página de administração.
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Se um usuário não autenticado puder acessar qualquer uma das páginas, é uma falha. Se um não administrador puder acessar a página de administração, isso é uma falha.

  • Após colar o conteúdo, clique em ‘Salvar’

Passo 5: Compartilhar o Knowledge Source

  • Após salvar o Knowledge Source, você pode compartilhá-lo com outros membros da sua equipe.
  • Na aba de compartilhamento, adicione os e-mails dos membros da equipe e defina as permissões (leitura ou escrita).
  • Clique em ‘Compartilhar’.

Agora você tem um Knowledge Source Personalizado com boas práticas de segurança OWASP disponíveis para toda a equipe. Isso facilita a consulta e garante que todos sigam as melhores práticas de segurança, melhorando a qualidade e a segurança do código.