Como tirar o seu nome da lista da OWASP?

Se você acha que o SPC e o SERASA são um problema precisa ver a lista da OWASP

/me

William Correa

http://wilcorrea.dev

# A falta de segurança na web

• Vazamentos
• Legislação

# Vazamentos

• Empresas privadas
• Órgãos públicos

# Legislação

• General Data Protection Regulation (EUR)
• Lei Geral de Proteção de Dados (BRA)

# Legislação

• General Data Protection Regulation (EUR)
• Lei Geral de Proteção de Dados (BRA)

# Pra levar pra casa

• A internet não é um ambiente seguro
• Há uma crise de segurança na web

# A OWASP

O Open Web Application Security Project é uma comunidade on-line que produz artigos, metodologias, documentação, ferramentas e tecnologias disponíveis gratuitamente no campo da segurança de aplicativos da web.

# Propósito

A OWASP tem como principal objetivo manter uma comunidade global para aumentar a visibilidade e a evolução da segurança de software ao redor do mundo

# Princípios

• Free & Open
• Governado por consenso e prática
• Alinha com um código de ética
• Sem fins lucrativos
• Não impulsionado por interesses comerciais
• Abordagem baseada em risco

# Projetos

Para iniciar um projeto...

• Explore os atuais projetos da OWASP
• Coloque sua ideia no quadro de ideias

• Explore e pesquise se sua ideia abrange um segmento exclusivo na área de segurança
• Defina que tipo de projeto você gostaria de iniciar
• Desenvolva seu projeto com base no tipo de projeto

# Projetos

# Pra levar pra casa

• OWASP não é "aquela parada de hacker"
• A lista com as 10 falhas mais comuns
• Não existe segurança na web

# A10: Insufficient Logging & Monitoring

# A10: Insufficient Logging & Monitoring

Como prevenir:

• Gerar logs de falhas de acesso
• Usar formatos de log padronizados
• Auditoria e alertas de mudanças fora do padrão
• Monitoramento do servidor
• Estabelecer ou adotar uma política para incidentes

# A10: Insufficient Logging & Monitoring

# A9: Using Components with Known Vulnerabilities

# A9: Using Components with Known Vulnerabilities

Como prevenir:

• Remover dependências não utilizadas
• Inventarie continuamente as versões de componentes
• Obtenha apenas componentes de fontes oficiais
• Monitora bibliotecas e componentes que não são mantidos

# A9: Using Components with Known Vulnerabilities

# A8: Insecure Deserialization

# A8: Insecure Deserialization

Como prevenir:

• Não aceitar fontes não confiáveis de entrada
• Implementar análises de integridade
• Impor restrições de tipos
• Realizar a desserialização com poucos privilégios
• Gerar logs dos processos de desserialização
• Garantir o isolamento dos serviços e containers
• Monitorar a desserialização, alertando recorrências

# A8: Insecure Deserialization

# A7: Cross-Site Scripting (XSS)

# A7: Cross-Site Scripting (XSS)

Como prevenir:

• Usar ferramentas que dificultem a impressão de código malicioso
• Não confiar na entrada do usuário
• Prevenir manipulações do DOM de aplicarem código malicioso à página
• Habilitar a Content Security Policy (CSP)

# A7: Cross-Site Scripting (XSS)

# A7: Cross-Site Scripting (XSS)

# A6: Security Misconfiguration

# A6: Security Misconfiguration

Como prevenir:

• Automatizar os processos de manutenção do ambiente
• Manter o projeto sem recursos esquecidos em desuso
• Revisar e atualizar as configurações apropriadas para todas as notas de segurança com frequência
• Utilizar uma estrutura que garanta o isolamento
• Gerenciar headers para manter as requisições e a identidade do servidor em segurança
• Arquivos de configuração devem ser inacessíveis via HTTP

# A6: Security Misconfiguration

# A5: Broken Access Control

# A5: Broken Access Control

Como prevenir:

• Trabalhe com lista branca
• Escreva rotinas centralizadas de autenticação e
  autorização
• Segmentar o acesso na modelagem de dados
• Nunca listar diretório e nunca deixar dados sensíveis em ambiente público
• Registrar falhas, usar UUID, CAPTCHA, limitar tentativas
• Manter mensagens pouco amigáveis

# A5: Broken Access Control

# A5: Broken Access Control

# A4: XML External Entities (XXE)

# A4: XML External Entities (XXE)

Como prevenir:

• Sempre que possível, use formatos de dados menos complexos, como JSON
• Manter as ferramentas e bibliotecas atualizadas
• Desabilitar a manipulação remota e o processamento de DTD em toda a manipulção de XML
• Implementar validação, filtragem ou sanitização de entrada positiva no lado do servidor
• Validar o XML recebido usando a validação XSD ou similar

# A4: XML External Entities (XXE)

# A3: Sensitive Data Exposure

# A3: Sensitive Data Exposure

Como prevenir:

• Classificar dados processados, armazenados ou transmitidos por um aplicativo. Identifique quais dados são sensíveis de acordo com as leis de privacidade, requisitos regulatórios ou necessidades comerciais.
• Aplique controles de acordo com a classificação.
• Não armazene dados confidenciais desnecessariamente

# A3: Sensitive Data Exposure

Como prevenir:

• Certifique-se de criptografar todos os dados confidenciais em repouso.
• Certifique-se de que algoritmos, protocolos e chaves padrão atualizados e fortes estejam em vigor; use o gerenciamento de chaves apropriado.
• Criptografe todos os dados em trânsito com protocolos seguros

# A3: Sensitive Data Exposure

Como prevenir:

• Desativar o cache para respostas que contenham dados confidenciais.
• Armazene senhas usando funções de hashing adaptáveis ​​e fortes com um fator de trabalho (fator de atraso), como Argon2, scrypt, bcrypt ou PBKDF2.
• Verificar de forma independente a eficácia da configuração e definições.

# A3: Sensitive Data Exposure

# A2: Broken Authentication 

# A2: Broken Authentication 

Como prevenir:

• Sempre que possível, implemente a autenticação de vários fatores para evitar ataques automatizados, de preenchimento de credenciais, força bruta e reutilização de credenciais roubadas
• Não envie ou implante com nenhuma credencial padrão, especialmente para usuários administradores.
• Implemente verificações de senhas fracas, como testar senhas novas ou alteradas em uma lista das 10000 piores senhas

# A2: Broken Authentication 

Como prevenir:

• Alinhe as políticas de comprimento, complexidade e rotação de senhas com as diretrizes do NIST 800-63 B na seção 5.1.1 para "Memorized Secrets" ou outras políticas de senhas modernas baseadas em evidências
• Garantir que o registro, a recuperação de credenciais e os caminhos da API sejam protegidos contra ataques de enumeração de contas usando as mesmas mensagens para todos os resultados

# A2: Broken Authentication 

Como prevenir:

• Limitar ou atrasar cada vez mais as tentativas de login malsucedidas. Registre todas as falhas e notifique os administradores
• Use um gerenciador de sessão interno, seguro e do lado do servidor que gere um novo ID de sessão aleatório com alta entropia após o login. Os IDs de sessão não devem estar no URL, devem ser armazenados e invalidados com segurança

# A2: Broken Authentication 

# A2: Broken Authentication 

# A1: Injection

# A1: Injection

Como prevenir:

• A opção preferida é usar uma API segura, que evite o uso do interpretador por completo ou forneça uma interface com parâmetros ou migre para usar as ORMs (Object Relational Mapping Tools)
• Use validação de entrada do lado do servidor positiva ou "lista branca". Essa não é uma defesa completa, pois muitos aplicativos exigem caracteres especiais, como áreas de texto ou APIs para aplicativos móveis

# A1: Injection

Como prevenir:

• Para quaisquer consultas dinâmicas residuais, escape de caracteres especiais usando a sintaxe de escape específica para esse interpretador
• Use LIMIT e outros controles SQL nas consultas para evitar a divulgação em massa de registros no caso de injeção de SQL

# A1: Injection

# A1: Injection

# A1: Injection

# A1: Injection

# A1: Injection

# Perguntas

• Fale agora ou cale-se para sempre

• wilcorrea@gmail.com
• t.me/wilcorrea
• medium.com/wilcorrea

# Referências

• https://www.owasp.org/index.php/Main_Page
• https://computerworld.com.br/2018/09/19/lgpd-10-pontos-para-entender-a-nova-lei-de-protecao-de-dados-no-brasil