00
4
Ativos em Escopo
10
Dias de Execução
OWASP
Top 10 + API Top 10
6m
Acompanhamento
GRAY
Modalidade Box
Identificação do Projeto
Ativos Autorizados — Escopo Oficial
🌐 https://www.maisloc.com.br · Front Principal
⚙️ maislocacoes.azurewebsites.net · API Backend
🔥 https://mais-locacoes-suport.web.app · Firebase Front
📄 https://maiscontratos.app.br · Front Contratos
🖧 45.230.209.77 · IP Fixo Autorizado
Stack Tecnológica (Client-Informed)
| Camada | Tecnologia | Vetor de Risco |
|---|---|---|
| Backend | C# / .NET | MÉDIO |
| Frontend | Dart / Flutter | ALTO |
| Banco de Dados | PostgreSQL | MÉDIO |
| Nuvem | Microsoft Azure | MÉDIO |
| CDN | Cloudflare | BAIXO |
| Hosting Front | Firebase | ALTO |
| Pagamentos | Asaas | ALTO |
| Storage | Wasabi | MÉDIO |
| Autenticação | JWT (inferido) | ALTO |
Roles de Acesso Autorizadas para Testes
| Role | Usuário de Teste | Status |
|---|---|---|
| owner | jeferson@maisloc.com.br | ⏳ Senha Pendente |
| employee | A confirmar com cliente | ⏳ Pendente |
| delivery | A confirmar com cliente | ⏳ Pendente |
| admin | Não existe — documentado no contrato | |
⚠️ Ação requerida: Solicitar ao Rafael criação de 3 usuários de teste (um por role) via WhatsApp criptografado antes do Dia 8.
FORA DO ESCOPO — Restrições Contratuais
Auditoria completa do ambiente Azure
Apenas exposição visível relacionada à aplicação web
Red Team / Operação encoberta
Pentest autorizado e declarado
Engenharia Social / Phishing / Vishing
Explicitamente fora do escopo neste contrato
DoS / DDoS ou qualquer teste de disponibilidade
Pentest de rede interna profundo
Não há acesso à rede interna neste escopo
Revisão completa de código-fonte
Exploração destrutiva ou com impacto operacional
Correção técnica / Desenvolvimento
Papel exclusivo do time de dev do cliente
01
Princípio de redação: Cada vulnerabilidade deve ser explicada em termos de "o que pode acontecer com o seu negócio", nunca apenas como um problema técnico. Um CEO precisa entender o risco, não o exploit.
Estrutura de Capítulos
Capa e Informações do Documento
Cap. 1 — Resumo Executivo (1 página)
Parágrafo de contexto: quem realizou o trabalho, quando, e qual foi o objetivo. Escrito para ser lido em 2 minutos.
// Estrutura do parágrafo de abertura
"A Tander Security realizou entre [DATA] e [DATA]
um Teste de Intrusão (Pentest) direcionado à
redução de risco nos sistemas web da MAIS LOCAÇÕES.
O trabalho avaliou [N] ativos digitais da empresa,
identificando [N] vulnerabilidades, sendo [N] de
nível CRÍTICO, [N] ALTO, [N] MÉDIO e [N] BAIXO.
O resultado indica que [perfil de risco geral].
A recomendação imediata é [ação prioritária]."
Elementos obrigatórios do resumo:
Quantitativo de vulnerabilidades por severidade
Nível de risco geral do ambiente (score visual)
Top 3 riscos de negócio identificados
Ações prioritárias (plano de 30 dias)
Declaração de escopo e limitações
Cap. 2 — Perfil de Risco do Negócio
Para cada achado CRÍTICO e ALTO, traduzir o impacto técnico em linguagem de negócio. Exemplos de perguntas a responder:
IMPACTO FINANCEIRO
Um atacante poderia acessar dados de pagamento dos clientes? Gerar cobranças indevidas no Asaas? Causar prejuízo direto?
IMPACTO LEGAL/LGPD
Há exposição de dados pessoais de clientes? A falha configuraria notificação obrigatória à ANPD? Há risco de multa ou sanção?
IMPACTO REPUTACIONAL
Se explorado, o incidente seria visível aos clientes? Geraria perda de contratos? Afetaria a percepção de confiança no SaaS?
Cap. 3 — Dashboard de Vulnerabilidades (visual)
Representação visual para o executivo. Exemplo de estrutura:
[N]
CRÍTICO
Correção imediata
[N]
ALTO
Até 7 dias
[N]
MÉDIO
Até 30 dias
[N]
BAIXO/INFO
Próximo ciclo
Cap. 4 — Plano de Ação Priorizado
Tabela de ações em linguagem executiva — o que corrigir, em qual ordem e por quê. Sem código. Sem exploits. Apenas o que importa para a tomada de decisão.
| # | Ação Recomendada | Prazo | Responsável | Prioridade |
|---|---|---|---|---|
| 01 | [Descrição executiva da correção 1] | Imediato | Time Dev | CRÍTICO |
| 02 | [Descrição executiva da correção 2] | 7 dias | Time Dev | ALTO |
| 03 | [Descrição executiva da correção 3] | 30 dias | Time Dev / Infra | MÉDIO |
Cap. 5 — Declaração de Escopo e Limitações
Texto padrão obrigatório: "A ausência de vulnerabilidades críticas NÃO ELIMINA riscos futuros. Este relatório representa o nível de exposição identificado durante o período de execução dos testes, dentro do escopo formalmente acordado. Novas funcionalidades, atualizações de dependências ou mudanças de configuração podem introduzir novos riscos não contemplados neste documento."
02
Estrutura de Capítulos — Relatório Técnico
| Capítulo | Conteúdo | Destinatário |
|---|---|---|
| 1. Escopo Técnico | Ativos testados, URLs, IPs, tecnologias, ferramentas, datas | TI / Dev |
| 2. Metodologia Aplicada | OWASP Top 10, OWASP API Top 10, PTES, NIST SP 800-115 | TI / Dev |
| 3. Resumo de Findings | Tabela consolidada de todas as vulnerabilidades | TI / Dev / Gestão |
| 4. Findings Detalhados | Um finding card completo por vulnerabilidade (template abaixo) | Dev |
| 5. Observações (Não-Confirmados) | Achados que precisam de validação adicional — não são vulns | Dev / TI |
| 6. Testes Sem Achado | Categorias testadas onde não foram encontradas vulnerabilidades | TI / Gestão |
| 7. Recomendações de Hardening | Melhorias de segurança além das vulnerabilidades encontradas | Dev / TI |
| 8. Apêndice de Evidências | Screenshots, logs, requests/responses completos | Dev |
Tabela Consolidada de Findings (Modelo)
Tabela Mestre de Vulnerabilidades
| ID | Título | Severidade | CVSS | Ativo | OWASP | Status | Reteste |
|---|---|---|---|---|---|---|---|
| BD-001 | [A ser preenchido] | CRÍTICO | — | [URL] | [A0X] | ABERTO | Sim |
| BD-002 | [A ser preenchido] | ALTO | — | [URL] | [A0X] | ABERTO | Sim |
| [ Linhas populadas durante execução pelo ZEUS-OPS ] | |||||||
Regras de Qualidade — Zero Falso Positivo
Critérios para Vulnerabilidade
Evidência técnica reproduzível
Request + Response + Screenshot ou vídeo
Confirmado em ao menos 2 tentativas independentes
Descartada possibilidade de falso positivo por scanner
Impacto real demonstrado ou demonstrável com segurança
Dados sensíveis mascarados na evidência (CPF, senhas, etc)
Critérios para Observação (não-confirmado)
Comportamento suspeito sem exploração confirmada
Scanner sinalizou mas teste manual não confirmou
Requer acesso adicional não disponível no escopo
Informação insuficiente para determinar exploitability
Observações são registradas no Cap. 5 com flag clara. Nunca aparecem como vulnerabilidade no dashboard executivo.
03
Diagrama Lógico de Ativos
☁️ Cloudflare WAF + CDN
IP Real: 45.230.209.77 (autorizado)
DNS: Cloudflare
↓ HTTPS ↓
🌐 maisloc.com.br · Flutter Web
🌐 maiscontratos.app.br · Flutter Web
🔥 mais-locacoes-suport.web.app · Firebase Hosting
↓ API Calls ↓
⚙️ maislocacoes.azurewebsites.net · Azure App Service · C# .NET
🗄️ PostgreSQL · Azure SQL Database
🔐 Azure WAF · App Service
↓ Integrações 3rd Party ↓
💳 Asaas · Pagamentos
🤖 OpenAI GPT · IA
🔥 Firebase · Auth/DB
🗃️ Wasabi · Object Storage
📋 ACBR · NF-e
🏢 CNPJA · Consulta CNPJ
📬 ViaCep · CEP
🇧🇷 BrasilApi · Dados Públicos
Estação Ofensiva — ZEUS-OPS / Kali
O Kali é a estação ofensiva, não o alvo. Toda ação parte daqui. Nada é executado fora do horário autorizado (09h-17h Seg-Sex) para fases de exploração.
Camadas de Proteção Identificadas
| Proteção | Status | Impacto no Teste |
|---|---|---|
| Cloudflare WAF | ATIVA | Possível bloqueio de payloads — bypass a testar |
| Azure WAF | ATIVA | Segunda camada — App Service level |
| IDS/IPS | DECLARADO | Pode gerar alertas — notificar cliente se bloqueio |
| Backup Diário | CONFIRMADO | Pré-requisito de segurança para início |
04
Frameworks Aplicados
| Framework | Aplicação no Projeto |
|---|---|
| OWASP Top 10 (2021) | Cobertura dos 10 principais riscos em aplicações web |
| OWASP API Security Top 10 | Testes específicos nos endpoints REST da API .NET |
| PTES | Estrutura geral das fases do pentest |
| NIST SP 800-115 | Guia técnico de testes de segurança |
| CVSSv3.1 | Pontuação e classificação de severidade |
Abordagem Gray Box
Cobertura OWASP Top 10 (2021)
| Categoria | Descrição | Vetores no Projeto | Fase |
|---|---|---|---|
| A01 Broken Access Control | Controle de acesso falho | IDOR entre roles, BOLA na API | 4 |
| A02 Crypto Failures | Falhas criptográficas | JWT fraco, dados em trânsito sem TLS | 3 |
| A03 Injection | Injeção SQL/NoSQL/Command | Endpoints API + PostgreSQL | 3 |
| A04 Insecure Design | Design inseguro | Lógica de negócio, fluxo de pagamento | 4 |
| A05 Security Misconfiguration | Configuração insegura | Headers HTTP, CORS, Azure, Firebase | 2/3 |
| A06 Outdated Components | Componentes desatualizados | Libs .NET, pacotes Flutter | 2 |
| A07 Auth Failures | Falhas de autenticação | JWT manipulation, session management | 3/4 |
| A08 SSRF | Falsificação de requisição | Integrações: ViaCep, CNPJA, BrasilApi | 3 |
| A09 Logging Failures | Falhas de monitoramento | Logs de erros, exposição de stack trace | 3 |
| A10 SSRF (Server-Side) | SSRF server-side | Webhook endpoints, URLs externas aceitas | 3 |
Cobertura OWASP API Security Top 10
| Categoria | Foco | Aplicação em maislocacoes.azurewebsites.net |
|---|---|---|
| API1 BOLA | Broken Object Level Authorization | Acesso a objetos de outros tenants via ID manipulation |
| API2 Broken Auth | Autenticação quebrada | JWT, tokens de sessão, reset de senha |
| API3 BOPLA | Broken Object Property Level Auth | Mass assignment, campos protegidos via POST/PUT |
| API4 Resource Consumption | Consumo excessivo | Rate limiting nos endpoints |
| API5 BFLA | Broken Function Level Auth | Endpoints admin acessíveis por roles inferiores |
| API6 Sensitive Data Exposure | Exposição de dados | Respostas com PII, dados de pagamento, tokens |
| API7 Security Misconfiguration | Config insegura | CORS, métodos HTTP, error verbosity |
| API8 Injection | Injeção via API | Query parameters, headers, body payloads |
05
Regra fundamental: Evidência não é opcional. Se não está documentado, não aconteceu. Se não é reproduzível, não é vulnerabilidade.
Tipos de Evidência Aceitos
| Tipo | Formato | Quando Usar | Obrigatório? |
|---|---|---|---|
| HTTP Request/Response | Burp Suite export · .txt · .xml | Toda vulnerabilidade web | SIM |
| Screenshot | PNG com anotações | Confirmação visual do impacto | SIM |
| Vídeo de exploração | MP4 · máx. 2 min | Findings CRÍTICOS e ALTOS | Recomendado |
| Log de comandos | Terminal output · .txt | Comandos executados no Kali | SIM |
| Saída de ferramenta | nuclei, sqlmap, nmap output | Scan findings | Complementar |
| Código de exploit | Python/Bash script | Exploração customizada | Quando aplicável |
Protocolo de Proteção de Dados
CPF, CNPJ, e-mails de clientes reais → MASCARAR
Ex: 123.***.***-87 | joao***@email.com
Senhas, tokens e API keys → REDACT COMPLETO
[TOKEN_REDACTED] ou [API_KEY_REDACTED]
Dados bancários → NUNCA incluir na evidência
Nomes de clientes reais → [CLIENTE_N] anonimizado
Evidências armazenadas em disco criptografado
Estrutura de Nomenclatura de Arquivos
# Padrão de nomenclatura obrigatória
BD-{ID}_{SEVERIDADE}_{TIPO}.{ext}
# Exemplos:
BD-001_CRIT_request.txt
BD-001_CRIT_response.txt
BD-001_CRIT_screenshot.png
BD-001_CRIT_video.mp4
BD-002_HIGH_command-output.txt
BD-003_MED_screenshot-01.png
# Estrutura de pastas:
/evidence/
/BD-001_BOLA/
/BD-002_JWT/
/BD-003_SSRF/
/observations/ # não-confirmados
06
Matriz Probabilidade × Impacto
| Impacto BAIXO | Impacto MÉDIO | Impacto ALTO | Impacto CRÍTICO | |
|---|---|---|---|---|
| Prob. ALTA | MÉDIO | ALTO | CRÍTICO | CRÍTICO |
| Prob. MÉDIA | BAIXO | MÉDIO | ALTO | CRÍTICO |
| Prob. BAIXA | INFO | BAIXO | MÉDIO | ALTO |
Definição de Severidades — CVSS + Negócio
| Nível | CVSS | Prazo Correção | Comunicação |
|---|---|---|---|
| CRÍTICO | 9.0 – 10.0 | Imediato | WhatsApp + E-mail Rafael |
| ALTO | 7.0 – 8.9 | ≤ 7 dias | No relatório + reunião |
| MÉDIO | 4.0 – 6.9 | ≤ 30 dias | No relatório |
| BAIXO | 0.1 – 3.9 | Próximo sprint | No relatório |
| INFO | 0.0 | Oportunidade | Hardening recomendado |
Ajuste de Impacto — Contexto MaisLocações
Vetores de Risco Prioritários — Pré-Execução
| Vetor | Probabilidade | Impacto | Risco Estimado | Justificativa |
|---|---|---|---|---|
| BOLA/IDOR entre roles | ALTA | CRÍTICO | CRÍTICO | SaaS B2B multi-tenant sem admin declarado — padrão de risco elevado |
| JWT Manipulation | MÉDIA | CRÍTICO | CRÍTICO | Flutter expõe lógica de auth; alg confusion é frequente em .NET |
| Firebase Data Exposure | ALTA | ALTO | CRÍTICO | Rules mal configuradas é o vetor #1 em Firebase Hosting |
| SQLi na API .NET | MÉDIA | CRÍTICO | ALTO | PostgreSQL + .NET com ORM mal utilizado pode ter pontos de injeção |
| SSRF via 3rd parties | MÉDIA | ALTO | ALTO | 8 integrações externas aumentam superfície de SSRF significativamente |
| Wasabi Bucket Público | MÉDIA | ALTO | ALTO | Contratos e documentos de locação — dado LGPD sensível |
| Security Headers Ausentes | ALTA | BAIXO | MÉDIO | Flutter Web frequentemente carece de CSP, HSTS, X-Frame-Options |
07
Pré-Requisitos — Início dos Testes
Contrato assinado por ambas as partes
01/04/2026 — Rafael Spagnol + Jeferson
CONCLUÍDO
ROE (Rules of Engagement) assinado
Janelas de teste, IPs, contatos de emergência
CONCLUÍDO
NDA assinado — 5 anos de confidencialidade
CONCLUÍDO
URLs e subdomínios documentados e confirmados
CONCLUÍDO
IP autorizado confirmado (45.230.209.77)
CONCLUÍDO
Backup diário confirmado pelo cliente
CONCLUÍDO
Contato técnico 24h definido
Rafael Spagnol — (16) 99711-0308
CONCLUÍDO
Credenciais de teste recebidas com segurança
Via WhatsApp criptografado — aguardando
PENDENTE
Usuários para roles employee e delivery criados
Necessário para Fase 4 — Dias 8-9
PENDENTE
Checklist por Fase de Execução
FASE 1 (Dias 1-2) — Reconhecimento Passivo
OSINT · Subfinder · Shodan · GitHub Dorks · Wayback
FASE 2 (Dias 3-4) — Enumeração Ativa
Nmap · ffuf · nuclei passivo · Firebase Rules
FASE 3 (Dias 5-7) — Exploração Web OWASP
Burp · sqlmap · jwt_tool · dalfox · SSRFmap
FASE 4 (Dias 8-9) — Testes Autenticados
IDOR · BOLA · Privilege Escalation · Mass Assignment
FASE 5 (Dia 10) — Consolidação
Validação · Evidências · Relatório · Reunião
Checklist de Cobertura OWASP — Por Ativo
| Teste | maisloc.com.br | API (.azurewebsites) | Firebase Front | maiscontratos.app.br |
|---|---|---|---|---|
| A01 - Broken Access Control | ⏳ | ⏳ | ⏳ | ⏳ |
| A02 - Crypto Failures | ⏳ | ⏳ | ⏳ | ⏳ |
| A03 - Injection | ⏳ | ⏳ | N/A | ⏳ |
| A04 - Insecure Design | ⏳ | ⏳ | N/A | ⏳ |
| A05 - Misconfiguration | ⏳ | ⏳ | ⏳ | ⏳ |
| A07 - Auth Failures | ⏳ | ⏳ | ⏳ | ⏳ |
| A08 - SSRF | N/A | ⏳ | N/A | N/A |
| API1 - BOLA | N/A | ⏳ | N/A | N/A |
| API5 - BFLA | N/A | ⏳ | N/A | N/A |
⏳ = Pendente · ✓ = Concluído · ✗ = Não aplicável · N/A = Fora de escopo para este ativo
08
Timeline de Execução
Concluído — 01/04/2026
Assinatura do Contrato e ROE
Formalização legal completa. NDA, autorização de pentest, escopo final e contatos de emergência definidos e assinados por ambas as partes.
Dias 1–2 · Seg–Ter
FASE 1 — Reconhecimento Passivo
OSINT completo, mapeamento de superfície de ataque, exposição pública, vazamento de credenciais em repositórios. Impacto zero na operação da MaisLocações.
Dias 3–4 · Qua–Qui
FASE 2 — Enumeração Ativa
09h–17h. Port scan controlado, fingerprint de tecnologias, mapeamento de endpoints da API, análise de regras Firebase, verificação de buckets Wasabi.
Dias 5–7 · Sex–Ter
FASE 3 — Exploração Web (OWASP Top 10)
09h–17h. Testes ativos: SQLi, XSS, JWT manipulation, SSRF via integrações, CORS, headers de segurança, misconfigurations Azure. Findings CRÍTICOS comunicados imediatamente.
Dias 8–9 · Qua–Qui
FASE 4 — Testes Autenticados
09h–17h. Com credenciais das 3 roles. BOLA/IDOR, escalonamento de privilégios, mass assignment, lógica de negócio, fluxos críticos (locação, cobrança, documentos).
Dia 10 · Sex
FASE 5 — Consolidação e Encerramento
Validação final de todos os findings, documentação de evidências, início da redação dos relatórios, comunicação de encerramento dos testes ao cliente.
D+10 a D+15 (após execução)
Entrega dos Relatórios
Relatório Executivo + Relatório Técnico entregues ao Rafael. Documento classificado como CONFIDENCIAL, distribuição restrita.
D+17 a D+22 (após entrega)
Reunião de Apresentação dos Resultados
Call com Rafael + time técnico. Walkthrough completo dos findings — do CRÍTICO ao INFO. Plano de ação e próximos passos.
6 meses (após entrega do relatório)
Período de Acompanhamento Técnico
Suporte consultivo: esclarecimento de dúvidas, validação de correções críticas, orientação técnica em mudanças relevantes, suporte inicial em incidentes relacionados ao escopo.
09
⚠️ Regra absoluta: Em caso de dúvida sobre continuar ou parar, a ação padrão é PARAR e comunicar Rafael imediatamente via WhatsApp: (16) 99711-0308.
01
Dados reais de clientes acessíveis/expostos
Se durante os testes for identificado acesso não autorizado a dados pessoais reais de clientes da MaisLocações (CPF, endereço, contratos, dados de pagamento) → PARAR imediatamente, documentar sem ampliar o acesso, notificar Rafael com print mascarado.
02
Sistema com comportamento inesperado ou instabilidade
Se qualquer ação dos testes causar lentidão perceptível, erros em cascata ou comportamento anômalo no sistema → PARAR, aguardar estabilização, notificar Rafael e acordar retomada.
03
Descoberta de comprometimento pré-existente
Se durante os testes forem encontrados indícios de que o sistema JÁ está comprometido por terceiros (backdoors, malware, acesso não autorizado em progresso) → PARAR, isolar evidência, notificar Rafael com urgência. Não confundir atividade do pentest com a atividade maliciosa.
04
Bloqueio por WAF/IDS com comunicação ao cliente
Se o IP da estação ofensiva for bloqueado pelo Cloudflare ou Azure WAF de forma persistente → PARAR testes ativos, notificar Rafael para whitelist do IP, aguardar liberação formal antes de retomar.
05
Solicitação de parada pelo cliente
Rafael ou contato técnico designado pode solicitar parada a qualquer momento via WhatsApp ou e-mail → ação imediata, sem questionamentos. Retomada somente com autorização formal por escrito.
06
Descoberta de ativo fora do escopo autorizado
Se durante o teste for identificado um ativo relacionado que NÃO está no escopo contratado → documentar a descoberta, NÃO testar, comunicar ao cliente. Explorar ativo não autorizado é crime.
07
Fora da janela de tempo autorizada
Testes de scanning/exploração não devem ocorrer fora do horário Seg-Sex 09h-17h. Reconhecimento passivo pode ocorrer a qualquer momento. Em caso de dúvida, parar e aguardar a janela autorizada.
10
Log de Comunicações — Atualização Contínua
DATA/HORA
TIPO
CONTEÚDO
EMITIDO POR
01/04/2026
CONTRATO
Assinatura do contrato de pentest e ROE — formalização completa
AMBOS
07/04/2026
FORMULÁRIO
ROE preenchido pelo cliente — URLs, IPs, stack, credenciais (parcial), contatos
CLIENTE
PENDENTE
CREDENCIAL
Envio da senha do usuário jeferson@maisloc.com.br via WhatsApp criptografado
CLIENTE
PENDENTE
CREDENCIAL
Criação e envio de credenciais para roles employee e delivery
CLIENTE
INÍCIO
KICKOFF
Comunicação de início oficial dos testes — Fase 1 em andamento
TANDER
IF CRITICAL
ALERTA
Comunicação imediata de finding CRÍTICO — WhatsApp + e-mail Rafael
TANDER
D+10
ENCERRAMENTO
Comunicação de fim dos testes ativos — início da fase de relatório
TANDER
D+15
ENTREGA
Entrega dos relatórios Executivo e Técnico
TANDER
D+22
REUNIÃO
Reunião de apresentação dos resultados — Call com Rafael + time técnico
AMBOS
Protocolo de comunicação de urgência: Qualquer finding CRÍTICO identificado fora do horário comercial deve ser comunicado ao Rafael no celular (16) 99711-0308 disponível 24h, conforme declarado no ROE assinado.
11
Instrução para ZEUS: Use este template para cada finding confirmado. Achados não confirmados vão para a seção de Observações, não aqui.
BD-XXX
[NOME DA VULNERABILIDADE]
CRÍTICO
[9.X]
CVSSv3.1
[Nome técnico exato da vulnerabilidade]
A0X — [Nome da categoria] / API-X — [Nome]
https://[url-do-endpoint-afetado]
GET / POST / PUT / DELETE / PATCH
[nome_do_parametro] no [body / header / URL / cookie]
[Burp Suite / sqlmap / jwt_tool / Manual / etc]
[DD/MM/AAAA HH:MM]
Descrição objetiva e técnica do problema. Como funciona a vulnerabilidade. Qual mecanismo está quebrado. Sem jargão desnecessário, mas com precisão técnica suficiente para o desenvolvedor reproduzir e corrigir.
1. [Passo 1 — ação inicial]
2. [Passo 2 — intercepção/modificação]
3. [Passo 3 — payload utilizado]
4. [Passo 4 — resultado obtido]
[REQUEST COMPLETO — DADOS SENSÍVEIS MASCARADOS]
GET /api/contratos/[ID_SUBSTITUIDO] HTTP/1.1
Host: maislocacoes.azurewebsites.net
Authorization: Bearer [TOKEN_REDACTED]
[RESPONSE — DADOS MASCARADOS]
{"id": "[ID]", "cliente": "[NOME_MASCARADO]", ...}
O que um atacante pode fazer tecnicamente com esta vulnerabilidade. Quais sistemas, dados ou funcionalidades são comprometidos. Qual o alcance máximo da exploração.
O que esta vulnerabilidade significa para a MaisLocações em termos de risco real: financeiro, legal (LGPD), reputacional ou operacional. Escrito para o Rafael entender sem ser técnico.
Como corrigir. Referências a documentação oficial (OWASP, NIST, docs do framework). Código de exemplo quando aplicável. Específico para a stack C#/.NET + PostgreSQL.
IMEDIATO — Corrigir antes de qualquer deploy.
📎 BD-XXX_CRIT_request.txt
📎 BD-XXX_CRIT_response.txt
📎 BD-XXX_CRIT_screenshot-01.png
📎 BD-XXX_CRIT_video.mp4
ABERTO
✓ Sim — após correção pelo time dev, reteste via período de acompanhamento (6 meses)
Regra de mascaramento de dados: Nunca incluir dados reais de clientes (CPF, e-mail, contratos) nas evidências sem mascaramento. Senhas e tokens: [REDACTED] completo. O relatório deve ser legível sem expor PII.