edumanagerpro2/RELATORIO_SEGURANCA.md

Relatório de Segurança do App — EduManager & Portal do Aluno

1. Segurança no Portal do Aluno (portal)

O Portal do Aluno possui uma estrutura de segurança robusta baseada em JWT e middlewares de autenticação.

• Mecanismo de Autenticação (Login):
  • O endpoint POST /api/portal/login em server.selfhosted.js gerencia o acesso do aluno. Ele valida se o aluno existe no banco de dados através da busca pela matrícula (numero_matricula).
  • Verificação de Senha: A comparação de senha é feita em texto plano diretamente contra a coluna senha_portal do banco de dados PostgreSQL. Se o aluno não tiver uma senha definida (senha_portal nula ou vazia), o sistema utiliza como fallback de senha os primeiros 6 dígitos do CPF (removendo a formatação), ou uma string vazia caso o CPF também não esteja disponível.
  • Validação de Status: Se a conta do aluno estiver inativa no banco (status !== 'active'), o login é rejeitado com o código HTTP 403 Forbidden.
• Geração e Persistência de Sessão:
  • Ao autenticar com sucesso, o servidor assina um token JWT (JSON Web Token) com expiração de 7 dias (expiresIn: '7d'), contendo informações não sensíveis no payload (studentId, enrollmentNumber e name).
  • No frontend (AuthContext.tsx), esse JWT é guardado no localStorage do navegador sob a chave portal_token, juntamente com os dados do usuário em portal_user.
• Proteção de Rotas (Backend API):
  • Foi implementado um middleware de segurança centralizado no backend chamado authMiddleware.
  • Esse middleware intercepta as requisições, extrai o JWT do cabeçalho Authorization: Bearer <token>, e faz a validação da assinatura utilizando a variável de ambiente JWT_SECRET. Se o token for inválido ou estiver expirado, ele retorna imediatamente 401 Unauthorized.
  • Todas as rotas sensíveis do aluno (/api/portal/me, /api/portal/financeiro, /api/portal/boletos, /api/portal/notas, /api/portal/frequencia, /api/portal/contratos, /api/portal/avaliacoes, /api/portal/alterar-senha, etc.) estão devidamente protegidas pelo authMiddleware no backend.

---

2. Segurança no EduManager (Painel Administrativo — manager)

A arquitetura de segurança do Painel Administrativo possui particularidades importantes. Enquanto o frontend gerencia e restrinja as exibições com base na sessão local, o backend das APIs administrativas do Manager adota uma abordagem menos restritiva de verificação.

• Autenticação no Frontend:
  • O painel administrativo restringe o acesso aos componentes da interface gerenciando o estado de login através do index.tsx.
  • As sessões administrativas ativas são salvas no localStorage sob a chave edumanager_session contendo o objeto de perfil do usuário.
• Mecanismo de Login:
  • O endpoint POST /api/auth/login em server.selfhosted.js pesquisa o usuário na tabela usuarios do Postgres pelo campo username.
  • Assim como no portal, a comparação de senhas ocorre em texto plano (user.password !== password).
  • Se as credenciais forem válidas, o servidor gera um JWT contendo { userId, username, role } assinado com o JWT_SECRET com validade de 24 horas.
• Exposição de Rotas do Backend (API Administrativa aberta):
  • Ponto Crítico: Diferente do Portal do Aluno, no backend do Painel Administrativo (server.selfhosted.js), as APIs de gerenciamento de dados principais (/api/school-data, /api/alunos, /api/turmas, /api/cobrancas, etc.) não implementam uma verificação ativa de JWT (Authorization Middleware).
  • O frontend (dbService.ts) faz chamadas comuns via fetch sem incluir o cabeçalho Authorization: Bearer <token>. Como consequência, as rotas do backend do Manager estão abertas para requisições diretas de qualquer cliente que conheça os caminhos das rotas, confiando exclusivamente em isolamento de rede ou segurança por obscuridade.

---

3. Armazenamento de Senhas e Segurança de Dados (PostgreSQL)

A persistência do banco de dados PostgreSQL 15 local segue regras estritas estabelecidas em schema.sql:

• Senhas em Texto Claro (Plain Text):
  • As senhas dos usuários administrativos (tabela usuarios) e dos alunos (tabela alunos no campo senha_portal) são persistidas no banco sem uso de hashing unidirecional (como bcrypt, argon2 ou scrypt). Elas são guardadas e comparadas de forma literal.
• Usuário Padrão Inicial:
  • O script SQL inicial insere automaticamente o usuário administrador padrão com login admin e senha admin (default-admin).
• Integridade Biométrica (Anti-Sobrescrita):
  • Conforme as regras do GEMINI.md, a tabela de alunos armazena dados de biometria facial na coluna face_descriptor (do tipo JSONB). As rotas de sincronização de dados protegem essa coluna usando instruções COALESCE no ON CONFLICT para evitar que biometrias e fotos válidas sejam sobrescritas com valores nulos por sincronizações vindas do JSON legado.

---

4. Segurança no Upload e Armazenamento de Mídia (MinIO S3)

• Isolamento de Credenciais:
  • Todas as credenciais de serviços de terceiros e storage (como MINIO_ACCESS_KEY, MINIO_SECRET_KEY, ASAAS_API_KEY, DATABASE_URL e JWT_SECRET) estão isoladas no arquivo .env e injetadas pelo container Docker. O frontend não tem acesso a essas variáveis, evitando vazamento de credenciais privadas.
• Proxy de Mídia Relativo:
  • Tanto o Manager quanto o Portal servem mídias (fotos de alunos, anexos de justificativas de falta, comprovantes de pagamento e logotipos) através de uma rota dedicada de proxy interno /storage/:bucket/:key (exemplo: server.selfhosted.js).
  • Este proxy acessa internamente o MinIO usando o SDK da AWS e transfere os arquivos por fluxo de dados (data.Body.pipe(res)), ocultando as URLs físicas e as credenciais internas do storage.
  • Essas rotas de proxy são públicas, ou seja, não validam o JWT do aluno ou administrador para entregar a imagem solicitada, garantindo que o carregamento das mídias em tags <img> ocorra sem interrupções por CORS ou autenticação.

---

💡 Principais Pontos de Atenção e Recomendações

Com base no exposto, identifico três pontos sensíveis na arquitetura de segurança atual para seu conhecimento:

1. Exposição de API Administrativa: O backend do EduManager confia no frontend para ocultar as ações, mas as rotas /api/school-data (que lê e escreve toda a base de dados do sistema, incluindo dados financeiros do Asaas) estão abertas e expostas sem validação de tokens JWT no backend do Express.
2. Senhas sem Hash: O armazenamento e validação de senhas em texto plano tanto na tabela usuarios quanto na tabela alunos representa uma vulnerabilidade em caso de vazamento físico ou acesso não autorizado ao banco de dados.
3. Senha Padrão Ativa: Recomenda-se alterar a senha do usuário padrão admin criada no banco assim que possível caso esteja em ambiente de produção.