Ir para o conteúdo

API5:2023 Broken Function Level Authorization

Agentes Ameaça/Vetores Ataque Falha Segurança Impactos
Específico da API : Abuso Fácil Prevalência Comum : Deteção Fácil Técnico Grave : Específico Negócio
Para abusar deste tipo de falha o atacante tem de realizar pedidos legítimos ao endpoint da API ao qual não é suposto ter acesso como utilizadores anónimos, ordinários ou não privilegiados. Endpoints expostos serão facilmente explorados. As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração ou ao nível da implementação. A correta implementação destes mecanismos pode tornar-se confusa, uma vez que, as aplicações modernas prevêem vários perfis ou grupos de utilizador, assim como complexos esquemas de hierarquias (e.g. sub-utilizadores, utilizadores com mais do que um perfil). É mais fácil descobrir estas falhas em APIs dado que APIs são mais estruturadas, e aceder a diferentes funções é mais previsível. Estas falhas permitem aos atacantes aceder de forma não autorizada a certas funcionalidades. As funcionalidades administrativas são o alvo preferencial neste tipo de ataqueo que pode levar a divulgação de dados, perda de dados, ou corrupção de dados. Por último, pode dar aso a uma disrupção de serviço.

A API é vulnerável?

A melhor forma de identificar falhas de verificação de autorização de acesso a funções é através duma análise detalhada do mecanismo de autorização, devendo ter-se em consideração o esquema de hierarquia de utilizadores, diferentes perfis ou grupos e questionando continuamente:

  • Utilizadores ordinários podem aceder aos endpoints de administração?
  • Os utilizadores podem realizar ações sensíveis (e.g. criar, modificar ou apagar) para as quais não deveriam ter acesso, alterando simplesmente o método HTTP (e.g. alterando de GET para DELETE)?
  • Um utilizador do grupo X pode aceder a uma função reservada ao grupo Y, adivinhando o URL do endpoint e os parâmetros (e.g. /api/v1/users/export_all)?

Nunca assuma o tipo dum endpoint, normal ou administrativo, apenas com base no URL.

Apesar dos programadores poderem ter decidido expor a maioria dos endpoints administrativos sob um mesmo prefixo, e.g. api/admins, é comum encontrarem-se endpoints administrativos sob outros prefixos, misturados com endpoints ordinários e.g. api/users.

Exemplos de Cenários de Ataque

Cenário #1

Durante o processo de registo para uma aplicação que permite apenas a adesão de utilizadores convidados, a aplicação móvel faz uma chamada de API para GET /api/invites/{invite_guid}. A resposta contém um JSON com detalhes sobre o convite, incluindo o perfil do utilizador e o email do utilizador.

Um atacante duplica o pedido e manipula o método HTTP e o endpoint para POST /api/invites/new. Este endpoint deveria ser usado apenas por administradores através da consola de administração. O endpoint não implementa verificações de autorização de acesso à função.

O atacante explora a falha e envia um novo convite com privilégios de administrador:

POST /api/invites/new

{
  "email": "[email protected]",
  "role":"admin"
}

Mais tarde, o atacante usa o convite criado maliciosamente para criar uma conta de administrador e obter acesso total ao sistema.

Cenário #2

Uma API contém um endpoint que deveria ser exposto apenas a administradores - GET /api/admin/v1/users/all. Este endpoint retorna os detalhes de todos os utilizadores da aplicação e não implementa verificações de autorização de acesso à função. Um atacante que aprendeu sobre a estrutura da API faz uma suposição informada e consegue aceder a este endpoint, expondo detalhes sensíveis dos utilizadores da aplicação.

Como Prevenir

A sua API deve usar um módulo de autorização consistente e fácil de analisar, o qual deve ser invocado por todas as funções de negócio. Frequentemente, este tipo de proteção é oferecido por um ou mais componentes externos à lógica aplicacional.

  • Por omissão todos os acesso devem ser negados, exigindo que permissões específicas sejam concedidas a perfis específicos para acesso a cada função.
  • Rever todos os endpoints à procura de falhas ao nível da verificação de autorização de acesso a funções, tendo sempre em consideração a lógica de negócio da aplicação e hierarquia dos grupos.
  • Assegurar que todos os controladores administrativos herdam de um controlador administrativo base que implementa as verificações de autorização com base no grupo/perfil do utilizador.
  • Assegurar que funções administrativas num controlador ordinário implementam elas próprias as verificações de autorização baseadas no grupo e perfil do utilizador.

Referências

OWASP

Externas