Skip to content

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 3 – 07/10/2025 – 22/10/2025

Resumo da Sprint

Identificação e registro responsável de uma vulnerabilidade do tipo Stored XSS e execução de uma simulação controlada de phishing para avaliar riscos relacionados a engenharia social. Todo trabalho foi documentado e validado via comunicação com o monitor e o canal da comunidade antes da abertura pública do relatório.

Atividades realizadas (detalhado)

Data Atividade Tipo Referência / Observação
15/10/25 Planejamento da simulação de phishing: roteiro, templates e critérios Planejamento / Doc
16–21/10 Alinhamento pré-publicação com monitor e comunidade (Telegram) Comunicação Discussão sobre divulgação responsável
17/10/25 Execução do mock de phishing: email de teste e análise técnica Simulação / Análise Análise de cabeçalhos e campos relevantes
22/10/25 Registro da vulnerabilidade XSS em issue pública Teste / Report Issue: ej-application#1505
22/10/25 Consolidação do relatório final da simulação e decisões tomadas Documentação Relatório anexo ao projeto

Detalhes — Issue de XSS (Stored XSS)

Resumo: Foi identificada uma vulnerabilidade de Cross-Site Scripting persistente em um ponto da aplicação que armazena conteúdo enviado por usuário e o exibe sem a devida sanitização/escape para contexto HTML/DOM.

Contexto e ações tomadas:

  • Verificação inicial realizada em interface local, ambiente de desenvolvimento.
  • Antes da abertura, a descoberta foi discutida com o monitor e com o canal da comunidade para validar o procedimento de divulgação.
  • Decidiu-se por registrar a vulnerabilidade no GitLab (issue pública) pela ausência de canal confidencial disponível.

O que foi entregue na issue:

  • Descrição do comportamento observado (onde o conteúdo é salvo e reapresentado).
  • Passos para reproduzir (descritos em termos operacionais, sem payloads que facilitem exploração em massa).
  • Evidências: screenshots e referência aos endpoints/rotas afetadas (sem divulgar dados sensíveis).
  • Recomendações iniciais de correção (ex.: aplicar escape/output encoding no contexto HTML, validar e sanitizar entradas no servidor e usar Content Security Policy apropriada).

Impacto: Alto em potencial (possibilidade de execução arbitrária de scripts no navegador), mas exploração exige interação de usuário autenticado em funções específicas — o que reduz a probabilidade de exploração em massa.

Status: Issue aberta e registrada: https://gitlab.com/pencillabs/ej/ej-application/-/issues/1505

Detalhes — Simulação de Phishing (spear phishing mock)

Objetivo da simulação: Avaliar quão suscetíveis os usuários da plataforma seriam a um e-mail direcionado que solicita revalidação de conta por “segurança da votação”.

Escopo e limitações éticas:

  • Simulação restrita ao envio de mocks (ex.: email em ambiente controlado ou templates) — nenhuma landing page maliciosa foi hospedada e nenhuma credencial real foi coletada.
  • Todos os artefatos com potencial ofensivo foram mantidos em documento interno e não foram operacionalizados.

Componentes do e-mail simulado:

  • From (simulado): variações próximas ao legítimo (ex.: cd@cidadedemocratica.org.br ou typosquatting em subdomínio) para testar atenção do destinatário.
  • Assunto: texto que cria urgência (“Sua Opinião é Crucial — Ação Requerida”).
  • Corpo: mensagem que imita tom institucional, com CTA para “revalidar conta”.
  • Link exemplo: https://empurrandajuntas.com/revalidacao/login-seguro (exemplo não funcional; apenas ilustrativo).

Análise técnica do e-mail (headers):

  • Exemplos de campos verificados: mailed-by, signed-by, from, date, security (TLS) — para mostrar como um atacante tenta imitar ou manipular metadados.
  • Observação: muitos usuários não verificam campos técnicos; a engenharia social explora esse fato.

Fluxo esperado da simulação (não executado na prática):

  1. Usuário recebe e-mail com CTA urgente.
  2. Usuário clica e é levado a uma página que replica o formulário de login (na simulação, não criada).
  3. Se credenciais fossem submetidas, atacante as coleta e redireciona a vítima para a página legítima para evitar suspeita.

Conclusão da simulação: A simulação demonstrou que um e-mail bem construído (tono, urgência, aparência) tem potencial para induzir cliques; isso evidencia a necessidade de medidas de conscientização, além de controles técnicos (DMARC/DKIM/SPF corretamente publicados, comunicação oficial com links assinados/por subdomínios verificados).

Maiores Dificuldades

  • Ausência de um canal de responsible disclosure para reportes confidenciais.
  • Necessidade de equilibrar detalhamento técnico (útil para correção) com cautela para não facilitar exploração indevida.

Aprendizados

  • Projetos open source devem expor um canal seguro (e preferencialmente automatizado) para recebimento de vulnerabilidades — exemplo: email destinado a segurança ou formulário com PGP/DH chave pública.
  • Para XSS persistente: priorizar output encoding no contexto onde os dados aparecem (HTML text, attributes, JS context), validação do lado servidor e políticas CSP restritivas.
  • Treinamento e simulações regulares de phishing para usuários, e publicação de guias rápidos sobre verificação de e-mails (como checar mailed-by / signed-by).

Plano pessoal para a próxima sprint

  • Produzir documentação TTPs (táticas, técnicas e procedimentos) da XSS e da simulação no formato MITRE ATT&CK.
  • Ataque coordenado contra Blue Team:
    • Pipeline