OWASP TOP 10 API - Improper Inventory Management
Manter uma documentação de API incompleta e desatualizada é extremamemte prejucial para o time de desenvolvimento e com altos riscos de segurança. Improper Inventory Management é o nome que se dá para vulnerabilidades encontradas em APIs que possuem falta de informações e atualizações na documentação. Essa vulnerabilidade se encontra em nono lugar no OWASP API Security Top 10.
A API é vulnerável?
Uma API que possuí "pontos cegos" na documentação está vulnerável à Improper Inventory Management.
Uma API tem um "ponto cego na documentação" se:
- A finalidade de um host de API não é clara e não há respostas explícitas para as seguintes perguntas
- Em qual ambiente a API está sendo executada (por exemplo, produção, preparação, teste, desenvolvimento)?
- Quem deve ter acesso de rede à API (por exemplo, público, interno, parceiros)?
- Qual versão da API está em execução?
- Não há documentação ou a documentação existente não está atualizada.
- Não há plano de aposentadoria para cada versão da API.
- O inventário do host está ausente ou desatualizado.
Uma API tem um "ponto cego no fluxo de dados" se:
- Existe um "fluxo de dados confidenciais" onde a API compartilha dados confidenciais com aplicativos de terceiros
- Não há justificativa comercial ou aprovação do fluxo
- Não há inventário ou visibilidade do fluxo
- Não há visibilidade profunda de que tipo de dados confidenciais são compartilhados
Cenários vulneráveis
Cenário #1
Uma rede social utiliza um endpoint de API para recuperar as senhas dos usuários. Esse endpoint espera um código de 6 digitos enviado para o email da conta a ser recuperada.
Um atacante descobre o email do usuário alvo e faz brute force no código de 6 digitos, porém, rapidamente ele é bloqueado. O endpoint acessado foi: "/v3/auth/reset-password".
Após um processo de enumeração, ele descobre um endpoint que não estava na documentação da API: "/v1/auth/reset-password". Pelo fato do endpoint "/v1/auth/reset-password" não estar documentado na API, os desenvolvedores não implementaram patches de segurança e atualizações.
Ao tentar brute force nesse endpoint, ele percebe que não há proteções contra esse tipo de ataque, então ele consegue rapidamente descobrir o código de 6 digitos enviado ao email do usuário e consegue alterar a senha do mesmo.
wfuzz -c -z range,000000-999999 -d "{\"code\": FUZZ}" -H "Content-type: application/json" -H "reset-password-token: xxxxx" -t 150 https://api.redesocialx.com/v1/auth/reset-passwordCenário #2
Um aplicativo de mensagens possuí um sistema onde é possível fazer integrações com aplicativos de terceiros. Esses aplicativos terão acesso a todas as mensagens particulares e grupos do usuário. Porém na API não está documentado que os aplicativos de terceiros podem acessar mensagens particulares.
Com o conhecimento de que aplicativos de terceiros podem acessar as conversas dos usuários, um grupo de hackers criam uma campanha de phishing para que vários usuários do aplicativo de mensagens utilizem o aplicativo malicioso criado pelos hackers, e assim eles conseguem visualizar mensagens, fotos, documentos pessoais entre outras coisas que os usuários compartilham em suas conversas.
Protegendo as APIs do Improper Inventory Management
Documentando todos as versões, endpoints, parâmetros entre outas funcionalidades das APIs, o time de desenvolvimento, QA e AppSec conseguem oferecer melhor suporte e proteção ao código. Grandes APIs com má documentação se tornam um pesadelo para os desenvolvedores e um presente para os hackers.
Recomendações fornecidas pela OWASP:
- Documente todos os hosts da API e aspectos importantes de cada um deles, com foco no ambiente da API (ex: produção, staging, teste, desenvolvimento), quem deve ter acesso de rede ao host (ex: público, interno, parceiros) e a versão da API.
- Documente serviços integrados e aspectos importantes como o seu papel no sistema, quais dados são trocados (fluxo de dados) e sua sensibilidade.
- Documente todos os aspectos da sua API, como autenticação, erros, redirecionamentos, limitação de taxa, cross-origin resource sharing (CORS) e endpoints, incluindo seus parâmetros, solicitações e respostas.
- Gere documentação automaticamente adotando padrões abertos. Inclua a compilação da documentação em seu pipeline de CI/CD.
- Disponibilize a documentação da API apenas para aqueles autorizados a usá-la.
- Use medidas de proteção externa, como soluções específicas de segurança de API, para todas as versões expostas de suas APIs, não apenas para a versão de produção atual.
- Evite usar dados de produção com implantações de API que não sejam de produção. Se isso for inevitável, esses endpoints deverão receber o mesmo tratamento de segurança que os de produção.
- Quando versões mais recentes de APIs incluem melhorias de segurança, realize uma análise de risco para informar as ações de mitigação necessárias para as versões mais antigas. Por exemplo, se é possível fazer backport das melhorias sem quebrar a compatibilidade da API ou se você precisa retirar a versão mais antiga rapidamente e forçar todos os clientes a migrarem para a versão mais recente.
Referências
OWASP API Security Project team