Segurança no desenvolvimento: OWASP Top 10 e prevenção

1. Introdução à segurança no desenvolvimento e OWASP Top 10

A segurança no desenvolvimento de software deixou de ser uma preocupação secundária para se tornar um requisito fundamental em qualquer projeto moderno. O OWASP Top 10 é um documento publicado pela Open Web Application Security Project (OWASP) que lista as dez vulnerabilidades mais críticas em aplicações web, atualizado periodicamente com base em dados reais de milhares de aplicações.

Para o desenvolvedor, compreender o OWASP Top 10 significa entender os padrões de ataque mais comuns e, mais importante, como preveni-los desde a fase de codificação. O Ciclo de Vida do Desenvolvimento Seguro (SDL) integra práticas de segurança em todas as etapas — requisitos, design, implementação, teste e deploy — e o OWASP Top 10 serve como guia prático para priorizar correções.

É essencial distinguir três conceitos:

  • Vulnerabilidade: uma falha no código que pode ser explorada (ex.: uma query SQL sem sanitização)
  • Ameaça: um agente ou evento que pode explorar uma vulnerabilidade (ex.: um invasor automatizado)
  • Risco: a probabilidade e o impacto de uma ameaça explorar uma vulnerabilidade (ex.: exposição de dados sensíveis com alta probabilidade)

2. Principais vulnerabilidades: falhas de controle de acesso e injeção

Broken Access Control (A01)

Esta categoria lidera o OWASP Top 10 e inclui falhas como escalonamento de privilégios e Insecure Direct Object References (IDOR). Um exemplo clássico:

# Código vulnerável a IDOR
GET /api/user/1234/dados
# Qualquer usuário autenticado pode acessar dados de outro usuário apenas alterando o ID na URL

Prevenção: implementar verificações de autorização em cada endpoint e usar identificadores não previsíveis (UUIDs).

Cryptographic Failures (A02)

Engloba desde senhas armazenadas em texto puro até falta de criptografia em trânsito. Exemplo de falha:

# Configuração insegura de senha
senha_hash = md5(senha)  # MD5 é considerado quebrado

Prevenção: usar bcrypt, Argon2 ou PBKDF2 para senhas; forçar HTTPS; criptografar dados sensíveis em repouso com AES-256.

Injection (A03)

SQL Injection continua sendo uma das vulnerabilidades mais exploradas:

# Código vulnerável
query = "SELECT * FROM usuarios WHERE email = '" + email + "'"
# Se email = ' OR '1'='1, o invasor obtém todos os registros

Prevenção: usar prepared statements ou ORMs que sanitizam automaticamente:

# Código seguro com prepared statement
stmt = conexao.prepareStatement("SELECT * FROM usuarios WHERE email = ?")
stmt.setString(1, email)

3. Vulnerabilidades de design e configuração incorreta

Insecure Design (A04)

Refere-se a falhas no design da aplicação, como ausência de limites de taxa (rate limiting) em APIs ou modelagem de ameaças insuficiente. Exemplo:

# Endpoint sem rate limiting
POST /api/login  # Permite tentativas ilimitadas de senha

Prevenção: implementar rate limiting com Redis ou middleware específico, e realizar threat modeling antes de codificar.

Security Misconfiguration (A05)

Configurações padrão inseguras são extremamente comuns:

# Headers HTTP ausentes (exemplo de resposta)
HTTP/1.1 200 OK
X-Powered-By: Express
# Falta: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security

Prevenção: usar ferramentas de hardening como Helmet.js (Node.js) ou mod_security (Apache); revisar permissões de arquivos e portas abertas.

Vulnerable and Outdated Components (A06)

Dependências desatualizadas são porta de entrada para ataques conhecidos:

# package.json com biblioteca vulnerável
"dependencies": {
  "lodash": "^4.17.15"  # Versão com CVE conhecida
}

Prevenção: usar Software Bill of Materials (SBOM), scanners como OWASP Dependency-Check e Dependabot para atualizações automáticas.

4. Falhas de autenticação e integridade de dados

Identification and Authentication Failures (A07)

Senhas fracas e sessões inseguras são responsáveis por grande parte das violações:

# Sessão com tempo de expiração muito longo
session.cookie.maxAge = 30 * 24 * 60 * 60 * 1000  # 30 dias

Prevenção: implementar MFA (autenticação multifator), politicas de senha fortes (mínimo 12 caracteres, complexidade), e sessões com expiração curta (15-30 minutos de inatividade).

Software and Data Integrity Failures (A08)

Ataques à cadeia de suprimentos (supply chain) têm crescido. Exemplo de falha:

# Atualizações sem verificação de assinatura
wget https://exemplo.com/pacote.tar.gz
tar -xzf pacote.tar.gz
# Sem verificar checksum ou assinatura GPG

Prevenção: verificar assinaturas digitais de pacotes, usar hashes SHA-256 para downloads, e implementar CI/CD com verificação de integridade.

Práticas de logging e monitoramento

Logs devem registrar tentativas de autenticação sem expor dados sensíveis:

# Log seguro
log.info("Tentativa de login para usuário: " + usuario + " - IP: " + ip)
# Não logar a senha ou token

5. Falhas de logging, monitoramento e SSRF

Security Logging and Monitoring Failures (A09)

Sem logs adequados, ataques passam despercebidos:

# Log insuficiente
console.log("Erro no sistema")
# Não informa: qual usuário, qual ação, horário, IP

Prevenção: centralizar logs (ELK Stack, Splunk), definir alertas para múltiplas tentativas de login falhas, e garantir que logs sejam imutáveis.

Server-Side Request Forgery (A10)

SSRF permite que um invasor force o servidor a fazer requisições internas:

# Código vulnerável
resposta = fetch(url_fornecida_pelo_usuario)
# Se url = http://localhost:6379, o invasor acessa o Redis interno

Prevenção: validar URLs contra uma lista branca de domínios permitidos, bloquear IPs privados (127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Boas práticas de resposta a incidentes

Desenvolvedores devem ter um plano: isolar o sistema comprometido, preservar logs, notificar a equipe de segurança e corrigir a vulnerabilidade antes de restaurar.

6. Ferramentas e práticas de prevenção no dia a dia

Análise estática (SAST) e dinâmica (DAST)

  • SAST (Static Application Security Testing): analisa o código fonte sem executá-lo. Ferramentas: SonarQube, Semgrep, Checkmarx.
  • DAST (Dynamic Application Security Testing): testa a aplicação em execução. Ferramentas: OWASP ZAP, Burp Suite.

Integração no pipeline de CI/CD:

# Exemplo de configuração no GitHub Actions
- name: Executar SAST
  run: semgrep --config=auto .
- name: Executar DAST
  run: zap-api-scan.py -t https://staging.app.com -f openapi

Scanners de dependências

  • Snyk: detecta vulnerabilidades em dependências e sugere correções
  • OWASP Dependency-Check: gratuito, integra com Maven, Gradle, npm
  • Dependabot: nativo do GitHub, cria PRs automáticos para atualizações

Treinamento contínuo

Cultura de segurança inclui treinamentos regulares, capture-the-flag (CTF) interno e revisões de código focadas em OWASP.

7. Checklist de segurança para o desenvolvedor

Antes de cada deploy, verifique:

  • [ ] Validação de entrada: todos os inputs são validados no servidor (tipo, tamanho, formato)
  • [ ] Sanitização de saída: dados são escapados antes de serem exibidos (XSS prevention)
  • [ ] CORS configurado: apenas origens confiáveis permitidas
  • [ ] CSP implementado: Content-Security-Policy bloqueia scripts inline não autorizados
  • [ ] Headers HTTP de segurança: X-Frame-Options (DENY), Strict-Transport-Security, X-Content-Type-Options
  • [ ] Autenticação: MFA habilitado para usuários administrativos
  • [ ] Sessões: cookies com flags HttpOnly, Secure, SameSite=Strict
  • [ ] Dependências: scanner executado e sem vulnerabilidades críticas
  • [ ] Logs: tentativas de autenticação e erros são registrados com contexto
  • [ ] Revisão OWASP Top 10: cada ponto do Top 10 foi verificado no código

Referências