Teste de API com IA: OpenAPI e GraphQL

Apps modernos são um front-end fino sobre uma API, e a API é muitas vezes onde estão os bugs de verdade. A boa notícia para quem testa é que APIs tendem a se descrever: APIs REST entregam especificações OpenAPI, e APIs GraphQL respondem queries de introspection. As duas te dão um mapa que o modelo consegue ler. Este post segue testar bugs web comuns e leva a montar um hackbot.

#APIs quebram de outro jeito

O OWASP API Security Top 10 coloca autorização no topo. As duas para aprender primeiro são broken object level authorization, onde você alcança o objeto de outro usuário, e broken function level authorization, onde você chama uma ação de admin como usuário normal. As duas são a versão em API dos bugs de controle de acesso do post anterior, e as duas são comuns porque a API tem muitos endpoints e um deles costuma esquecer a checagem.

#Ache a spec OpenAPI

Muitas APIs publicam a própria especificação. Locais comuns são /openapi.json, /swagger.json, /v1/openapi.json, ou uma página de docs que carrega uma. Baixe e você tem todo path, método, parâmetro e schema em um arquivo.

curl -s https://api.example.com/openapi.json -o openapi.json

Dê a spec ao modelo e peça para listar os endpoints, marcar os que leem ou escrevem objetos de propriedade do usuário, e sinalizar os cujos nomes sugerem um papel de admin ou interno. Essa passada de leitura vira um longo documento OpenAPI em uma lista ranqueada do que testar primeiro.

#Introspection GraphQL

Uma API GraphQL costuma responder uma query de introspection que retorna o schema inteiro: todo type, field, query e mutation. Quando introspection está ligada, você recebe toda a superfície de ataque em um request.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

Entregue o schema ao modelo e peça para agrupar as queries e mutations, escolher as que tocam dados de outros usuários, e nomear os argumentos que cada uma recebe. A especificação GraphQL descreve introspection, e o OWASP Web Security Testing Guide tem uma seção sobre testar GraphQL.

#Deixe o modelo planejar, depois teste na mão

A partir de qualquer um dos mapas, peça ao modelo um plano de teste curto: para cada endpoint dono de objeto, quais duas contas usar e qual id trocar; para cada operação privilegiada, de qual sessão de baixo privilégio tentá-la. O modelo é bom em virar um schema nesse checklist. Ele não consegue dizer se a checagem está de fato ausente, então você roda cada caso pelo seu proxy com as contas que controla e lê o resultado. Uma mutation que deixa um usuário normal mudar o registro de outro usuário é um BOLA limpo, provado com duas sessões.

#Confira e guarde evidência

Findings de API são fáceis de provar e fáceis de exagerar. Prove com contas que você controla, uma variável de cada vez, e salve o request e a response completos de cada. Para um BOLA, a evidência são dois requests: o seu próprio objeto, depois o objeto da outra conta retornado para a sua sessão. Para um BFLA, é a chamada privilegiada funcionando a partir de uma sessão que não deveria ter permissão de fazê-la. Mantenha no mínimo os dados internos que você alcança para mostrar impacto, e descreva só o que você demonstrou.

#Uma nota sobre automação e rate

APIs tornam tentador scriptar centenas de requests. Confira antes as regras do programa sobre automação e rate, mantenha o volume baixo no alvo ao vivo, e faça a iteração pesada contra uma cópia local. Uma API que você martela é uma API cujo dono repara pelo motivo errado.

#A seguir nesta trilha

Agora você rodou o loop inteiro na mão. Os próximos três posts montam um pequeno agente que roda as etapas de recon e teste para você, sob a sua aprovação. Comece com a arquitetura do hackbot.