IDOR Vulnerability Testing

IDOR Vulnerability Testing

Purpose

Fornecer metodologias sistemáticas para identificar e explorar vulnerabilidades de Insecure Direct Object Reference (IDOR) em aplicações web. Esta skill abrange referências a objetos de banco de dados e referências a arquivos estáticos, técnicas de detecção usando manipulação de parâmetros e enumeração, exploração via Burp Suite e estratégias de remediação para proteger aplicações contra acesso não autorizado.

Inputs / Prerequisites

• Target Web Application: URL da aplicação com recursos específicos do usuário
• Multiple User Accounts: No mínimo duas contas de teste para verificar acesso entre usuários
• Burp Suite or Proxy Tool: Proxy interceptador para manipulação de requisições
• Authorization: Permissão escrita para teste de segurança
• Understanding of Application Flow: Conhecimento de como objetos são referenciados (IDs, nomes de arquivo)

Outputs / Deliverables

• IDOR Vulnerability Report: Documentação de bypasses de controle de acesso descobertos
• Proof of Concept: Evidência de acesso não autorizado a dados em contextos de usuário diferentes
• Affected Endpoints: Lista de endpoints de API vulneráveis e parâmetros afetados
• Impact Assessment: Classificação da severidade de exposição de dados
• Remediation Recommendations: Correções específicas para vulnerabilidades identificadas

Core Workflow

1. Understand IDOR Vulnerability Types

Direct Reference to Database Objects

Ocorre quando aplicações referenciam registros de banco de dados via parâmetros controláveis pelo usuário:

# Original URL (autenticado como Usuário A)
example.com/user/profile?id=2023

# Tentativa de manipulação (acessando dados do Usuário B)
example.com/user/profile?id=2022

Direct Reference to Static Files

Ocorre quando aplicações expõem caminhos ou nomes de arquivo que podem ser enumerados:

# Original URL (recibo do Usuário A)
example.com/static/receipt/205.pdf

# Tentativa de manipulação (recibo do Usuário B)
example.com/static/receipt/200.pdf

2. Reconnaissance and Setup

Create Multiple Test Accounts

Account 1: "attacker" - Conta de teste principal
Account 2: "victim" - Conta cujos dados tentamos acessar

Identify Object References

Capturar e analisar requisições contendo:

• IDs numéricos em URLs: /api/user/123
• IDs numéricos em parâmetros: ?id=123&action=view
• IDs numéricos no corpo da requisição: {"userId": 123}
• Caminhos de arquivo: /download/receipt_123.pdf
• GUIDs/UUIDs: /profile/a1b2c3d4-e5f6-...

Map User IDs

# Acessar endpoint de ID do usuário (se disponível)
GET /api/user-id/

# Notar padrões de ID:
# - Números sequenciais (1, 2, 3...)
# - Valores auto-incrementados
# - Padrões previsíveis

3. Detection Techniques

URL Parameter Manipulation

# Passo 1: Capturar requisição autenticada original
GET /api/user/profile?id=1001 HTTP/1.1
Cookie: session=attacker_session

# Passo 2: Modificar ID para alvo de outro usuário
GET /api/user/profile?id=1000 HTTP/1.1
Cookie: session=attacker_session

# Vulnerável se: Retorna dados da vítima com sessão do atacante

Request Body Manipulation

# Requisição POST original
POST /api/address/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{"id": 5, "userId": 1001, "address": "123 Attacker St"}

# Requisição modificada atacando a vítima
{"id": 5, "userId": 1000, "address": "123 Attacker St"}

HTTP Method Switching

# Requisição GET original pode estar protegida
GET /api/admin/users/1000 → 403 Forbidden

# Tentar métodos alternativos
POST /api/admin/users/1000 → 200 OK (Vulnerável!)
PUT /api/admin/users/1000 → 200 OK (Vulnerável!)

4. Exploitation with Burp Suite

Manual Exploitation

1. Configurar proxy do navegador através do Burp Suite
2. Fazer login como usuário "attacker"
3. Navegar para página de perfil/dados
4. Ativar Intercept na aba Proxy
5. Capturar requisição com ID do usuário
6. Modificar ID para ID da vítima
7. Encaminhar requisição
8. Observar resposta para dados da vítima

Automated Enumeration with Intruder

1. Enviar requisição para Intruder (Ctrl+I)
2. Limpar todas as posições de payload
3. Selecionar parâmetro ID como posição de payload
4. Configurar tipo de ataque: Sniper
5. Configurações de payload:
   - Tipo: Numbers
   - Intervalo: 1 a 10000
   - Passo: 1
6. Iniciar ataque
7. Analisar respostas para códigos de status 200

Battering Ram Attack for Multiple Positions

# Quando mesmo ID aparece em múltiplos locais
PUT /api/addresses/§5§/update HTTP/1.1

{"id": §5§, "userId": 3}

Attack Type: Battering Ram
Payload: Numbers 1-1000

5. Common IDOR Locations

API Endpoints

/api/user/{id}
/api/profile/{id}
/api/order/{id}
/api/invoice/{id}
/api/document/{id}
/api/message/{id}
/api/address/{id}/update
/api/address/{id}/delete

File Downloads

/download/invoice_{id}.pdf
/static/receipts/{id}.pdf
/uploads/documents/{filename}
/files/reports/report_{date}_{id}.xlsx

Query Parameters

?userId=123
?orderId=456
?documentId=789
?file=report_123.pdf
?account=user@email.com

Quick Reference

IDOR Testing Checklist

Response Analysis

Common Vulnerable Parameters

Constraints and Limitations

Operational Boundaries

• Requer no mínimo duas contas de usuário válidas para verificação
• Algumas aplicações usam tokens vinculados a sessão em vez de IDs
• Referências GUID/UUID mais difíceis de enumerar, mas não impossível
• Rate limiting pode restringir tentativas de enumeração
• Alguns IDOR requerem vulnerabilidades em cadeia para explorar

Detection Challenges

• Escalação de privilégio horizontal (usuário-para-usuário) vs vertical (usuário-para-admin)
• IDOR cego onde resposta não confirma acesso
• IDOR baseado em tempo em operações assincronamente
• IDOR em comunicações WebSocket

Legal Requirements

• Testar apenas aplicações com autorização explícita
• Documentar todas as atividades e descobertas de teste
• Não acessar, modificar ou exfiltrar dados reais de usuários
• Relatar descobertas através dos canais apropriados de divulgação

Examples

Example 1: Basic ID Parameter IDOR

# Login como atacante (userId=1001)
# Navegar para página de perfil

# Requisição original
GET /api/profile?id=1001 HTTP/1.1
Cookie: session=abc123

# Resposta: Dados de perfil do atacante

# Requisição modificada (alvo userId da vítima=1000)
GET /api/profile?id=1000 HTTP/1.1
Cookie: session=abc123

# Resposta Vulnerável: Dados de perfil da vítima retornados!

Example 2: IDOR in Address Update Endpoint

# Interceptar requisição de atualização de endereço
PUT /api/addresses/5/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{
  "id": 5,
  "userId": 1001,
  "street": "123 Main St",
  "city": "Test City"
}

# Modificar userId para ID da vítima
{
  "id": 5,
  "userId": 1000,  # Alterado de 1001
  "street": "Hacked Address",
  "city": "Exploit City"
}

# Se 200 OK: Endereço criado sob conta da vítima

Example 3: Static File IDOR

# Baixar próprio recibo
GET /api/download/5 HTTP/1.1
Cookie: session=attacker_session

# Resposta: PDF do recibo do atacante (pedido #5)

# Tentar acessar outros recibos
GET /api/download/3 HTTP/1.1
Cookie: session=attacker_session

# Resposta Vulnerável: PDF do recibo da vítima (pedido #3)!

Example 4: Burp Intruder Enumeration

# Configurar ataque Intruder
Target: PUT /api/addresses/§1§/update
Payload Position: Address ID na URL e corpo

Attack Configuration:
- Type: Battering Ram
- Payload: Numbers 0-20, Step 1

Body Template:
{
  "id": §1§,
  "userId": 3
}

# Analisar resultados:
# - Respostas 200 indicam modificação bem-sucedida
# - Verificar conta da vítima para novos endereços

Example 5: Horizontal to Vertical Escalation

# Passo 1: Enumerar funções de usuário
GET /api/user/1 → {"role": "user", "id": 1}
GET /api/user/2 → {"role": "user", "id": 2}
GET /api/user/3 → {"role": "admin", "id": 3}

# Passo 2: Acessar funções de admin com ID descoberto
GET /api/admin/dashboard?userId=3 HTTP/1.1
Cookie: session=regular_user_session

# Se acessível: Escalação de privilégio vertical alcançada

Troubleshooting

Issue: All Requests Return 403 Forbidden

Cause: Controle de acesso servidor está implementado Solution:

# Tentar vetores de ataque alternativos:
1. Alternância de método HTTP (GET → POST → PUT)
2. Adicionar headers X-Original-URL ou X-Rewrite-URL
3. Tentar poluição de parâmetro: ?id=1001&id=1000
4. Variações de codificação de URL: %31%30%30%30 para "1000"
5. Variações de maiúscula/minúscula para IDs em string

Issue: Application Uses UUIDs Instead of Sequential IDs

Cause: Identificadores aleatorizados reduzem risco de enumeração Solution:

# Técnicas de descoberta de UUID:
1. Verificar corpos de resposta para UUIDs vazados
2. Procurar em arquivos JavaScript por UUIDs hardcoded
3. Verificar respostas de API que listam múltiplos objetos
4. Procurar por padrões UUID em mensagens de erro
5. Tentar predição UUID v1 (baseado em tempo) se aplicável

Issue: Session Token Bound to User

Cause: Aplicação valida sessão contra recurso solicitado Solution:

# Tentativas de bypass avançado:
1. Testar IDOR em endpoints não autenticados
2. Verificar fluxos de reset de senha/verificação de email
3. Procurar IDOR em upload/download de arquivo
4. Testar versionamento de API: /api/v1/ vs /api/v2/
5. Verificar endpoints de API móvel (frequentemente menos protegidos)

Issue: Rate Limiting Blocks Enumeration

Cause: Aplicação implementa throttling de requisição Solution:

# Técnicas de bypass:
1. Adicionar delays entre requisições (Burp Intruder throttle)
2. Girar endereços IP (cadeias de proxy)
3. Alvo de IDs específicos de alto valor em vez de intervalo completo
4. Usar diferentes endpoints para mesmos recursos
5. Testar durante horas de pouco movimento

Issue: Cannot Verify IDOR Impact

Cause: Resposta não indica claramente propriedade dos dados Solution:

# Métodos de verificação:
1. Criar dados identificáveis únicos em conta da vítima
2. Procurar marcadores de PII (nome, email) em respostas
3. Comparar tamanhos de resposta entre usuários
4. Verificar diferenças de tempo em respostas
5. Usar indicadores secundários (datas de criação, metadados)

Remediation Guidance

Implement Proper Access Control

# Exemplo Django - validar propriedade
def update_address(request, address_id):
    address = Address.objects.get(id=address_id)
    
    # Verificar propriedade antes de permitir atualização
    if address.user != request.user:
        return HttpResponseForbidden("Unauthorized")
    
    # Prosseguir com atualização
    address.update(request.data)

Use Indirect References

# Em vez de: /api/address/123
# Usar: /api/address/current-user/billing

def get_address(request):
    # Sempre filtrar por usuário autenticado
    address = Address.objects.filter(user=request.user).first()
    return address

Server-Side Validation

# Sempre validar no servidor, nunca confiar em entrada do cliente
def download_receipt(request, receipt_id):
    receipt = Receipt.objects.filter(
        id=receipt_id,
        user=request.user  # Crítico: filtrar por usuário atual
    ).first()
    
    if not receipt:
        return HttpResponseNotFound()
    
    return FileResponse(receipt.file)