Demonstração Prática de Security Misconfiguration

Uma apresentação interativa mostrando vulnerabilidades e soluções em segurança de APIs.

---

Resumo para a apresentação

O que é Security Misconfiguration?

Falhas de configuração de segurança em sistemas ou APIs que permitem:

• Acesso não autenticado a dados sensíveis
• Exposição de informações do servidor
• Falta de controle de acesso
• Operações críticas sem proteção

---

Como executar a demonstração

Passo 1: instalar dependências

npm install

Swagger para apresentação (documentação visual)

Após iniciar cada API, abra no navegador:

• API vulnerável: http://localhost:3000/docs
• API corrigida: http://localhost:3001/docs

Na API corrigida:

1. Execute POST /login
2. Copie o token retornado
3. Clique em Authorize no Swagger e cole: Bearer SEU_TOKEN
4. Teste os endpoints protegidos

---

Parte 1 - Demonstração da vulnerabilidade (30 segundos)

Terminal 1: rodar a API vulnerável

npm start

Terminal 2: simular o ataque

node simular-ataque.js

O que acontece:

1. Consegue acessar /api/users sem autenticação
2. Visualiza dados sensíveis (salários, e-mail etc.)
3. Consegue deletar usuários sem permissão
4. Expõe credenciais do banco de dados

Resultado: todos os ataques são bem-sucedidos.

---

Parte 2 - Mostrando a solução (30 segundos)

Terminal 1: parar API vulnerável (Ctrl+C) e rodar a corrigida

npm run start:corrigida

Terminal 2: testar a API corrigida

node simular-ataque-corrigida.js

O que acontece:

1. Tenta acessar /api/users sem token -> negado
2. Faz login em /login -> recebe token JWT
3. Acessa /api/users com token -> permitido
4. Tenta deletar sem permissão -> bloqueado
5. Dados sensíveis não são expostos -> protegido

Resultado: os ataques são bloqueados.

---

Testando manualmente com Postman/cURL

API vulnerável (localhost:3000)

1) Acessar dados sem autenticação

curl http://localhost:3000/api/users

Resultado:

{
  "sucesso": true,
  "mensagem": "Dados de usuários (sem autenticação!)",
  "usuarios": [
    {
      "id": 1,
      "nome": "João Silva",
      "email": "joao@empresa.com",
      "salario": 5000
    },
    {
      "id": 2,
      "nome": "Maria Santos",
      "email": "maria@empresa.com",
      "salario": 6000
    }
  ]
}

2) Acessar /api/status (expõe segredos)

curl http://localhost:3000/api/status

Resultado:

{
  "servidor": "Em produção",
  "debug": true,
  "banco_dados": "postgresql://admin:senha123@db.interna.com",
  "chave_secreta": "chave_super_secreta_123456"
}

---

API corrigida (localhost:3001)

1) Tentar acessar sem token (será bloqueado)

curl http://localhost:3001/api/users

Resultado:

{
  "erro": "Acesso negado! Token não fornecido.",
  "mensagem": "Faça login primeiro para obter um token."
}

2) Fazer login para obter token

curl -X POST http://localhost:3001/login

Resultado:

{
  "mensagem": "Login realizado com sucesso!",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

3) Usar o token para acessar dados (permitido)

curl -H "Authorization: Bearer SEU_TOKEN_AQUI" http://localhost:3001/api/users

Resultado:

{
  "sucesso": true,
  "autenticado_como": "admin@empresa.com",
  "usuarios": [ ... ]
}

4) /api/status não expõe segredos

curl -H "Authorization: Bearer SEU_TOKEN_AQUI" http://localhost:3001/api/status

Resultado:

{
  "servidor": "Em produção",
  "versao": "1.0.0 (SEGURA)",
  "debug": false,
  "mensagem": "Informações sensíveis não são expostas!"
}

---

Slide para apresentação

Título: Security Misconfiguration - Demonstração Prática

Problema

• API sem autenticação expõe dados de usuários
• Qualquer pessoa consegue acessar informações sensíveis
• Operações críticas (delete) sem proteção
• Credenciais e chaves secretas visíveis

Impacto

• Roubo de dados pessoais
• Vazamento de credenciais
• Exclusão e modificação de dados
• Comprometimento da aplicação inteira

Solução implementada

• Autenticação com JWT
• Autorização por roles (admin, user)
• Ocultamento de informações sensíveis
• Proteção de endpoints críticos

Resultado

• Todos os ataques são bloqueados
• Apenas usuários autenticados acessam dados
• Operações críticas requerem autorização
• Informações sensíveis são protegidas

---

Estrutura dos arquivos

.
├── app-vulneravel.js           # API sem segurança
├── app-corrigida.js            # API com segurança JWT
├── simular-ataque.js           # Simula ataques na versão vulnerável
├── simular-ataque-corrigida.js # Testa segurança da versão corrigida
├── package.json                # Dependências
└── README.md                   # Este arquivo

---

Dicas para apresentação

Timing

• Introdução: 2 minutos
• Demonstração vulnerável: 1 minuto (simular-ataque.js)
• Explicação do problema: 2 minutos
• Demonstração corrigida: 1 minuto (simular-ataque-corrigida.js)
• Conclusão: 1 minuto
• Total: ~7 minutos

Visual

• Use 2 terminais lado a lado (API + ataque)
• Maximize os textos para visualização
• Pause nos pontos importantes

Interatividade

• Pergunte à plateia: "Como vocês acham que um atacante conseguiria acesso?"
• Mostre os dados expostos
• Explique o impacto em dados reais (salários, informações pessoais)

Conclusão

• Mostre a comparação antes vs depois
• Reforce que a implementação de autenticação é essencial
• Mencione que JWT é apenas uma solução (também há OAuth, sessão etc.)

---

Conceitos abordados

Security Misconfiguration (OWASP Top 10)

• Falta de autenticação
• Falta de controle de acesso
• Exposição de informações sensíveis
• Debug habilitado em produção

JWT (JSON Web Tokens)

• O que é e como funciona
• Estrutura: Header.Payload.Signature
• Token contém informações do usuário
• Protege contra acesso não autorizado

Boas práticas

• Implementar autenticação
• Validar e autorizar cada requisição
• Nunca expor segredos (credenciais, chaves)
• Desabilitar debug em produção
• Usar HTTPS em produção
• Manter tokens com expiração

---

Testando outros cenários

Você pode modificar os arquivos para experimentar:

No app-vulneravel.js

• Adicione mais endpoints vulneráveis
• Exponha diferentes tipos de dados sensíveis
• Teste sem CORS (remova a linha app.use(cors()))

No app-corrigida.js

• Adicione diferentes roles (admin, user, viewer)
• Teste autorização em endpoints específicos
• Valide token expirado

---

Perguntas para discutir

1. Por que é perigoso expor dados de usuários?
2. Como um atacante exploraria isso em produção?
3. Por que autenticação não é suficiente?
4. O que é diferente entre autenticação e autorização?
5. Como as credenciais do banco de dados poderiam ser usadas?

---

Contato e dúvidas

Para adicionar mais cenários ou melhorar a demonstração, edite os arquivos .js.

Bom sucesso na apresentação.