Controle de Acesso Quebrado: Forjando o Papel de Admin a Partir de um Parâmetro Controlado pelo Cliente

Controle de acesso quebrado é a falha em impor o que um usuário autenticado realmente pode fazer. É consistentemente uma das classes mais comuns e prejudiciais de vulnerabilidade web. Neste desafio, a aplicação pede ao servidor para carregar um painel de conta, e coloca o próprio papel do usuário diretamente na requisição como um parâmetro de query. O servidor lê esse parâmetro e o usa para decidir quais painéis e dados retornar - ele trata um valor que o usuário controla como a fonte da verdade para autorização.

Isso é um caso clássico de escalação de privilégio. Um papel é uma decisão de autorização, não um dado de entrada do usuário. Quando o servidor confia em um papel, campo de support ou de privilégio definido pelo cliente, qualquer usuário pode simplesmente reescrevê-lo para reivindicar um nível mais alto. A requisição passa pelo navegador e por qualquer proxy que o usuário execute, então cada byte na URL, nos headers e nos cookies é controlado pelo atacante. Ecoar esse valor de volta em uma decisão de acesso significa que a fechadura está do lado errado da porta.

A mesma causa raiz aparece sob vários nomes: escalação vertical de privilégio quando um usuário de baixo privilégio ganha um papel mais alto, insecure direct object reference quando um identificador seleciona um recurso que deveria estar fora de alcance, e mass assignment quando uma requisição silenciosamente define um campo como is_admin que o usuário nunca deveria poder tocar. Em todos os casos a correção é a mesma ideia - o servidor deve derivar a autoridade a partir da sessão autenticada, nunca de dados que o cliente pode editar.

• Assumir que o papel exibido na requisição é fixado pelo servidor, quando é apenas texto em uma URL que qualquer um pode reescrever antes de enviar.
• Tentar payloads de injeção obscuros antes de ler a requisição e perceber que um valor de autorização está à vista, totalmente editável.
• Ir direto ao nível de nome mais imponente sem ler as respostas - a opção mais alta aqui é rejeitada porque exige um segundo fator, então é um beco sem saída.
• Tratar o bug como um valor de parâmetro ruim em vez da falha real: o servidor nunca deveria ter aceitado um papel vindo do cliente.

Nunca leia o papel de um usuário, nível de permissão ou qualquer atributo de autorização a partir de um parâmetro de requisição, cookie, campo oculto de formulário ou corpo da requisição. Busque a identidade de quem chama a partir da sessão autenticada no servidor, obtenha o papel dele no seu repositório confiável, e aplique a verificação ali. A requisição deve descrever o que o usuário quer fazer, nunca o que ele tem permissão para fazer.

• Resolva o papel a partir da sessão no lado do servidor, depois verifique-o contra a ação solicitada com uma política de negar por padrão.
• Ignore e nunca confie em nenhum papel, permissão ou campo de privilégio fornecido pelo cliente - descarte em vez de acatar.
• Aplique verificações de acesso em nível de objeto e de função em todo endpoint, incluindo os que a interface não expõe, já que atacantes chamam a API diretamente.
• Registre e alerte quando uma requisição tentar reivindicar um papel mais alto do que o da sessão, para que o abuso fique visível.