Referências diretas a objetos inseguras, comumente chamadas de IDORs, continuam sendo uma das classes mais comuns e prejudiciais de vulnerabilidades de aplicativos. Apesar de serem bem documentadas e amplamente compreendidas em nível conceitual, elas continuam a aparecer em sistemas de produção reais, particularmente em aplicativos modernos orientados por API.
Uma vulnerabilidade IDOR ocorre quando uma aplicação utiliza um identificador fornecido pelo utilizador para aceder a um objeto interno sem verificar se o utilizador atual está autorizado a aceder a esse objeto específico. Esta questão insere-se na categoria mais ampla de controle de acesso quebrado, mas é distinta na forma como se manifesta e na razão pela qual é difícil eliminá-la completamente.
Os IDORs persistem não porque as equipas não têm conhecimento deles, mas porque surgem da forma como os sistemas reais evoluem. Frequentemente, são introduzidos nas extremidades dos fluxos de trabalho, durante refatorações ou quando as suposições de propriedade são reutilizadas em etapas que não foram originalmente concebidas para estarem conectadas. Este artigo explica como os IDORs se apresentam na prática, por que as abordagens comuns de testes de segurança têm dificuldade em detetá-los de forma confiável e como as técnicas modernas de testes validam falhas de propriedade em sistemas em execução.
O que é uma referência direta a objeto insegura na prática
Uma vulnerabilidade IDOR ocorre quando uma aplicação aceita um identificador que faz referência a um objeto interno, como um registo, documento ou conta, e o utiliza diretamente sem aplicar de forma consistente a autorização para esse objeto.
Os identificadores geralmente aparecem como:
- IDs de utilizador em caminhos de URL
- IDs de encomenda ou fatura nos parâmetros de consulta
- Identificadores de recursos nos corpos das solicitações
A vulnerabilidade não é o identificador em si. A vulnerabilidade é a suposição de que o identificador pertence ao utilizador autenticado, sem revalidar essa suposição no servidor.
Em aplicações modernas, essa suposição geralmente se aplica na maioria dos casos, mas não em todos. Essa inconsistência é onde os IDORs existem.
Por que as vulnerabilidades IDOR são especialmente perigosas nas APIs
segurança de API , os IDORs são frequentemente referidos como Broken Object Level Authorization (BOLA), o principal risco no segurança de API 10 segurança de API da OWASP. A OWASP mudou para o termo BOLA para se adequar ao design moderno de API.
As APIs expõem as funcionalidades e os dados essenciais da aplicação. Quando existe uma IDOR numa API, os atacantes podem frequentemente explorá-la em grande escala.
Os impactos comuns incluem:
- Acessar dados confidenciais pertencentes a outros utilizadores
- Modificar ou eliminar recursos pertencentes a outras pessoas
- Ignorando regras de negócios vinculadas à propriedade ou função
- Prejudicar fluxos de trabalho, como aprovações, faturamento ou gestão de contas
Como as APIs são projetadas para automação, uma única verificação de propriedade ausente pode comprometer grandes partes de um sistema.
Tipos comuns de vulnerabilidades IDOR
IDOR é um termo genérico. Na prática, as equipas deparam-se com vários padrões recorrentes:
- IDOR horizontal: um utilizador acede aos objetos de outro utilizador com o mesmo nível de privilégios
- IDOR vertical: os identificadores permitem o acesso a objetos privilegiados ou administrativos
- Blind IDOR: A resposta não expõe dados, mas a ação é bem-sucedida no objeto de outra pessoa.
Os IDORs cegos são especialmente fáceis de passar despercebidos com ferramentas que se concentram na exposição óbvia de dados. Eles geralmente exigem validação explícita para confirmar o impacto.
Como as vulnerabilidades IDOR são tradicionalmente testadas na prática
Durante um teste de penetração, o teste IDOR é normalmente realizado através da reprodução cuidadosa e comparação de pedidos.
Na prática, isso envolve:
- Autenticação como utilizador legítimo
- Executar fluxos de trabalho através da interface do utilizador
- Captura de pedidos enviados pelo navegador ou cliente
- Reproduzir essas solicitações com um utilizador autenticado diferente
- Comparar respostas para ver se há mudanças de comportamento
Por exemplo, se uma solicitação que deveria retornar apenas dados para o Utilizador A retorna os mesmos dados quando reproduzida como Utilizador B, isso indica controle de acesso quebrado.
Esta abordagem é eficaz e amplamente utilizada. Baseia-se na compreensão do testador sobre a intenção da aplicação e na sua capacidade de raciocinar sobre quais as solicitações que são sensíveis em termos de segurança.
No entanto, também é inerentemente manual e demorado. Cada fluxo de trabalho, função ou transição de estado adicional multiplica o número de solicitações que precisam ser capturadas, reproduzidas e interpretadas. À medida que as aplicações se tornam mais complexas, torna-se impraticável aplicar essa comparação exaustivamente em todos os caminhos possíveis.
É por isso que os testes manuais frequentemente encontram IDORs em áreas que recebem muita atenção, mas não podem garantir uma cobertura abrangente.
Por que DAST não detectam vulnerabilidades IDOR reais
Testes Dinâmicos de Segurança de Aplicações (ou Testes de Segurança em Tempo de Execução) operam ao nível do pedido. Elas rastreiam pontos finais, fazem fuzz inputs e procuram respostas anómalas. O que elas não compreendem é a intenção. Um scanner não sabe se uma determinada fatura pertence ao Utilizador A ou ao Utilizador B. Ele não raciocina sobre propriedade, contexto de fluxo de trabalho ou se uma resposta é apropriada para a identidade autenticada. Desde que a aplicação responda de forma limpa, muitas vezes com um 200 OK, um scanner pode tratar a interação como bem-sucedida, mesmo quando dados confidenciais são expostos ao utilizador errado.
Isso torna DAST para problemas superficiais, mas fundamentalmente limitado quando se trata de IDORs e outras falhas de autorização que dependem da propriedade do objeto e do contexto. Essa limitação não é específica de nenhuma ferramenta. Ela reflete o facto de que a verificação no nível da solicitação, mesmo quando bem implementada, não tem contexto suficiente para raciocinar sobre a propriedade do objeto e a intenção do fluxo de trabalho.
Por que a análise estática cria ruído em torno dos IDORs
Muitas equipas dependem de ferramentas de análise estática para sinalizar potenciais problemas de IDOR. Essas ferramentas normalmente procuram padrões em que identificadores são passados para manipuladores ou controladores sem verificações de autorização óbvias nas proximidades.
Isso muitas vezes produz um grande número de descobertas.
Na prática, a maioria destes são falsos positivos. As verificações de autorização frequentemente existem em outros locais da cadeia de chamadas, em middleware partilhado ou em nível de estrutura. A análise estática não pode determinar com segurança se um identificador é explorável em tempo de execução.
Este problema é amplificado quando a autorização é implementada implicitamente ou distribuída por camadas, incluindo:
- Controlo de acesso aplicado por middleware ou decoradores
- Verificações implementadas em serviços partilhados ou métodos modelo
- Lógica de permissão distribuída por vários ficheiros e caminhos de chamada
Nesses casos, as ferramentas estáticas veem um identificador e um caminho de acesso aos dados, mas perdem o contexto completo da autorização. O resultado é um grande volume de descobertas plausíveis, mas com baixo nível de confiança.
Esta é uma limitação fundamental da análise estática. Sem o estado de tempo de execução e o contexto de identidade, nenhuma análise ao nível do código pode determinar de forma fiável se uma referência de objeto é explorável na prática.
Mesmo as ferramentas de análise estática assistidas por IA continuam sendo preditivas. Elas raciocinam sobre a estrutura do código, mas não podem confirmar o comportamento em tempo de execução. Como resultado, descobertas semelhantes ao IDOR geralmente apresentam taxas de falsos positivos superiores a cinquenta por cento, forçando as equipas a triar problemas teóricos, enquanto falhas reais de propriedade correm o risco de serem ocultadas.
O problema central: a propriedade é contextual
Os IDORs não são simplesmente verificações em falta. São falhas de autorização contextual ligadas à propriedade do objeto.
A propriedade é estabelecida através de uma combinação de:
- Estado de autenticação
- Modelos de funções e permissões
- Progressão do fluxo de trabalho
- Estado do lado do servidor criado anteriormente num processo
Se qualquer parte desse contexto for assumida em vez de revalidada, pode surgir um IDOR.
Alguns IDORs são de segunda ordem. Um identificador é aceite numa etapa, armazenado e só utilizado posteriormente, quando o controlo de acesso já não é verificado. Estas questões são particularmente difíceis de detetar, porque a exploração está separada no tempo e nas etapas.
Testar IDORs de forma fiável requer fazer repetidamente uma pergunta simples: o que acontece se este identificador pertencer a outra pessoa?
Os UUIDs não impedem vulnerabilidades IDOR
É um equívoco comum pensar que mudar de identificadores sequenciais para UUIDs elimina o risco de IDOR.
Identificadores imprevisíveis reduzem ataques de força bruta. Eles não impedem o acesso não autorizado se não houver verificações de propriedade.
Em sistemas reais, os invasores obtêm identificadores através do comportamento normal da aplicação, incluindo:
- Referências devolvidas por outros pontos finais
- Links e URLs partilhados
- Mensagens e notificações no aplicativo
- Registos, exportações e histórico do navegador
Se um invasor conseguir obter um identificador válido e o backend não aplicar a propriedade, ainda existe um IDOR.
Como pentest de IA vulnerabilidades IDOR que outros não detectam
pentest de IA adota uma abordagem diferente para identificar falhas de autorização.
Em vez de se limitar à deteção, testa ativamente hipóteses sobre propriedade e controlo de acesso numa aplicação em execução.
No Aikido, essa abordagem é implementada por meio Aikido , um teste de penetração autônomo que combina a criatividade humana com a velocidade da máquina. Ele foi projetado para avaliar falhas de autorização e propriedade em ambientes reais. Aikido opera usando identidades reais, executa fluxos de trabalho de ponta a ponta e valida a explorabilidade antes de relatar as descobertas.
Para os IDORs, este processo envolve:
- Autenticação como utilizadores reais
- Exercitar fluxos de trabalho completos de ponta a ponta
- Reutilização de identificadores de objetos entre funções e contextos
- Tentar aceder ou modificar recursos pertencentes a outros utilizadores
- Validar se o comportamento é explorável e reproduzível
Apenas as questões que podem ser exploradas na prática são relatadas. As restantes são descartadas automaticamente.
Isso reduz os falsos positivos e garante que os resultados relatados representem falhas reais de autorização. Em situações em que a intenção não é clara, um testador humano normalmente precisaria consultar o proprietário da aplicação. A validação em tempo de execução resolve isso diretamente.
Testes focados nas premissas de propriedade
pentest de IA esforços específicos à avaliação das suposições de propriedade associadas aos identificadores de objetos em toda a aplicação.
Em vez de tratar os IDORs como um efeito secundário dos testes genéricos, concentra-se explicitamente em:
- Identificadores vinculados a recursos pertencentes ao utilizador
- Transições de fluxo de trabalho que reutilizam referências de objetos
- Pontos finais de backend que dependem de suposições de propriedade do frontend
Isso garante uma cobertura consistente das partes de um sistema onde os IDORs realmente ocorrem.
Exemplo: IDOR num fluxo de trabalho de aprovação em várias etapas
Este exemplo ilustra como um IDOR pode surgir em várias etapas do fluxo de trabalho, mesmo quando os pontos finais individuais parecem aplicar o controlo de acesso corretamente.
Contexto da aplicação
A aplicação inclui um fluxo de trabalho de aprovação em várias etapas para ações confidenciais. Um utilizador cria uma solicitação que deve ser posteriormente analisada e aprovada. Cada solicitação está vinculada ao utilizador que a criou e é referenciada por um identificador usado em várias chamadas de API.
Apenas o proprietário de uma solicitação pode visualizá-la ou modificá-la antes da aprovação.
O que o sistema observou
pentest de IA como um utilizador padrão e executou o fluxo de criação de pedidos. Durante este processo, o sistema armazenou o estado intermédio do fluxo de trabalho no servidor e reutilizou-o nas etapas posteriores.
As verificações iniciais de propriedade foram aplicadas corretamente quando a solicitação foi criada.
Teste de propriedade em todo o fluxo de trabalho
Testes adicionais avaliaram como o identificador da solicitação foi usado em etapas posteriores. Observou-se que:
- O identificador foi reutilizado ao retomar uma solicitação pendente
- As chamadas API posteriores assumiram a propriedade com base na validação anterior.
- A propriedade não foi revalidada quando o fluxo de trabalho foi retomado.
Ao repetir a ação de retomada com um utilizador autenticado diferente e substituir o identificador da solicitação, o sistema conseguiu aceder e agir sobre uma solicitação que não lhe pertencia.
Por que isso era uma vulnerabilidade IDOR
O problema não se originou de uma única verificação em falta.
Isso resultou da suposição de que a propriedade já havia sido validada anteriormente no fluxo de trabalho e não precisava ser verificada novamente quando a solicitação foi retomada. Essa suposição falhou quando os identificadores de objeto foram reutilizados entre os utilizadores.
Validação e reprodutibilidade
Antes de reportar o problema, o sistema:
- Reproduziu a sequência completa várias vezes
- Comportamento consistente confirmado
- Provas recolhidas de acesso não autorizado
Somente após a reprodutibilidade e o impacto terem sido confirmados é que a questão foi relatada.
Por que isso seria ignorado por outras abordagens
Cada terminal individual funcionou corretamente quando isolado. A vulnerabilidade só surgiu quando:
- Um fluxo de trabalho foi parcialmente concluído
- O estado do lado do servidor foi reutilizado
- Uma etapa posterior foi invocada fora do contexto original do utilizador
Isso tornou o problema difícil de ser detectado por meio de testes manuais e invisível para ferramentas de verificação baseadas em solicitações.
Por que os testes contínuos são importantes para vulnerabilidades IDOR
Os IDORs são frequentemente introduzidos por mudanças.
Eles geralmente aparecem quando:
- Novos recursos reutilizam modelos de dados existentes
- A lógica de autorização é adicionada num local, mas não noutro
- Refactores inadvertidamente ignoram verificações de propriedade anteriores
Um teste pontual pode confirmar que a propriedade é aplicada hoje, mas essa garantia diminui à medida que a aplicação evolui.
Os testes contínuos baseados em IA mantêm a confiança ao reavaliar as premissas de propriedade à medida que o software muda. pentest contínuo apoiam isso ao testar continuamente fluxos de trabalho novos e modificados para acesso não autorizado a objetos.
Vulnerabilidades IDOR como um sintoma da complexidade do sistema
Os IDORs não são casos extremos. Eles são um resultado natural de sistemas complexos que evoluem ao longo do tempo.
À medida que as aplicações crescem, a lógica de propriedade se espalha por serviços, fluxos de trabalho e camadas. As suposições se acumulam e o raciocínio sobre o acesso ao nível do objeto torna-se cada vez mais difícil.
pentest de IA elimina essa complexidade, mas torna-a testável.
Ao exercer sistematicamente fluxos de trabalho, rastrear o estado e validar a propriedade no contexto, transforma uma das classes de vulnerabilidade mais persistentes em algo que pode ser detetado mais cedo, de forma mais consistente e com maior confiança.
As equipas de segurança priorizam cada vez mais as IDORs e outras falhas de autorização porque são específicas do sistema, propensas a regressão e difíceis de validar sem testes de tempo de execução que levem em consideração o fluxo de trabalho.
Você também pode gostar:
Proteja seu software agora
.avif)
