https://slides.com/wilcorrea/como-tirar-o-seu-nome-da-lista-do-owasp

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

@wilcorrea

http://wilcorrea.dev

# Agenda

A falta de segurança na web
A OWASP
Top Ten de 10 a 1

# 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

# Top ten de 10 a 1

Relatório

# 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

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

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)

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)

# 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

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

# 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

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

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

# 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

Hora das palmas

# 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