O que é IDOR e como ele expõe dados de outros usuários

IDOR (Insecure Direct Object Reference) é uma vulnerabilidade de segurança web que ocorre quando uma aplicação fornece acesso direto a objetos internos (como arquivos, registros de banco de dados ou contas de usuários) com base em entradas fornecidas pelo usuário, sem realizar a validação adequada de autorização. Na prática, isso significa que um invasor pode simplesmente alterar um parâmetro em uma URL ou requisição de API, mudando, por exemplo, de user_id=10 para user_id=11, e conseguir visualizar, modificar ou excluir dados confidenciais de outra pessoa sem precisar de senhas adicionais.

Principais Aprendizados

• O IDOR é uma falha de autorização (Broken Access Control), não de autenticação, pois o usuário já está logado, mas acessa recursos que não lhe pertencem.
• A manipulação de parâmetros em URLs e APIs é o vetor de ataque mais comum para explorar essa vulnerabilidade.
• A substituição de IDs sequenciais por UUIDs (Identificadores Únicos Universais) e a validação rigorosa de sessão são as melhores defesas contra o IDOR.

Entendendo o conceito: O que significa IDOR?

A sigla IDOR significa Referência Direta Insegura a Objetos. Historicamente, ela ganhou destaque em edições anteriores de relatórios de segurança globais, mas hoje é amplamente categorizada sob o guarda-chuva de Falhas de Controle de Acesso (Broken Access Control). De acordo com a documentação oficial da Fundação OWASP, o controle de acesso quebrado subiu para a primeira posição das falhas mais críticas da web, e o IDOR é um dos principais responsáveis por essa estatística alarmante.

O grande problema do IDOR é que ele passa despercebido por firewalls de aplicação (WAFs) e ferramentas automatizadas de segurança. Como a requisição HTTP parece perfeitamente legítima e o usuário possui um token válido de login, o servidor confia cegamente que o cliente tem permissão para acessar o objeto solicitado. A falha reside exclusivamente na lógica de negócios da aplicação.

Como um ataque IDOR acontece na prática?

Exemplo clássico em URLs

Imagine um sistema bancário ou um portal de e-commerce onde o usuário faz login e é redirecionado para a página do seu perfil ou fatura. A URL no navegador pode se parecer com isso: https://www.site.com/fatura?id=1050. Um usuário mal-intencionado, ao notar esse padrão numérico sequencial, pode alterar manualmente a URL para https://www.site.com/fatura?id=1051. Se o sistema não verificar se o usuário logado é o verdadeiro dono da fatura 1051, o servidor retornará os dados privados do outro cliente. Isso é o IDOR em sua forma mais pura.

O perigo silencioso nas APIs Restful

Com a modernização das aplicações web, grande parte do tráfego passou a ser gerenciado por APIs. O princípio é o mesmo, mas ocorre nos bastidores (em requisições JSON ou XML). Durante um pentest de API, é extremamente comum encontrar endpoints como /api/v1/users/44/profile. Se o aplicativo móvel ou frontend web não valida a relação entre o token de autenticação e o ID do recurso, qualquer invasor pode extrair o banco de dados inteiro apenas incrementando os números através de um script automatizado.

Qual o impacto do IDOR para a segurança das empresas?

O impacto de uma vulnerabilidade IDOR bem-sucedida é catastrófico, resultando quase sempre em vazamento massivo de dados (Data Breach). Informações de Identificação Pessoal (PII), dados financeiros, históricos médicos e documentos confidenciais podem ser expostos. O instituto MITRE classifica essa falha sob a CWE-639, alertando que a ausência de verificações de autorização pode levar ao comprometimento total da confidencialidade do sistema.

Além dos danos à reputação e das pesadas multas impostas por leis de privacidade como a LGPD e a GDPR, o IDOR é o vetor inicial para ataques mais complexos. Por isso, compreender o OWASP Top 10 é um requisito obrigatório para qualquer equipe de desenvolvimento de software moderna.

Como identificar e prevenir falhas de IDOR

Mapeamento e testes de invasão

A identificação do IDOR exige testes manuais aprofundados. Diferente de um SQL Injection que pode ser detectado por scanners, o IDOR requer que o testador entenda o contexto da aplicação. A fase de enumeração é crucial aqui: o profissional de segurança criará duas contas distintas (Conta A e Conta B) e tentará acessar os recursos da Conta B usando os cookies de sessão da Conta A. Se funcionar, a vulnerabilidade está confirmada.

Melhores práticas para desenvolvedores

• Validação de Autorização: Nunca confie nos parâmetros enviados pelo cliente. O servidor deve sempre verificar se o usuário associado ao token de sessão atual tem privilégios explícitos para acessar o ID solicitado.
• Uso de UUIDs ou GUIDs: Evite IDs numéricos e sequenciais (ex: 1, 2, 3) no banco de dados. Utilize Identificadores Únicos Universais (ex: f47ac10b-58cc-4372-a567-0e02b2c3d479). Embora isso não corrija a falha de autorização em si, torna a adivinhação de outros IDs matematicamente impossível para o invasor.
• Controle de Acesso Baseado em Papéis (RBAC): Implemente matrizes de acesso centralizadas no backend para garantir que apenas administradores possam acessar recursos globais.

Perguntas Frequentes

1. IDOR e Broken Access Control são a mesma coisa?

O IDOR é um tipo específico de Broken Access Control (Controle de Acesso Quebrado). Enquanto o Broken Access Control é uma categoria ampla que abrange qualquer falha onde os usuários agem fora de suas permissões, o IDOR refere-se especificamente à manipulação direta de referências de objetos, como IDs em URLs ou parâmetros de API.

2. Apenas usar UUIDs em vez de números resolve o IDOR?

Não. O uso de UUIDs (Identificadores Únicos Universais) atua como uma camada de ofuscação, impedindo que invasores adivinhem o ID de outros usuários. No entanto, se um invasor descobrir o UUID de outra pessoa (por exemplo, através de um vazamento em outro endpoint), ele ainda conseguirá acessar os dados se não houver uma verificação de autorização no servidor. A verdadeira correção é a validação de permissões no backend.

3. Ferramentas automatizadas conseguem encontrar falhas de IDOR?

Na maioria das vezes, não. Scanners de vulnerabilidade automatizados têm dificuldade em encontrar IDOR porque a falha não gera erros de sintaxe (como no SQLi) e exige compreensão do contexto de negócios. O scanner não sabe quais dados pertencem ao Usuário A e quais pertencem ao Usuário B. Por isso, testes manuais e revisões de código são indispensáveis.