📝 Relatório de Contribuição – Sprint 4

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

Equipe: OWASP (Times Blue e Red)

Período da Sprint: 22/10/2025 - 19/11/2025

1. Objetivos da Sprint

Blue Team

Estabelecer o Ambiente: Definir um fork oficial do projeto que servirá como ambiente de desenvolvimento e testes para a implementação do pipeline.
Integrar o Arsenal: Adicionar os seguintes jobs a um novo stage de segurança (security_scan) no arquivo .gitlab-ci.yml.

Red Team

Continuidade dos ataques coordenados sobre a EJ
- Session Hijacking
Exploração de vulnerabilidades Web.
Estudo sobre novas ferramentas de ataques e verificação
- GoPhish
- MailHog
Contribuição para detecção, exploração controlada e solução de XSS na EJ-Application.

2. Entregas Coletivas

Entrega	Status (Concluído/Parcial/Pendente)	Observações
Ataque de Session Hijacking sobre EJ	Concluído	Marcus V. & Júlio César
Implementação das ferramentas de segurança na pipeline	Concluído	Ana Carol, Sebastian e Daniel
Relatorio sobre a implementação e vulnerabilidades encontradas	Concluído	Miguel, Breno e Peixoto

3. Contribuições Individuais

Integrante	Contribuições	Links (PRs, Issues, Docs)	Observações
Mateus Vieira	Fix do XSS na plataforma EJ	MR #392
Miguel Arthur	--------	-------------------------	-----------
Henrique Camelo Quenino	Testes de XSS refletido/armazenado, SQL Injection, headers/CORS e brute force na EJ-Application, com diário técnico detalhado da Sprint 4	Diário Sprint 4

4. Maiores Avanços

Blue Team

1. Integração do Arsenal de Segurança no CI/CD

O principal marco desta sprint foi a transição do planejamento para a execução técnica. O ambiente de CI/CD do GitLab foi configurado para executar verificações de segurança automáticas a cada push, estabelecendo a primeira linha de defesa ativa do projeto.

🔹 Criação do Estágio `security_scan`

Foi criado um novo estágio no arquivo .gitlab-ci.yml, dedicado exclusivamente à execução de testes de segurança.

🔹 Jobs Automatizados

As ferramentas selecionadas foram integradas com sucesso:

Gitleaks — para detecção de segredos.
Semgrep — para análise estática de código (SAST).
pip-audit — para análise de vulnerabilidades em dependências (SCA).
Trivy — análise de vulnerabilidades em filesystem, dependências e configurações (SCA + Config Scan).
Essas ferramentas agora garantem que o código, as dependências e a busca por segredos sejam auditados continuamente a cada alteração enviada ao repositório.

2. Relatório Técnico de Implementação e Vulnerabilidades

Além da configuração da infraestrutura, a equipe executou a primeira rodada de análises e registrou os resultados obtidos.

🔹 Diagnóstico Inicial

Foi gerado um relatório completo detalhando como cada ferramenta foi integrada ao pipeline, incluindo:

Configurações realizadas no GitLab CI/CD
Estágios e jobs adicionados
Parâmetros e flags utilizadas nas ferramentas
Fluxo de execução em commits e merge requests

🔹 Análise de Achados

As primeiras vulnerabilidades identificadas foram analisadas e documentadas, constituindo a base de dados inicial para as próximas ações de hardening.

Entre os achados iniciais, destacam-se:

Resultados de detecção de segredos (Gitleaks)
Vulnerabilidades em bibliotecas registradas pelo pip-audit
Alertas de código potencialmente inseguro encontrados pelo Semgrep

Este mapeamento permitirá direcionar as correções nas próximas sprints, priorizando os riscos mais críticos.

Red Team

PR de fix sobre XSS

Tendo em vista a Issue #1505, o qual foi aberta durante a sprint 3, com o objetivo de reportar a falha de XSS identificada sobre a plataforma EJ. Agora, na sprint 4 foi realizado o MR com a proposta de solução para tal problema de vulnerabilidade, o mesmo pode ser identificado por: MR #392.

Solução do XSS

Após estudos e testes, a solução foi implementada diretamente nos métodos clean_welcome_message e clean_ending_message do formulário de conversação:

def _clean_html_field(self, field_name):
    data = self.cleaned_data.get(field_name, "")
    return nh3.clean(
        data,
        attributes={
            "*": {"style", "href"}
        },
        filter_style_properties={"color", "font-weight", "text-align", "background-color"}
    )

def clean_welcome_message(self):
    return self._clean_html_field("welcome_message")

def clean_ending_message(self):
    return self._clean_html_field("ending_message")

Contribuições de Teste e Validação

Testes de XSS (Cross-Site Scripting)

Objetivo: validar se campos de busca e componentes da EJ-Application refletiam ou armazenavam conteúdo potencialmente malicioso sem sanitização adequada.
Procedimento: sessão autenticada obtida via navegador, exportando manualmente cookies (csrftoken, sessionid, show_welcome_window) e usando-os em requisições curl contra o endpoint /conversations/tags/promoted/ com payloads como "><script>alert('XSS')</script>.
Resultado: as respostas HTTP 200 retornaram o payload codificado como texto, sem execução de scripts, indicando uso consistente de output encoding/sanitização na camada de apresentação.

Testes de SQL Injection

Objetivo: avaliar se parâmetros de busca eram concatenados em SQL permitindo injeção.
Procedimento: envio de payloads como ' OR '1'='1 via curl autenticado para o mesmo endpoint de busca, salvando as respostas em arquivos HTML para análise detalhada.
Resultado: não foram observados erros de banco, vazamento de mensagens SQL, alterações indevidas em resultados ou bypass de lógica, sugerindo uso de prepared statements e validação adequada no backend.

Validação de Headers de Segurança e CORS

Foi realizada inspeção de headers com curl autenticado em /profile/, confirmando presença de X-Frame-Options: SAMEORIGIN e X-Content-Type-Options: nosniff, mas ausência de Content-Security-Policy e Strict-Transport-Security, o que indica oportunidade de hardening adicional.
Para CORS, requisições com Origin: https://malicious.com em /api/v1/users/ retornaram 401 sem exposição de recursos cross-origin, indicando política de CORS alinhada ao modelo de autenticação.

Testes de Rate Limiting e Força Bruta

Foram desenvolvidos scripts em bash e Python (com requests e BeautifulSoup) para automatizar login com CSRF válido e sessão persistente, buscando simular tentativas repetidas de autenticação.
Na prática, o fluxo de autenticação da EJ, com validação rígida de CSRF e cookies de sessão, dificultou a execução de ataques de brute force em escala direta via curl, o que evidencia robustez do mecanismo de autenticação, ainda que sem evidência explícita de respostas 429.

Ataque Session Hijacking

Foi realizado um ataque de Session Hijacking bem sucedido (encontrou uma falha) na aplicação EJ, a falha acontece porque o cookie sessionid não possui flag Secure ativada, possibilitando que um atacante roube o valor do cookie para logar como se fosse a vítima (roubo de sessão)

Para a execução do ataque é preciso simular uma vítima e um atacante, a máquina vítima é uma máquina virtual rodando Kali Linux com network modo Bridge, a máquina host é o atacante, a vítima loga no site normalmente usando seu email e senha, o atacante intercepta a requisição http usando alguma ferramenta de sniffing como tcpdump ou Wireshark, copia o valor do sessionid e cria um cookie com o valor copiado, ao dar reload ele estará logado como a vítima.

5. Maiores Dificuldades

Blue Team

Implementar as ferramentas no arquivo .yml do projeto

Red Team

Não foram identificadas dificuldades por parte do red team.

6. Lições Aprendidas

Blue Team

Integração de Segurança é Mais Eficiente Quando Automatizada
A inclusão dos scans no CI/CD demonstrou que falhas e segredos são identificados mais cedo, reduzindo retrabalho e riscos acumulados.
Ferramentas Complementares São Essenciais
Cada ferramenta cobre uma superfície diferente (SAST, SCA, secrets, IaC). Usá-las em conjunto aumenta a profundidade da análise e reduz pontos cegos.

Red Team

Realização do ataque do tipo Session Hijacking
Como utilizar bibliotecas de sanitização de strings com HTML em Python para remover tags inseguras
Aprendizado prático de como replicar a navegação de um usuário real via cookies, CSRF e scripts personalizados, para testar XSS, SQLi e brute force em ambiente autenticado.

7. Planejamento para a Próxima Sprint

Blue Team

Abrir o MR para atualizar a pipeline
Mudar da detecção para a prevenção e mitigação, aplicando melhorias de segurança diretamente na configuração da aplicação (Django) e da infraestrutura como código (Dockerfile).
Entender como funciona o scan de imagens Docker e a diferença entre vulnerabilidades do S.O. e da aplicação.
Pesquisar sobre o que é um Web Application Firewall (WAF) e comparar as principais soluções open-source (ex: ModSecurity) e de provedores de nuvem.

Red Team

Documentar TTPs no formato MITRE ATT&CK

📝 Relatório de Contribuição – Sprint 4

1. Objetivos da Sprint

Blue Team

Red Team

2. Entregas Coletivas

3. Contribuições Individuais

4. Maiores Avanços

Blue Team

1. Integração do Arsenal de Segurança no CI/CD

🔹 Criação do Estágio security_scan

🔹 Jobs Automatizados

2. Relatório Técnico de Implementação e Vulnerabilidades

🔹 Diagnóstico Inicial

🔹 Análise de Achados

Red Team

PR de fix sobre XSS

Solução do XSS

Contribuições de Teste e Validação

Testes de XSS (Cross-Site Scripting)

Testes de SQL Injection

Validação de Headers de Segurança e CORS

Testes de Rate Limiting e Força Bruta

Ataque Session Hijacking

5. Maiores Dificuldades

Blue Team

Red Team

6. Lições Aprendidas

Blue Team

Red Team

7. Planejamento para a Próxima Sprint

Blue Team

Red Team

🔹 Criação do Estágio `security_scan`