Diário de Bordo – Mateus Vieira

Disciplina: Gestão de Configuração e Evolução de Software

Equipe: OWASP (Time Red)

Comunidade/Projeto de Software Livre: OWASP (ej-application)

Sprint 2 – 24/09/2025 – 07/10/2025

Resumo da Sprint

Nesta sprint executei a investigação de vulnerabilidades com foco em técnicas de Red Team. O trabalho concentrou-se na identificação e documentação de uma vulnerabilidade de XSS persistente em campos Rich Text da plataforma Empurrando Juntas. Realizei também uma triagem automática por SQL Injection usando sqlmap (level=5, risk=3) sem encontrar falhas exploráveis; CSRF e Clickjacking não foram explorados por mim durante a sprint e ficaram por conta de outros integrantes. A análise resultou em um relatório técnico com diagnóstico, evidências de persistência e recomendações de mitigação.

Atividades Realizadas

Data	Atividade	Tipo	Link/Referência	Status
29/09	Mapeamento inicial dos formulários Rich Text da aplicação	Investigação	–	Concluído
01/10	Análise e documentação da vulnerabilidade XSS persistente (investigação)	Verificação	–	Concluído
02/10	Teste rápido de SQL Injection com sqlmap (level=5, risk=3)	Teste automatizado	Resultado: sem evidências	Concluído
05/10	Validação da persistência da entrada problemática no banco de dados	Investigação	Logs / consulta local (interno)	Concluído
07/10	Redação das recomendações de mitigação (sanitização backend)	Doc	Relatório XSS	Concluído
07/10	Planejamento pessoal para próxima sprint	Planejamento	–	Concluído

Maiores Avanços

Descoberta e documentação de uma vulnerabilidade de XSS Persistente em campos de Rich Text da plataforma EJ (persistência no banco e execução no navegador de usuários).
Identificação da causa raiz: ausência de sanitização server-side e uso inseguro de renderização que permite conteúdo não-escape ser inserido no DOM.
Triagem com sqlmap (level=5, risk=3) não encontrou vetores de SQL Injection na superfície testada.

Maiores Dificuldades

Busca exaustiva sobre os endpoints da API até encontrar uma maneira de burlar o sistema de sanitização.
- Os endpoints foram bem feitos. Logo, foi complexo encontrar um caso específico em que há vulnerabilidade XSS.

Aprendizados

Sanitização server-side é mandatória mesmo com validações client-side.
Rich Text + renderização sem escape aumenta severidade de XSS persistente.
Ferramentas automatizadas (ex.: sqlmap) são úteis para triagem, mas análise manual orientada continua necessária.

Exploração (XSS) — Resumo Técnico

Classificação

Cross-Site Scripting Persistente (Stored XSS). Este é o tipo mais prejudicial de XSS, pois o payload malicioso é salvo no servidor da aplicação, afetando múltiplos usuários ao longo do tempo.
Localização Específica

Campos de Rich Text. O conteúdo inserido nesses campos é transformado em marcações HTML e armazenado permanentemente no banco de dados da aplicação.
Causa Raiz Primária

Falha na Sanitização do Backend. A interface de usuário (frontend) pode ter mecanismos de filtragem, mas a API de backend não realiza essa mesma validação e filtragem. Isso quebra o princípio de Defesa em Profundidade.
Causa Raiz Secundária

Renderização Insegura (Jinja2). A aplicação utiliza filtros que instruem o Jinja2 a não escapar caracteres HTML, permitindo que o script injetado seja executado em sua forma bruta no navegador da vítima.
Impacto Potencial
- Qualquer usuário que acesse a página da Conversa comprometida será afetado, independentemente de suas permissões.
- A execução de scripts arbitrários no contexto da sessão da vítima permite ações não autorizadas pelo atacante, como:
  - Roubo de Cookies de Sessão (session hijacking).
  - Captura de Credenciais digitadas (keylogging).
  - Modificação do Conteúdo da página visualizado.
  - Redirecionamento do usuário para sites maliciosos.

Link: Relatório Completo de Reprodução e Análise da Vulnerabilidade

Obs: O relatório completo é um arquivo privado no OneDrive e, até o momento, só está liberado para a professora da disciplina.

Estudo

IDOR (Insecure Direct Object Reference)

O que é: IDOR é uma falha de controle de acesso em que a aplicação expõe identificadores diretos, como IDs, caminhos ou parâmetros, sem verificar se o usuário tem autorização para acessá-los. Isso permite que um invasor manipule esses valores e acesse, altere ou exclua dados de outros usuários. De acordo com o OWASP, esse tipo de vulnerabilidade é comum em APIs REST e aplicações que utilizam identificadores previsíveis, sendo um dos vetores mais simples e críticos de vazamento de informações.

Exemplo no contexto EJ: Na plataforma Empurrando Juntas, um endpoint que retorna dados de conversas com base em um conversation_id previsível poderia permitir que um atacante autenticado visualizasse mensagens ou feedbacks de outras organizações. Se a aplicação não validar a propriedade da conversa, bastaria alterar o valor do ID na URL para acessar dados sensíveis de terceiros, comprometendo a privacidade e a integridade das informações da plataforma.

Ref: OWASP - IDOR

Sessões / Cookies Inseguros

O que é: Sessões e cookies inseguros referem-se a falhas na configuração ou gestão desses mecanismos de autenticação. Cookies sem as flags HttpOnly, Secure ou SameSite podem ser acessados via JavaScript, transmitidos em conexões não seguras ou utilizados em requisições cross-site, permitindo roubo ou reutilização de sessão. Segundo o OWASP, essa é uma das causas mais comuns de sequestro de sessão e elevação de privilégios em aplicações web.

Exemplo no contexto EJ: Se os cookies de sessão da EJ não possuírem a flag HttpOnly e existir uma vulnerabilidade de XSS (como a identificada nesta sprint), um invasor poderia injetar um script que coleta o cookie do usuário e o envia para seu próprio servidor. Com isso, ele conseguiria assumir a sessão da vítima, agir em nome dela e acessar dados confidenciais, simulando ser um usuário legítimo dentro da plataforma.

Ref: OWASP - Session Management

Brute Force / Rate Limiting

O que é: Ataques de Brute Force consistem em tentativas sucessivas e automatizadas de adivinhação de senhas, tokens ou credenciais de acesso. O OWASP destaca que, sem mecanismos de rate limiting ou bloqueios progressivos, uma aplicação pode ser explorada por ataques de força bruta, password spraying ou credential stuffing. Isso é especialmente preocupante em endpoints de login e recuperação de senha, onde a falta de controle de requisições facilita o comprometimento de contas.

Exemplo no contexto EJ: Na plataforma EJ, se o endpoint de login não possuir limitação de tentativas por IP ou usuário, um atacante poderia automatizar tentativas de senha usando listas de credenciais comuns até encontrar combinações válidas. Além disso, APIs que validam tokens ou autenticações parciais também podem ser abusadas com fuzzing e ataques de força bruta, comprometendo a disponibilidade e a segurança do sistema.

Ref: OWASP - Credential Stuffing

Plano Pessoal para a Próxima Sprint

Envio do Relatório de Vulnerabilidade para o time da EJ
Ataques IDOR
Ataques de sessão
Abusar de APIs (rate-limit, fuzzing)
Simular phishing no contexto da plataforma