Introdução
Referências Diretas a Objetos Inseguras (IDOR) são um tipo de vulnerabilidade de controle de acesso que ocorre quando uma aplicação utiliza entradas fornecidas pelo usuário para acessar objetos diretamente. Se a aplicação não verificar adequadamente se o usuário que solicita o objeto tem autorização para acessá-lo, um atacante pode manipular a referência (como um ID de banco de dados, nome de arquivo ou ID de usuário em uma URL) para acessar dados confidenciais de outros usuários.
A distinção importante é que a referência em si não é a vulnerabilidade. A vulnerabilidade reside em confiar nessa referência sem verificar se o usuário atual tem permissão para acessá-la.
Neste laboratório, você atuará como um testador de segurança avaliando uma API de aplicação web local. Você começará autenticando-se como um usuário comum, analisando como a aplicação referencia seu perfil de usuário e, em seguida, explorará uma vulnerabilidade IDOR para acessar dados privados de outros usuários, incluindo um administrador.
Autenticar como um Usuário Comum
Nesta etapa, você interagirá com uma API web local rodando em sua máquina na porta 5000. Para começar a testar a aplicação em busca de vulnerabilidades, primeiro você precisa se autenticar como um usuário comum para obter um token de sessão válido.
Recebemos as credenciais de um usuário comum chamado Alice. Seu nome de usuário é alice e sua senha é password123.
Você usará a ferramenta de linha de comando curl para enviar uma requisição HTTP POST para o endpoint de login. O curl é uma ferramenta poderosa usada para transferir dados de ou para um servidor.
Execute o seguinte comando em seu terminal para fazer login:
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
Vamos analisar este comando:
-X POSTespecifica que estamos enviando uma requisição POST, que é normalmente usada para enviar dados como credenciais de login.-H "Content-Type: application/json"informa ao servidor que os dados que estamos enviando estão formatados como JSON.-d '...'contém o payload de dados JSON com o nome de usuário e a senha.
Se as credenciais estiverem corretas, você verá uma saída semelhante a esta:
{"token": "Bearer alice_token", "user_id": "1001"}
Anote o token e o user_id. O token (Bearer alice_token) atua como seu cartão de identificação digital. Você precisará incluí-lo em futuras requisições para provar que está autenticado. O user_id (1001) é seu identificador único no banco de dados da aplicação.
Analisar Referências de Objetos (URLs/APIs)
Agora que você está autenticado como Alice, pode acessar seu perfil de usuário. Em muitas aplicações web, os perfis de usuário são acessados via um endpoint de API que requer seu token de autenticação e uma referência ao objeto específico (neste caso, o perfil do usuário) que você deseja visualizar.
Você usará o curl novamente, mas desta vez enviará uma requisição GET para o endpoint /api/profile. Você deve incluir o token de autenticação nos cabeçalhos HTTP e especificar seu user_id na URL.
Este é exatamente o tipo de padrão que aparece em APIs reais: um token prova que a sessão existe, enquanto um parâmetro seleciona o objeto a ser buscado. Aplicações seguras devem vincular essas duas ideias com verificações de autorização.
Execute o seguinte comando para visualizar o perfil da Alice:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
Neste comando:
-H "Authorization: Bearer alice_token"passa seu cartão de identificação digital para o servidor.?user_id=1001é um parâmetro de consulta anexado à URL. Esta é a Referência Direta a Objeto. Ela diz ao servidor exatamente qual registro do banco de dados buscar.
Você deve receber uma resposta JSON contendo as informações do perfil da Alice:
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
Observe como a aplicação depende do parâmetro user_id=1001 na URL para decidir quais dados retornar. Uma aplicação segura verificaria se o usuário associado ao Bearer alice_token tem permissão para visualizar os dados do user_id=1001. Se a aplicação falhar ao realizar essa verificação de autorização, ela estará vulnerável a IDOR.
Manipular IDs de Usuário
Nesta etapa, você testará se a aplicação impõe corretamente os controles de acesso. Você está atualmente autenticado como Alice, mas o que acontece se você solicitar ao servidor os dados de outro usuário?
Essa é a questão central da autorização. "Estou logado?" e "Tenho permissão para ler este objeto?" são verificações diferentes, e confundi-las leva diretamente ao IDOR.
Vamos supor que exista outro usuário comum chamado Bob, e seu ID de usuário seja 1002. Se a aplicação for vulnerável a IDOR, ela confiará cegamente no parâmetro user_id na URL sem verificar se Alice tem permissão para visualizar o perfil de Bob.
Modifique o parâmetro user_id no seu comando anterior de 1001 para 1002. Execute o seguinte comando:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
Observe a saída retornada pelo servidor:
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
Você recuperou com sucesso as informações privadas de Bob, incluindo seu e-mail e chave secreta, enquanto ainda estava autenticado como Alice!
Isso confirma a presença de uma vulnerabilidade de Referência Direta a Objeto Insegura (IDOR). O servidor verificou se você estava logado (validando o token), mas falhou ao verificar se você estava autorizado a acessar o objeto específico (perfil de Bob) que você solicitou.
Acessar Dados Não Autorizados
Tendo confirmado a vulnerabilidade IDOR, você pode agora escalar o ataque para acessar informações altamente confidenciais. Em muitos sistemas, usuários administrativos possuem IDs previsíveis, como 1, 0 ou 9999.
Para esta aplicação, o ID de usuário do administrador é 9999. Ao explorar a mesma vulnerabilidade IDOR, você pode tentar extrair o perfil do administrador, que contém uma flag secreta.
Para documentar sua descoberta, você redirecionará a saída do seu comando curl para um arquivo chamado flag.txt dentro do seu diretório de trabalho atual (~/project).
Execute o seguinte comando para buscar o perfil do administrador e salvá-lo:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
O símbolo > redireciona a saída que normalmente seria exibida na sua tela para o arquivo especificado.
Para verificar se você capturou com sucesso os dados do administrador, leia o conteúdo do arquivo usando o comando cat:
cat ~/project/flag.txt
Você deve ver os dados do perfil do administrador, incluindo a flag secreta:
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
Parabéns! Você explorou com sucesso uma vulnerabilidade IDOR para contornar os controles de acesso e recuperar dados administrativos confidenciais.
Resumo
Neste laboratório, você explorou a mecânica das Referências Diretas a Objetos Inseguras (IDOR), uma falha crítica de controle de acesso. Você começou autenticando-se como um usuário comum e analisando como a aplicação referenciava dados de usuário via parâmetros de URL. Ao manipular esses parâmetros, você contornou com sucesso as verificações de autorização para visualizar os perfis privados de outros usuários. Finalmente, você escalou o ataque para extrair dados administrativos confidenciais.
Este exercício destaca a importância de implementar verificações de autorização robustas no lado do servidor. As aplicações nunca devem confiar apenas na entrada fornecida pelo usuário para conceder acesso a objetos; elas devem sempre verificar se o usuário autenticado tem o direito explícito de acessar o recurso solicitado.
