GabaritoC — Certo
✅ CERTO. A afirmação está correta: referências inseguras a objetos (IDOR) permitem que um atacante ignore a autorização e acesse diretamente recursos do sistema, como registros ou arquivos de banco de dados, manipulando identificadores (IDs) em requisições. Essa é uma falha clássica de controle de acesso, classificada no OWASP Top 10 como "Quebra de Controle de Acesso" (A01:2021).
O que são referências inseguras a objetos? É uma vulnerabilidade que ocorre quando uma aplicação expõe uma referência direta a um objeto interno (como um ID de registro, nome de arquivo ou chave de banco de dados) e não valida se o usuário autenticado tem permissão para acessar aquele objeto específico. O atacante, então, simplesmente altera o valor do identificador na URL ou em parâmetros da requisição para acessar dados de outros usuários ou recursos que não deveria ver.
A regra que rege essa vulnerabilidade é o princípio da autorização: o usuário pode estar autenticado (saber quem é), mas isso não significa que ele tenha autorização para acessar qualquer recurso. A autorização deve ser verificada em cada requisição que manipula objetos, com base na identidade do usuário e na propriedade do recurso. No OWASP Top 10 2021, essa falha se enquadra na categoria A01:2021 – Quebra de Controle de Acesso (Broken Access Control), que ocorre quando o controle de acesso não impõe a política de forma que os usuários não possam agir fora de suas permissões pretendidas.
Na prática, imagine uma API de um serviço bancário onde usuários autenticados podem consultar suas transações: GET /api/v1/transactions/874391. Se o backend não validar se a transação 874391 pertence ao usuário autenticado, basta outro cliente descobrir ou adivinhar um ID diferente (ex.: 874392) para acessar dados de terceiros. Esse é o cenário clássico de IDOR, que leva a violação de confidencialidade, escalada de privilégios horizontal (o usuário comum atua como outro usuário da mesma categoria) e perda de confiança.
A distinção importante é entre autenticação e autorização: autenticação confirma quem é o usuário; autorização define o que ele pode fazer. A vulnerabilidade IDOR explora justamente a falta de verificação de autorização no nível do objeto. A banca explora essa confusão: o candidato pode achar que, como o usuário está autenticado, o acesso é legítimo, mas a falha está na ausência de validação da propriedade do recurso.
A pegadinha aqui é sutil: a afirmação parece descrever um ataque genérico, mas ela descreve exatamente a definição de IDOR. O termo "ignorar a autorização" é a chave — o atacante não precisa de credenciais de outro usuário; ele apenas manipula o identificador para acessar recursos que não lhe pertencem. Guarde essa fronteira: IDOR = acesso direto a objetos via identificadores manipuláveis, sem verificação de autorização.
A afirmação está correta. Referências inseguras a objetos (IDOR) são exatamente isso: o atacante modifica o parâmetro "id" na URL (ou em outros campos) para acessar recursos diretamente, ignorando a autorização. O exemplo citado — acesso a registros ou arquivos de banco de dados — é o cenário típico. A vulnerabilidade ocorre quando a aplicação não verifica se o objeto pertence ao usuário autenticado, permitindo que ele acesse dados de terceiros. Isso é classificado no OWASP Top 10 como Quebra de Controle de Acesso (A01:2021).
A alternativa E afirma que o item está errado, mas o item está correto. A descrição apresentada é a definição precisa de referências inseguras a objetos (IDOR). Não há erro conceitual na afirmação: ela descreve corretamente a vulnerabilidade e seu impacto (acesso direto a recursos sem autorização). Portanto, a alternativa E é incorreta.
Gabarito: letra C
Link permanente: /questoes/ce398107