Luna Ferreira Reges
Eu encontro o que
os scanners não encontram.

Contexto. Aplicação web e APIs da plataforma Cardapya, com avaliações autorizadas e monitoramento do ambiente. O que é público aqui é um resumo profissional; evidências, logs e dados operacionais não são divulgados.

FRENTE OFENSIVA

• Controle de acesso entre lojas (Broken Access Control / IDOR): identifiquei que era possível alterar manualmente o identificador de uma loja na URL e acessar outro restaurante — comportamento posteriormente confirmado pela equipe como não esperado.
• Cadastro sem validação adequada: a plataforma permitia a criação de contas utilizando CNPJ, telefone e e-mails sem validação adequada, inclusive com domínios arbitrários, possibilitando cadastros falsos e abuso do fluxo de onboarding.
• Avaliei aproximadamente 130 rotas da API com perfis de cliente, estabelecimento e administrador, verificando autenticação, autorização e isolamento de dados.
• Identifiquei duplicação de cadastros sob requisições simultâneas, fornecendo evidências para orientar correções de unicidade e concorrência.
• Realizei validações manuais e retestes, consolidando alertas automatizados e ajustando a classificação dos achados conforme as evidências e as regras de negócio.

FRENTE DEFENSIVA

• Investiguei atividades suspeitas contra o SSH e implementei 34 regras de bloqueio persistentes no firewall, sem novos eventos da faixa bloqueada na janela pós-mitigação analisada.
• Endureci SSH e Fail2Ban, ampliando bloqueios de 10 minutos para 2 horas, ativando proteção contra reincidência e reduzindo as tentativas de autenticação permitidas por conexão.

ENTREGA E CONTINUIDADE

• Produzi relatórios técnicos e executivos com evidências, impacto e recomendações priorizadas, apoiando decisões de correção e acompanhamento dos riscos.
• Orientei e documentei procedimentos reproduzíveis, apoiando a transferência de conhecimento e a continuidade das avaliações de segurança.

Edição pública de um assessment de API REST (Go / Gin) de um SaaS de delivery de comida, com metodologia white-box + black-box, bateria de testes por categoria do OWASP Top 10 (2021), evidências sanitizadas, diagramas e roadmap de hardening. Todos os dados do cliente, hostnames, identificadores e segredos foram removidos; o relatório original é confidencial.

• Adendo de reavaliação (out/2026): achado CRÍTICO de isolamento multi-tenant entre restaurantes, além de Broken Access Control / IDOR entre lojas e cadastro sem validação adequada — acrescentados ao relatório sem alterar os achados anteriores.
• Dois achados HIGH de lógica de negócio (regras de negócio ausentes, não bugs de framework): escalada vertical de privilégio no auto-registro de loja (CVSS 8.8) e duplicação massiva de cadastro — CNPJ — sob requisições paralelas (CVSS 8.1).
• OWASP Top 10 (2021): 10/10 categorias exercidas no escopo do assessment; autenticação, RBAC, upload e CORS atacados ativamente e validados.
• Entrega: relatório de 28 páginas (edição original de 25 páginas + adendo de reavaliação), 25 achados no total — 22 mapeados em CVSS/CWE/OWASP/ATT&CK mais 3 do adendo — e roadmap de hardening, tudo sanitizado, sem expor o cliente.

Distribuição total (relatório v1.0 + adendo). Relatório original: 0 Crítico · 2 High · 4 Medium · 7 Low · 9 Info. Adendo: 1 Crítico (F-23) e 2 achados de severidade preliminar (F-24 Alto, F-25 Médio).

Aplicação de automação contábil em fase inicial · avaliação Web/API · referências OWASP

Avaliação de segurança de uma aplicação Web/API em fase inicial, envolvendo mapeamento de superfície, reconhecimento, análise de frontend, testes em fluxos de licenciamento, controles client-side, endpoints de telemetria, headers HTTP e tratamento de erros. O trabalho incluiu identificação e validação de comportamentos de segurança, documentação de evidências, análise de impacto e elaboração de recomendações priorizadas, com referências OWASP e respeito ao escopo autorizado.

MINHA ATUAÇÃO

Conduzi e coordenei a avaliação autorizada: defini escopo e metodologia, consolidei as evidências e priorizei as recomendações. A avaliação respeitou estritamente o escopo autorizado.

METODOLOGIA

• Reconhecimento e enumeração de superfície; crawling e descoberta de conteúdo.
• Análise de JavaScript e de artefatos de build do frontend.
• Revisão de autenticação client-side e de fluxos de licenciamento.
• Testes de API e de endpoints de telemetria.
• Análise de headers HTTP, clickjacking e tratamento de erros.
• Validação de controles contra automação e documentação de evidências.

FERRAMENTAS

PRINCIPAIS CLASSES DE ACHADOS

• Restrições de interface baseadas em armazenamento local (controle de acesso aplicado no cliente).
• Controles de autenticação e validação em telemetria de licenciamento.
• Proteções contra tentativas automatizadas (rate limiting / lockout).
• Exposição de detalhes internos por mensagens de erro.
• Ausência de headers de segurança e possibilidade de enquadramento (clickjacking).
• Exposição de artefatos de build do frontend (source maps).
• Recomendações de hardening de servidores e de redirecionamentos.

Red Team e testes de penetração em aplicações web e APIs · apoio à LGPD

Atuação em Red Team e testes de penetração em aplicações web e APIs.

ATUAÇÃO

• Estruturação de escopo e definição de metodologias para testes de segurança.
• Identificação, validação e exploração controlada de vulnerabilidades.
• Análise de falhas de autenticação, autorização, controle de acesso e exposição de dados.
• Elaboração de relatórios técnicos claros e detalhados, com evidências, classificação de criticidade e recomendações de correção.
• Validação de vulnerabilidades identificadas e realização de retestes para confirmar os resultados.
• Apoio a iniciativas de conformidade com a LGPD, com foco na identificação de riscos relacionados à exposição de dados pessoais e no fortalecimento dos controles de segurança.

PRINCIPAIS VULNERABILIDADES IDENTIFICADAS E CORRIGIDAS

• Configuração insegura de CORS.
• Ausência de cabeçalhos de segurança HTTP.
• Ausência de Content Security Policy (CSP).
• Ausência de proteção contra Clickjacking.
• Ausência de Subresource Integrity (SRI).
• Exposição excessiva de informações em endpoints públicos.
• Suporte a protocolos TLS obsoletos.
• Exposição da versão ou tecnologia do servidor HTTP.
• Ausência de HSTS.
• Ausência de X-Content-Type-Options.
• Exposição pública da especificação OpenAPI.
• Identificação de comentários relevantes em código JavaScript.

Consultoria de segurança para uma aplicação do setor financeiro.

Identificação e classificação de vulnerabilidades por severidade em uma aplicação do setor financeiro.

VULNERABILIDADES ALTAS

• Documentos armazenados sem criptografia em repouso: documentos de clientes ficam em texto claro no armazenamento causando exposição dos arquivos revelando informações pessoais, contratos e extratos.
• Ausência de segundo fator no portal do cliente: o acesso utiliza apenas e-mail e senha, inclusive para consultar informações financeiras e realizar assinaturas contratuais. É uma fragilidade de autenticação.
• Permissões excessivas em arquivos de segredo: a chave de assinatura de sessão e o segredo do segundo fator são criados com permissão 0644, permitindo leitura por outros usuários locais.
• Endpoint de saúde sem autenticação e sem cache: a rota /health aceita requisições não autenticadas e executa operações custosas.
• Token de convite exposto na URL: o token pode aparecer em logs e no histórico do navegador durante sua validade, criando risco de uso indevido.

VULNERABILIDADES MÉDIAS

• Endpoint de contato vulnerável a abuso de requisições: aceita gravações mesmo com uma origem não permitida, possui validação de tamanho que pode ser contornada com requisições em blocos e limitações de taxa com controles insuficientes. Há risco potencial de gravações em massa e consumo de recursos.
• Proteção CSRF incompleta no sistema interno: o login interno não valida token CSRF e uma rota de conformidade aceita requisições sem o cabeçalho de contexto de origem.
• Limitação de tentativas de login dependente do processo: os contadores não são compartilhados entre processos. A proteção funcionou nos testes locais, mas pode perder eficácia em uma implantação com múltiplos processos.
• Política CSP em modo de observação: a política de segurança de conteúdo não é aplicada pelo navegador. Isso reduz uma camada de defesa contra determinados ataques de conteúdo.

VULNERABILIDADES BAIXAS

• Proteção contra repetição do segundo fator dependente do processo: o estado antirreplay fica em memória e pode não coordenar corretamente vários processos.