Ir para o conteúdo

API5:2019 Broken Function Level Authorization

Agentes Ameaça/Vetores Ataque Falha Segurança Impactos
Específico da API : Abuso 3 Prevalência 2 : Deteção 1 Técnico 2 : 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. Estes endpoints podem estar disponíveis para utilizadores anónimos, ordinários ou não privilegiados. É fácil identificar estas falhas em APIs uma vez que estas são mais estruturada, sendo a forma de acesso a certas funcionalidades mais previsível (e.g., utilizar o método HTTP PUT ao invés de GET ou substituir a palavra "user" por "admin" no URL). As verificações de autorização para aceder a uma determinada função ou recurso são normalmente geridas por configuração e às vezes 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 hierarquia (e.g., sub-utilizadores, utilizadores com mais do que um perfil). 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 ataque.

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 numa aplicação que apenas permite o registo de utilizadores por convite, é realizado um pedido GET ao endpoint /api/invites/{invite_guid}. A resposta em formato JSON contém detalhes sobre o convite, incluindo o perfil de utilizador e o seu endereço de email. Um atacante duplica o pedido e altera o método HTTP e o endpoint do medido para POST /api/invites/new. Esta funcionalidade deveria estar apenas disponível para administradores através da consola de administração, uma vez que o endpoint não implementa verificações de autorização de acesso à função.

O atacante abusa da falha e envia para si próprio um convite para criar uma conta de administrador:

POST /api/invites/new

{“email”:”[email protected]”,”role”:”admin”}

Cenário #2

Uma API implementa um endpoint que é suposto estar apenas disponível para administradores - GET /api/admin/v1/users/all. Este endpoint devolve os detalhes de todos os utilizadores da aplicação e não realiza qualquer verificação de autorização de acesso à função. Com base no conhecimento adquirido sobre a estrutura da API um atacante consegue prever com um elevado grau de certeza o URL do endpoint, ganhado acesso ao dados sensíveis de todos os 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 dum 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