Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
Este artigo apresenta uma análise empírica em larga escala de 107 relatórios de recompensa por bugs classificados, revelando que a BOLA em nível de ação é uma família de vulnerabilidades dominante, porém sub-representada, e demonstrando que a dependência de tags de plataforma superestima significativamente a prevalência da Autorização de Nível de Objeto Quebrada.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você está caminhando por um complexo de apartamentos massivo e de alta tecnologia. Você possui um cartão de acesso que permite a entrada no prédio (autenticação), mas a verdadeira segurança deveria verificar qual apartamento específico você tem permissão para entrar.
A Autorização de Nível de Objeto Quebrada (BOLA) é o que acontece quando o guarda de segurança do prédio esquece de verificar seu cartão de acesso contra o número do apartamento específico que você está tentando abrir. Você pode ser um residente válido, mas tenta abrir o Apartamento 402, e o guarda apenas diz: "Claro, pode passar", sem verificar se o 402 pertence a você.
Este artigo é uma investigação massiva de 107 relatórios de segurança reais de um programa de recompensa por bugs (onde hackers são pagos para encontrar essas falhas). Os pesquisadores quiseram ir além do conselho de segurança "teórico" e observar o que realmente está acontecendo no mundo real.
Aqui está a análise de suas descobertas, usando analogias simples:
1. O Problema do "Ruído de Rótulos" (Os Falsos Alarmes)
Os pesquisadores começaram analisando 200 relatórios marcados como "IDOR" (um nome comum para esse tipo de bug) no HackerOne.
- A Descoberta: Apenas 42% desses relatórios eram realmente o caso real.
- A Analogia: Imagine um sistema de alarme de incêndio que dispara 200 vezes. Os pesquisadores descobriram que 39% das vezes não era um incêndio de forma alguma — era apenas alguém queimando torrada, um chuveiro com vapor ou um sensor quebrado.
- Conclusão: Apenas porque um sistema é marcado com "IDOR" não significa que ele possui a vulnerabilidade específica e perigosa de "Objeto Quebrado". As equipes de segurança frequentemente superestimam o risco porque confiam demais nas etiquetas.
2. Os Dois Principais Vilões (A Taxonomia)
Os pesquisadores classificaram os bugs reais em seis categorias. Duas delas foram as claras vencedoras, representando quase 80% de todos os casos:
Vilão A: A "Referência Direta a Objeto" (O Truque do Livro Telefônico)
- O que é: Você vê uma URL como
site.com/fatura/101. Você muda o número para102e, de repente, vê a fatura de outra pessoa. - A Analogia: É como caminhar até uma fileira de caixas de correio. Você sabe que sua caixa é a #101. Você tenta a #102, e a fechadura está quebrada, então você a abre e lê o correio do seu vizinho.
- Frequência: Isso aconteceu em 37% dos casos.
- O que é: Você vê uma URL como
Vilão B: O "Objeto de Nível de Ação" (O Vândalo)
- O que é: Esta é a grande surpresa. Não se trata apenas de ler os dados de outra pessoa; trata-se de alterar ou excluir eles.
- A Analogia: Você se aproxima da caixa de correio do seu vizinho (que você não deveria tocar) e, em vez de apenas ler o correio, arranca a caixa da parede, exclui os e-mails dela ou transfere o dinheiro dela.
- Frequência: Isso aconteceu em 42% dos casos.
- Por que importa: A maioria dos guias de segurança foca em "ler" dados. Este artigo diz: "Ei, os bandidos estão na verdade destruindo e alterando dados com mais frequência do que apenas espionando".
3. Os Outros Vilões Sorrateiros
Os 20% restantes de bugs foram mais complexos:
- Isolamento de Inquilino: Você está em um prédio de escritórios compartilhado. Você tenta abrir a porta para a suíte de escritório de uma empresa diferente, e a fechadura falha.
- Contexto de Fluxo de Trabalho: Você foi demitido de uma empresa, mas o sistema ainda permite que você acesse os arquivos "arquivados" de um projeto em que trabalhava porque o sistema esqueceu de atualizar seu status.
- Divulgação em Cadeia: Você não consegue adivinhar o ID, mas encontra uma lista de IDs em outra parte do aplicativo (como um recibo) e usa essa lista para invadir as contas de outras pessoas.
- Revinculação de Objeto: Você engana o sistema fazendo-o pensar que você é o dono do objeto, alterando um campo oculto na solicitação (como mudar o nome do "Proprietário" em um documento).
4. A Surpresa "Vertical" (A Viagem de Elevador)
Geralmente, pensamos nesses ataques como "Horizontais" (Usuário A roubando do Usuário B).
- A Descoberta: 12% das vezes, um usuário comum conseguiu acessar ou excluir coisas pertencentes a um Administrador.
- A Analogia: Um inquilino comum no complexo de apartamentos consegue entrar no escritório privado do gerente do prédio e excluir as chaves mestras.
- Conclusão: Este é um risco enorme que a maioria das listas de verificação de segurança ignora porque assumem que "Administradores estão seguros".
5. Os IDs "Mágicos" Não Funcionam
Desenvolvedores frequentemente pensam: "Se não usarmos números simples como 1, 2, 3, mas sim códigos longos e aleatórios (UUIDs) ou strings codificadas, estamos seguros."
- A Descoberta: 39% dos ataques bem-sucedidos usaram esses IDs "complexos".
- A Analogia: Os bandidos encontraram uma maneira de decodificar o "código secreto" na caixa de correio, perceberam que era apenas um número oculto e, em seguida, apenas incrementaram o número para chegar à próxima caixa de correio.
- Conclusão: Esconder o ID não resolve o problema. O servidor ainda precisa verificar se você é o dono do objeto, independentemente de como o ID se parece.
6. A Brecha do "GraphQL"
O artigo descobriu que muitos aplicativos modernos usam um sistema chamado GraphQL. Esses sistemas usam "IDs Globais" (como gid://hackerone/Relatorio/123).
- A Descoberta: Os atacantes descobriram que, se decodificassem esses IDs, eles revelavam os números sequenciais subjacentes, permitindo que eles adivinhassem o próximo ID facilmente.
- Conclusão: Apenas porque um ID parece uma string complexa de caracteres não significa que é aleatório.
Resumo para a Pessoa Comum
Este artigo nos diz que:
- Não confie nas etiquetas: Apenas porque um sistema é sinalizado como tendo um bug específico não significa que ele está realmente quebrado dessa maneira específica.
- Os bandidos são destrutivos: Eles não estão apenas roubando dados; estão excluindo e alterando-os com mais frequência do que pensávamos.
- Códigos secretos não são suficientes: Usar IDs complexos não impede hackers se o servidor não verificar quem é o dono dos dados.
- Usuários comuns podem prejudicar administradores: Uma conta de usuário normal às vezes pode invadir as coisas do "chefe".
O artigo conclui que os testes de segurança precisam mudar. Precisamos parar de verificar apenas se você pode ler os dados de outra pessoa e começar a verificar se você pode excluir ou alterar eles, e precisamos testar se usuários comuns podem acidentalmente (ou intencionalmente) invadir as coisas do administrador.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.