Adultere o ID da Fatura: Um Walkthrough de IDOR / Broken Object Level Authorization

Uma referência direta insegura a objeto (IDOR) acontece quando uma aplicação expõe uma referência a um objeto interno - uma linha de banco de dados, um arquivo, uma fatura - diretamente na requisição e então confia nessa referência sem verificar se quem está chamando tem permissão para acessar aquele objeto específico. O formato clássico é um id numérico em uma URL ou query string, como /api/invoice?id=1019. Como o id é sequencial e previsível, um atacante pode simplesmente trocá-lo por um valor vizinho e pedir o registro de outra pessoa.

O detalhe sutil é que o endpoint não é desautenticado. O servidor validou corretamente o cookie de sessão, então ele sabe qual usuário está chamando. O erro é que ele parou por aí: nunca fez a segunda pergunta - essa fatura realmente pertence ao usuário logado? Verificar identidade (autenticação) não é o mesmo que verificar permissão a um objeto específico (autorização). Quando essa verificação por objeto está ausente, a falha também é chamada de broken object level authorization (BOLA), o risco número um no OWASP API Security Top 10.

Este desafio reproduz exatamente essa lacuna. Você tem em mãos uma requisição real e capturada para a sua própria fatura. O id aparece na requisição como texto simples e editável, e nada no formato da resposta sugere que o servidor diferencia os seus registros dos de qualquer outra pessoa - o que é exatamente o sinal de que a autorização está sendo pulada.

• Supor que um login válido é suficiente. Muitos aprendizes veem o cookie de sessão e concluem que o endpoint é seguro. A autenticação só prova quem está chamando; ela não diz nada sobre quais objetos esse chamador pode ler.
• Editar a parte errada da requisição. O caminho, o host e o cookie devem permanecer exatamente como capturados. Só a referência ao objeto - o valor do id - precisa mudar, e apenas esse campo está em jogo aqui.
• Parar em um 404 e desistir. Uma resposta de não encontrado só significa que aquele id não existe; é um retorno, não um obstáculo. Ajuste o id para um valor que provavelmente seja um registro real e vizinho.
• Tratar IDOR como um bug de injeção. Não são necessários caracteres especiais, encoding ou payload. Você troca um id legítimo por outro id legítimo - a vulnerabilidade é a falta de controle de acesso, não uma entrada não sanitizada.

A correção é uma verificação de propriedade em nível de objeto em todo acesso. Depois que a sessão é autenticada, o servidor precisa confirmar que o objeto solicitado pertence (ou é compartilhado com) aquele usuário antes de retorná-lo - por exemplo, restringindo a consulta ao chamador: SELECT * FROM invoice WHERE id = ? AND owner_user_id = :sessionUser. Se a linha não corresponder, retorne 404 ou 403 e nunca os dados. Reforçar o fluxo de login não resolve nada aqui, porque o atacante já está logado.

• Aplique a autorização por objeto no servidor; nunca confie que o cliente vai solicitar apenas os ids que ele "deveria" conhecer.
• Prefira identificadores imprevisíveis (UUIDs) a inteiros sequenciais para eliminar a enumeração fácil, mantendo ainda a verificação de propriedade - obscuridade sozinha não é controle de acesso.
• Registre e alerte tentativas de acesso que falham na verificação de propriedade, especialmente varreduras sequenciais de id.