Skip to content

Diário de Bordo – Henrique Camelo Quenino

Disciplina: Gestão de Configuração e Evolução de Software
Equipe: OWASP (Red Team)
Comunidade/Projeto de Software Livre: EJ-Application
Sprint 4 – 22/10/2025 – 11/11/2025

Resumo da Sprint

Durante a Sprint 4, foquei em testes práticos de injeção e segurança na web (XSS típico, SQLi, rate limiting, headers, CORS), usando técnicas automatizadas realistas (scripts, curl e análise de código) em ambiente autenticado, replicando o comportamento real de um atacante do tipo Red Team. Documentei tanto sucessos quanto limitações e barreiras encontradas, ajustando o escopo aos mecanismos reais da EJ.

Atividades Realizadas

Data Atividade Tipo Resultado/Observação
24/10/2025 Teste de XSS refletido no campo de busca autenticado Teste/PoC Payload aceito, renderização observada e analisada
25/10/2025 Teste de SQL Injection em endpoint de busca autenticado Teste/PoC Backend resistente, não vulnerável aos payloads clássicos
27/10/2025 Validação manual de headers de segurança e CORS Auditoria/manual Headers parciais; CSP e HSTS ausentes, CORS restrito
28/10/2025 Teste de brute force/rate limiting no login Teste/PoC Proteção sólida via CSRF/session, bloqueio por workflow
29/10/2025 Documentação das técnicas e evidências Documentação Prints, scripts e outputs incluídos para auditoria

Detalhamento do Processo e Resultados

1. Testes de XSS (Cross-Site Scripting)

  • Objetivo: Verificar se há reflexão ou persistência de payloads XSS em campos visíveis.
  • Procedimento:
  • Iniciei sessão autenticada manualmente (extraindo cookies do DevTools).
  • Usei curl com header Cookie: para enviar payloads em /conversations/tags/promoted/: bash curl -H "Cookie: csrftoken=...; sessionid=...; ..." \ -G "https://www.ejplatform.org/conversations/tags/promoted/" \ --data-urlencode "search_text=\"><script>alert('XSS')</script>" \ -o resp_xss.html
  • Analisei visualmente o HTML retornado e o comportamento na UI.
  • Resultado:
  • Nenhum XSS executado ou refletido sem escape; payload sempre exibido como string literal no HTML.
  • A aplicação faz encoding/sanitização adequada no output do campo de busca, mitigando XSS refletido e armazenado mesmo com payloads típicos.

2. Testes de SQL Injection

  • Objetivo: Avaliar se parâmetros de busca são concatenados em SQL sem proteção.
  • Procedimento:
  • Repeti o método de autenticação via cookies válidos.
  • Envio de payloads SQL clássicos por curl para /conversations/tags/promoted/: bash curl -H "Cookie: csrftoken=...; sessionid=...;" \ -G "https://www.ejplatform.org/conversations/tags/promoted/" \ --data-urlencode "search_text=' OR '1'='1" \ -o resp_sqli.html
  • Examinei resposta HTML e não identifiquei mudanças, erros de SQL ou vazamentos.
  • Resultado:
  • Nenhum efeito dos payloads; backend trabalha com queries seguras (provavelmente via prepared statements).
  • Não houve erro, bypass, nem vazamento de estrutura SQL.

3. Validação de Headers/CORS

  • Procedimento:
  • Usei curl autenticado para analisar headers: bash curl -H "Cookie: ..." -I "https://www.ejplatform.org/profile/"
  • Resultado:
    • X-Frame-Options: SAMEORIGIN
    • X-Content-Type-Options: nosniff
    • CSP e HSTS ausentes.
  • Para CORS: bash curl -H "Origin: https://malicious.com" -I "https://www.ejplatform.org/api/v1/users/"
    • Endpoint retornou 401, sem vazamento de permissões cross-origin.

4. Teste de Rate Limiting/Brute Force

  • Procedimento:
  • Automatizei requisições de login via curl e pelo script Python (usando CSRF válido).
  • Não foi possível testar brute force massivo, pois o fluxo de autenticação da EJ exige múltiplos controles (token CSRF recente, cookies válidos, possíveis headers adicionais), bloqueando o automation simples.
  • Resultado:
  • Ambiente resistente a ataques de força bruta e automação não-orquestrada.
  • Não houve resposta 429, mas também não foi possível realizar ataque em escala.

Vulnerabilidades e Gaps Práticos Identificados na Sprint

ID Vulnerabilidade Severidade Resultado
S4-XSS XSS (refletido e armazenado) Baixo Não explorável
S4-SQLI SQL Injection N/A Não explorável
S4-HEADERS Headers de segurança (parcial) Médio Reforçar CSP/HSTS
S4-CORS Falha crítica de permissividade Baixo Sem vazamento
S4-BRUTE Rate limiting/brute force Baixa Forte barreira

Maiores Avanços

  • Execução realista, documentada e reprodutível de todos os testes previstos na sprint.
  • Consolidação de metodologia para extrair e usar credenciais de sessão via browser e curl, simulando navegação real.
  • Confirmação, com evidência, das boas práticas implementadas no backend da EJ quanto à sanitização e autenticação.

Maiores Dificuldades

  • Restrições técnicas na automação de brute force devido à robustez dos controles anti-bot/anti-script do Django.
  • Impossibilidade de checkpoint automatizado em dependências sem mapeamento completo do stack.

Aprendizados

  • Proteção contra XSS e SQLi exige não só sanitização de input, mas também output encoding rigoroso e arquitetura de queries seguras.
  • Infra segura se reflete não apenas no backend, mas também em headers, CORS estrito e políticas anti-força bruta.
  • Ferramentas automáticas muitas vezes fracassam em ambientes maduros, necessitando criatividade adaptativa (ex: uso de cookies reais, análise manual de fluxo, scripts sob medida).

Plano Próximo Sprint

  • Recomendar reforço de headers CSP e HSTS na EJ.
  • Avaliar potencial de ataques XXE e deserialização insegura caso hajam APIs e endpoints compatíveis.
  • Consolidar scripts reutilizáveis para automatização de PoCs seguras e didáticas aos colegas de Red Team.