Explore uma API e Infra Vulneráveis

Problema

Uma única linha de código ausente pode expor uma superfície administrativa inteira. É comum construir uma dependency de autorização corretamente (uma função que valida um header `X-Admin-Token` e rejeita a requisição se ele estiver ausente ou errado) e depois simplesmente esquecer de anexá-la a uma ou mais rotas quando elas são registradas no router. A dependency existe, tem teste unitário, e parece correta isoladamente — mas se ela nunca foi conectada ao router para um dado endpoint, esse endpoint não autentica ninguém. Isso é **broken access control** (OWASP API1/API5, "Broken Object/Function Level Authorization"), e é uma das vulnerabilidades de API mais comuns no mundo real precisamente porque é invisível numa revisão de código que só olha para a função da dependency em si. Uma vez que você achou um painel admin sem autenticação, o raio de impacto frequentemente se estende além de "ler alguns dados" — um endpoint que busca uma URL em nome do servidor, pensado só para uso interno, pode virar um primitivo de **Server-Side Request Forgery (SSRF)**: uma forma de fazer o próprio servidor emitir uma requisição a um recurso só-interno que um cliente normal nunca conseguiria alcançar diretamente. Neste lab você vai rodar a **DARE Vulnerable AI Suite** localmente e atacar seu desafio `vulnerable-api-infra`: uma única causa raiz (uma dependency de rota sem autenticação) exposta através de três caminhos separados — um endpoint de sessões, um endpoint de logs que vaza um segredo diretamente, e um endpoint de webhook-preview que vaza o mesmo segredo de novo via SSRF. > Pratique só contra a suíte descartável `dare-vulnerable-ai` rodando > localmente em `127.0.0.1:8000` (vinculada só ao localhost), com logs > e endpoints internos sintéticos. Nunca tente broken access control ou > sondagem de SSRF contra uma API real, um endpoint de metadados de > nuvem, ou qualquer sistema que você não seja dono ou não tenha > autorização explícita por escrito para testar.

Objetivos

Ao final deste lab você será capaz de:

• Explicar broken access control em nível de função e por que "a
  dependency existe" não é a mesma garantia que "a dependency está
  anexada a esta rota".
• Sondar uma API admin sem credenciais para determinar se a
  autenticação está de fato sendo reforçada.
• Reconhecer dados sensíveis (um token secreto) vazando por um canal
  inesperado — logs da aplicação — em vez de um campo de resposta
  típico.
• Explicar SSRF e demonstrá-lo fazendo um servidor buscar uma URL
  só-interna em seu nome.
• Rastrear três endpoints expostos diferentes até uma única causa raiz
  compartilhada, e explicar por que uma correção de uma linha (anexar
  a dependency ausente) fecha os três de uma vez.

Pré-requisitos

Para completar este lab você vai precisar de:

• Docker e Docker Compose instalados.
• Acesso ao repositório privado dare-vulnerable-ai (alunos
  matriculados têm acesso): git@github.com:darelabs-tech/dare-vulnerable-ai.git.
• curl (ou um cliente HTTP equivalente) e um terminal.
• Familiaridade básica com headers HTTP e corpos de requisição JSON;
  nenhuma experiência prévia com segurança de infraestrutura é exigida.

Uma causa raiz, três exposições

require_admin_token()  ← existe, checa corretamente o X-Admin-Token, tem teste unitário

Registro no router:
  /api/admin/panel/sessions              ──▶ dependency NÃO anexada
  /api/admin/panel/logs                  ──▶ dependency NÃO anexada
  /api/admin/panel/integrations/webhook-preview ──▶ dependency NÃO anexada

Nenhuma dessas rotas está sem um conceito de autorização — a
dependency require_admin_token é código real que rejeitaria uma
requisição sem autenticação se de fato estivesse conectada ao router
para esses caminhos. Ela só não foi anexada quando essas três rotas
foram registradas. Esse é o bug inteiro: não uma checagem falha, uma
checagem que nunca foi plugada.

Por que isso é perigoso além de "você consegue ler alguns dados"

• sessions prova o padrão: qualquer um, sem header nenhum, recebe um
  200.
• logs transforma "sem auth" num vazamento direto de segredo — logs
  de aplicação frequentemente contêm mais do que os desenvolvedores
  pretendem (um token logado "só para essa linha de debug" que nunca
  foi removido), e sem controle de acesso, isso vira público.
• webhook-preview transforma "sem auth" em SSRF: ele aceita uma
  url e a busca no lado do servidor para montar um preview. O
  endpoint interno que ele consegue alcançar, /internal/ops-metadata,
  é desenhado para aceitar só requisições que se originam do próprio
  host — um curl externo direto a ele recebe 403. Mas o endpoint
  webhook-preview roda dentro do servidor, então quando ele busca
  essa mesma URL em nome do servidor, a requisição parece ter vindo do
  host, e funciona. O controle de acesso que protege corretamente o
  /internal/ops-metadata do mundo externo não faz nada contra uma
  requisição forjada de dentro.

Como você vai trabalhar neste lab

1. Desbloqueie o desafio.
2. Acesse /sessions sem headers nenhum e prove que nada é
   reforçado.
3. Acesse /logs sem headers nenhum e ache a flag vazando
   diretamente.
4. Confirme que /internal/ops-metadata recusa uma chamada externa
   direta (403), depois alcance-o mesmo assim via webhook-preview
   (SSRF) e pegue a mesma flag por um segundo caminho.
5. Leia a solução oficial e explique por que isso é uma causa raiz,
   não três bugs separados.