Laboratório de Segurança: do achado ao plano de tratamento

Introdução

Este laboratório consolida a trilha em um sistema inteiramente fictício. Não existem credenciais, dados pessoais, endereços ou ambientes reais. Os exemplos mostram o mínimo necessário para compreender a falha e concentram o trabalho em correção, teste e prevenção.

O objetivo não é explorar um sistema. É transformar observações técnicas em decisões verificáveis: o que está em risco, como reduzir a exposição, como perceber uma tentativa, como responder e qual risco permanecerá.

O sistema fictício

O Portal Farol organiza perfis e reservas de salas de estudo. Usuários comuns atualizam o próprio nome e consultam reservas. Operadores podem suspender contas após um fluxo aprovado. Um serviço interno produz relatórios agregados.

Dados utilizados no laboratório são sintéticos:

• Identificador fictício de usuário.
• Nome de exibição inventado.
• Papel member ou operator.
• Reserva sem dados de pessoas reais.
• Evento de auditoria sem segredo ou token.

O ambiente possui cliente web, API pública, serviço de domínio, banco de dados e pipeline de logs para um Security Information and Event Management (SIEM).

Os dois diagramas representam, em conjunto, Cliente → API → Serviço → Banco de dados, com API e serviço enviando eventos a Logs/SIEM.

Trust boundaries e pontos de controle

A primeira trust boundary fica entre cliente e API. Todo campo recebido é não confiável, mesmo quando a interface oficial não o exibe.

A segunda fica entre API e serviço. A API propaga identidade autenticada, mas o serviço continua responsável por autorizar a ação de negócio.

A terceira separa serviço e banco. A identidade técnica recebe apenas as operações necessárias, e consultas usam parâmetros e contratos controlados.

O pipeline de logs cruza outra fronteira. Ele recebe somente eventos estruturados e redigidos, com acesso limitado e retenção definida.

Roteiro do laboratório

Inventário de ativos

Ativos não são apenas tabelas. No Portal Farol, a função administrativa, a integridade dos papéis, a disponibilidade das reservas, o pipeline de entrega e a capacidade de investigar eventos também possuem valor.

Registro dos achados

O mapeamento abaixo usa o OWASP Top 10:2021. CWE aparece apenas quando a fraqueza é suficientemente clara; uma categoria não substitui a descrição da causa.

Achado 1: mass assignment

O handler frágil copia todas as propriedades recebidas. A interface não mostra role, mas isso não é uma fronteira de segurança.

// Frágil: o cliente escolhe quais atributos chegam à entidade.
await users.update(request.user.id, request.body);

A correção cria um contrato explícito. Mudança de papel pertence a outro caso de uso, com autorização e auditoria próprias.

const input = {
  displayName: String(request.body.displayName),
};
 
await users.updateProfile(request.user.id, input);

O teste envia uma propriedade não prevista e espera rejeição ou descarte seguro conforme o contrato. Depois, lê o usuário e confirma que o papel permaneceu inalterado.

Achados 2, 3 e 6: autenticação não é autorização

O endpoint /admin/users/{id}/suspend valida a sessão, mas não a permissão. O defeito se repete porque a arquitetura trata identidade autenticada como autorização global.

Prepared statements protegem a estrutura da consulta usada pelo endpoint. Eles não verificam se a pessoa pode suspender aquela conta.

if (!authorization.can(request.user, "user:suspend", request.params.id)) {
  return response.status(403).json({ code: "FORBIDDEN" });
}
 
await users.suspendById(request.params.id);

O aceite inclui testes de usuário comum, operador, recurso fora do escopo e identidade sem sessão. A aplicação precisa diferenciar autenticação, autorização funcional e autorização sobre o recurso.

Achados 4 e 5: transporte e Basic Auth

Basic Auth codifica usuário e senha em Base64. O desenho só pode utilizá-lo em contexto apropriado e sobre HTTPS; Base64 não é criptografia.

O Portal Farol aceita requisições HTTP e faz redirecionamento sem HSTS. O plano exige HTTPS em toda a aplicação, redirecionamento seguro quando necessário, HSTS após validação da cobertura e eliminação de conteúdo misto.

Critérios de aceite incluem certificado válido, ausência de endpoint funcional apenas em HTTP, cabeçalho HSTS com política aprovada e teste de que credenciais nunca aparecem em URL ou logs.

Achado 7: SQL Injection em outro fluxo

O endpoint administrativo utiliza prepared statements, mas um relatório separado concatena o campo de ordenação. Não é necessário criar um payload ofensivo para demonstrar a causa: o dado controla a estrutura da consulta.

Campos estruturais não usam parâmetro da mesma forma que valores. O código mapeia opções públicas para identificadores conhecidos.

const allowedSort = {
  createdAt: "created_at",
  room: "room_name",
} as const;
 
const sortColumn = allowedSort[request.query.sort as keyof typeof allowedSort] ?? "created_at";
const result = await database.query(`SELECT id, room_name FROM bookings ORDER BY ${sortColumn}`);

A allowlist é pequena e controlada pelo servidor. Valores de filtro continuam parametrizados. Revisão e testes verificam opções aceitas e rejeitam qualquer estrutura fora do contrato.

Achados 8 e 9: RSA-256 e DES

RSA-256 não descreve uma configuração suficiente. Se indicar chave RSA de 256 bits, é inadequada; se a intenção for combinação com SHA-256, ainda faltam esquema, padding, tamanho de chave, finalidade e política de rotação.

DES também não deve proteger dados atuais. O tratamento começa com inventário de dados, chaves, integrações e compatibilidade; seleciona algoritmo e biblioteca aprovados; migra registros; rotaciona chaves; e verifica que dados antigos não permanecem dependentes do mecanismo legado.

O aceite não é “a configuração mudou”. Evidências incluem teste de interoperabilidade, inventário sem uso residual, rotação executada, acesso às chaves auditado e plano de reversão testado.

Achado 10: logging insuficiente

Suspensão de conta e mudança de papel precisam produzir evento estruturado. O evento registra ator, ação, alvo, resultado, correlação e horário. Senhas, tokens e dados pessoais desnecessários não entram no log.

O SIEM correlaciona tentativas de alteração de role, recusas em endpoint administrativo e uma operação privilegiada bem-sucedida. A regra possui responsável, severidade, playbook e teste controlado.

Detecção sem resposta apenas acumula alertas. O playbook orienta validar a identidade, conter sessão quando necessário, preservar evidências, revisar alterações e comunicar responsáveis.

Achado 11: dependência vulnerável

O laboratório assume uma dependência com vulnerabilidade conhecida e aplicável, sem inventar um identificador CVE. O time confirma versão, alcance do código, exposição e orientação do mantenedor.

O tratamento pode ser atualizar, substituir, desabilitar a funcionalidade afetada ou aplicar mitigação temporária. A decisão registra prazo, proprietário, teste de regressão e risco residual.

Uma Software Bill of Materials (SBOM) atualizada ajuda a localizar onde o componente está implantado. Software Composition Analysis (SCA) alerta sobre informações conhecidas, mas o analista confirma aplicabilidade e prioridade.

Cadeia de ataque e attack tree

A cadeia torna explícita a progressão:

Ativo: função administrativa
→ Ameaça: usuário tenta ampliar privilégios
→ Vulnerabilidade: role aceito e autorização ausente
→ Incidente: conta comum executa suspensão
→ Impacto: indisponibilidade para usuários e perda de integridade

A attack tree mostra caminhos alternativos para o mesmo objetivo.

Objetivo: executar função administrativa
├── Enviar role por mass assignment
├── Chamar endpoint autenticado sem autorização
└── Obter credencial em transporte inseguro
    ├── Usar HTTP
    └── Ausência de política HSTS após acesso seguro

O controle mais valioso pode cortar vários ramos. Autorização por ação e recurso bloqueia a função mesmo se outro dado estiver incorreto; HTTPS reduz exposição de credencial; allowlist de propriedades impede a elevação pelo perfil.

Classificação e plano de tratamento

Os níveis deste exercício pertencem ao Portal Farol. “Alto” e “médio” não são valores universais.

Prevenção, detecção, resposta e recuperação

Critérios de aceite

Um critério precisa ser observável. “Corrigir autorização” é uma intenção; “usuário member recebe 403 e nenhuma alteração ocorre” é verificável.

Priorização e risco residual

F-02 recebe prioridade imediata porque uma identidade comum alcança função administrativa. F-01 e F-06 compartilham a mesma fronteira de controle e podem entrar no mesmo esforço de autorização, sem esconder critérios separados.

F-05, F-08 e F-09 exigem plano de migração para evitar indisponibilidade ou perda de compatibilidade. Controles temporários não encerram o achado; eles reduzem exposição até a solução definitiva.

O risco residual de uma correção de autorização pode incluir contas de operador comprometidas. Por isso permanecem autenticação forte, revisão de acesso, eventos, alertas e resposta.

Cada risco residual registra proprietário, justificativa, controles ativos, prazo de revisão e gatilhos para reavaliação, como nova exposição, incidente ou mudança de arquitetura.

Referências

• OWASP Top 10:2021 — categorias de riscos de aplicações web.
• MITRE CWE-915 — Improperly Controlled Modification of Object Attributes — fraqueza associada a mass assignment.
• MITRE CWE-862 — Missing Authorization — ausência de verificação de autorização.
• MITRE CWE-89 — SQL Injection — fraqueza de neutralização em comandos SQL.
• MITRE CWE-327 — Broken or Risky Cryptographic Algorithm — uso de algoritmo criptográfico arriscado.
• RFC 7617 — The Basic HTTP Authentication Scheme — Basic Auth e Base64.
• OWASP Threat Modeling Project — processo e recursos para modelagem de ameaças.

Conclusão

Um achado técnico só se torna tratável quando está ligado a ativo, ameaça, impacto e contexto. Classificações OWASP e CWE ajudam a comunicar, mas não substituem a descrição da causa nem a evidência de correção.

O Portal Farol mostrou que mass assignment, autorização, transporte, criptografia, consultas, logging e dependências formam caminhos conectados. O tratamento precisa combinar prevenção, detecção, resposta, recuperação e risco residual explícito.