🚀 Capítulo 19: Projeto Final Parte 1: Auditoria (Tema: Mr. Robot)
NOTE
Este capítulo utiliza a temática de Mr. Robot para o Projeto Final. Elliot Alderson audita as empresas de dia e as hackeia de noite. Sua missão é fazer a auditoria do bem!
1. 🎯 Objetivo da Aula
Aplicar os conhecimentos adquiridos durante o curso para realizar uma auditoria de segurança em um sistema simulado, identificando vulnerabilidades e sugerindo correções profissionais.
2. 🏢 O Cenário Prático (Seu Desafio)
Você trabalha na Allsafe Cybersecurity. A empresa “E Corp” (Evil Corp) contratou você para auditar o novo sistema de portal do cliente deles. Abaixo está o relatório do que você encontrou ao olhar o código e a infraestrutura do sistema:
Relatório da Auditoria (Descobertas):
- Código do Formulário de Login: O programador usou concatenação direta de strings para montar a consulta SQL que verifica o usuário.
- Configuração do Servidor: O arquivo de configuração do Docker roda a aplicação como usuário
rootpor padrão. - Gestão de Credenciais: A chave secreta da API de pagamentos está escrita diretamente no arquivo
config.jse foi enviada para o repositório do GitHub. - Biblioteca de Terceiros: O projeto usa uma biblioteca de geração de PDF na versão 1.2. O
npm auditavisou que essa versão tem uma falha crítica de execução de código remoto.
🔍 Sua Missão:
Você deve agir como o Elliot e criar um relatório de auditoria apontando pelo menos 3 vulnerabilidades encontradas acima. Para cada uma, você deve dizer qual o risco e qual a solução recomendada.
🧠 Fundamentos: A Teoria Traduzida
Um bom Relatório de Auditoria de Segurança deve ser claro para que os programadores consigam corrigir os erros. Ele deve conter:
- A Falha: O que está errado.
- O Risco: O que um hacker pode fazer se explorar essa falha.
- A Solução: Como o programador deve reescrever o código ou alterar a configuração para ficar seguro.
4. 📖 Exemplo Guiado: Relatando a Primeira Falha
Vamos preencher o relatório para a descoberta número 1 (Login):
- Falha: Uso de concatenação de strings na consulta SQL do login.
- Risco: Ataque de SQL Injection. Um hacker pode burlar o login sem saber a senha ou apagar o banco de dados.
- Solução: Mudar o código para usar Prepared Statements (Consultas Preparadas).
5. 🛠️ Prática Obrigatória 1: Relatando a Segunda Falha
Escolha uma das outras descobertas do relatório (2, 3 ou 4) e preencha os campos abaixo:
- Falha: [Qual das descobertas você escolheu?]
- Risco: [O que pode acontecer de ruim?]
- Solução: [Como corrigir?]
6. 🛠️ Prática Obrigatória 2: Severidade
Qual das 4 descobertas do relatório você considera a mais perigosa (de maior severidade) e que deveria ser corrigida primeiro? Por quê?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 19 Seguranca) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
mod_12_desenvolvimento_seguro/
├── capitulos/
│ ├── capitulo_19_projeto_p1.md
│ └── codigos/
│ └── cap19/
│ └── auditoria_report.txt💡 Checkpoint de Lógica
Em uma auditoria real, nós também usamos ferramentas automáticas (SAST, DAST e SCA) para nos ajudar a encontrar as falhas, mas a revisão humana do código ainda é essencial para entender a lógica do sistema!
10. 🔥 Desafio de Fixação
Pesquise sobre o que faz um Analista de SOC e um Analista de Pentest e veja em qual dessas carreiras você se encaixaria melhor no futuro.
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática 1 (Exemplo para a descoberta 3):
- Falha: Chave de API exposta no código.
- Risco: Hackers podem roubar a chave no GitHub e usá-la para roubar dinheiro ou fazer cobranças.
- Solução: Mover a chave para um arquivo
.enve usar variáveis de ambiente. Gabarito da Prática 2: A resposta pode variar, mas a descoberta 4 (Execução de Código Remoto em biblioteca) costuma ser a mais crítica, pois permite que o hacker execute qualquer comando no servidor da empresa sem precisar de login!