Pular para o conteúdo
Categoria: Pentest8 min de leitura

Pentest de APIs REST e GraphQL: Checklist Tecnico para Bug Bounty Legal

Por Lucas Andrade ·

Metodologia tecnica para testar APIs REST e GraphQL em programas autorizados, com foco em IDOR, bypass de autenticacao e introspeccao maliciosa.

Pentest de APIs REST e GraphQL: Checklist Tecnico para Bug Bounty Legal

APIs viraram o ponto mais lucrativo de qualquer programa de bug bounty serio, e tambem o mais negligenciado pelos pentesters que ainda focam em XSS no formulario de contato. Um IDOR num endpoint de /api/v3/users/{id}/invoices pode pagar tres a oito mil dolares no HackerOne, enquanto um reflected XSS em pagina marketing fecha em 250. A equipe Basilisk OffSec compilou neste checklist o fluxo exato que usamos em engajamentos autorizados e em programas publicos como GitLab, Shopify e Reddit. Antes de qualquer coisa: leia o escopo, confirme o brand domain, e nunca toque em endpoints fora da lista. Tudo aqui pressupoe autorizacao escrita, e tudo e enquadrado no OWASP API Security Top 10 (2023).

Autorizacao e escopo primeiro, sempre

Antes de qualquer ferramenta rodar, existe uma unica pergunta: eu tenho permissao de tocar nisso. Bug bounty sem confirmar escopo nao e pentest, e incidente. Leia o documento de politica, anote os dominios em escopo, os endpoints explicitamente excluidos (muitas vezes /admin ou fluxos de pagamento) e as tecnicas proibidas (quase sempre DoS e engenharia social). Registre a data, a versao do programa e sua conta de teste. Essa disciplina nao e burocracia, e a diferenca entre uma bounty paga e uma denuncia. Bug bounty legal e disciplina antes de criatividade.

Mapeie a superficie antes de disparar qualquer payload

O ponto de partida nunca e o Burp aberto na cara. E o mapeamento de superficie. Pegue o app mobile com apktool, extraia strings de URL, jogue no Burp como sitemap manual. Use ffuf com a wordlist api-endpoints-res.txt da SecLists contra paths como /api/, /v1/, /internal/, /graphql, /gql, /query. Wayback Machine via gau e waybackurls revelam endpoints depreciados que ninguem patcheou. Em uma engagement recente encontramos um /api/v1/admin/export herdado de 2019 que aceitava token de usuario comum, similar ao que descrevemos em Pentest Web do Zero: Montando um Lab Seguro com DVWA, Juice Shop e Burp Suite. Documente cada endpoint com metodo, content-type esperado e papel necessario antes de testar qualquer payload.

IDOR/BOLA: o bug mais caro em REST

IDOR continua sendo o bug numero um em APIs REST por uma razao simples: desenvolvedores confiam no ID vindo do JWT mas leem o ID da URL. Crie duas contas no app alvo, capture as duas sessoes no Burp, e use a extensao Autorize ou Auth Analyzer para reenviar cada request da conta A com o cookie da conta B. Preste atencao em respostas 200 com corpo diferente, nao so em status codes. UUIDs nao sao protecao: enumere via endpoints de busca, exports CSV ou notificacoes. Teste tambem o lado de escrita: PUT e DELETE com ID alheio, porque IDOR de leitura e info disclosure mas IDOR de escrita e account takeover.

A logica de injecao tambem se aplica em APIs, como mostramos em SQL Injection na Pratica: Explorando, Detectando e Mitigando em Lab Controlado, especialmente em filtros sort, order e search que viram concat de SQL. Um ?sort=name)-- ou um delay booleano no corpo JSON costuma revelar que o parametro entra sem protecao na query. Nunca reporte uma SQLi sem uma prova reproduzivel e nao destrutiva (sem DROP, sem UPDATE), apenas extraindo um valor inofensivo como a versao do banco.

GraphQL muda o jogo

GraphQL muda o jogo. Comece testando introspeccao em /graphql com a query {__schema{types{name fields{name}}}}. Se estiver aberto em producao, voce ja tem metade do relatorio escrito. Ferramentas como InQL, GraphQL Voyager e clairvoyance reconstroem schemas mesmo com introspeccao desabilitada via field stuffing. Procure por mutations expostas como adminUpdateUser, impersonate, exportAllData. Batch queries permitem bypass de rate limit: envie 1000 mutations login em uma so request HTTP. Alias overloading quebra validadores ingenuos. Diferente do que cobrimos em XSS Moderno: DOM, Stored e Reflected com Exemplos Reais em Ambiente de Teste, aqui o impacto e quase sempre logico, nao injecao de script.

Bypass de auth vai alem do none algorithm

Bypass de autenticacao nesse contexto vai alem do classico none algorithm no JWT. Teste jku e kid injection, troca de RS256 por HS256 usando a publica como segredo, e tokens de refresh que nunca expiram. Headers como X-Original-URL, X-Rewrite-URL, X-Forwarded-For e X-User-Id frequentemente bypassam middlewares de auth quando a API esta atras de um gateway mal configurado. Em GraphQL, verifique se @auth directive cobre todos os campos ou se algum nested resolver vaza dados sem checagem. Teste tambem a logica de expiracao: um token revogado que continua aceito apos logout e um relatorio limpo e bem pago.

SSRF, mass assignment e business logic

SSRF tambem aparece em APIs que aceitam URL como parametro para webhooks ou avatares, padrao que detalhamos em SSRF Descomplicado: Explorando Cloud Metadata em Lab AWS Local com exploits contra IMDS da AWS. Para mass assignment, adicione campos como isAdmin:true, role:owner, verified:true em qualquer PATCH ou PUT; frameworks como Rails e NestJS com whitelist incompleta entregam admin no prato. Business logic e a classe que scanner nunca acha: quantidades negativas, troca de moeda entre o calculo de preco e a cobranca, aplicacao dupla de cupom. Esses bugs exigem que voce entenda o fluxo de negocio, nao so o protocolo.

Rate limiting e race conditions

Rate limiting, testado direito, raramente e bounty sozinho, mas e o multiplicador de outros bugs: ausente no endpoint de OTP ou login, um codigo de 6 digitos e bruteforced em minutos. Para race conditions em endpoints de cupom ou saque, use Turbo Intruder com single packet attack do James Kettle, mandando 30 requests simultaneas; se um cupom de 50 dolares resgata cinco vezes, voce tem relatorio de impacto financeiro. Combine race com business logic: o classico duplo saque onde a checagem de saldo e o debito nao sao atomicos.

Upload de arquivos, desserializacao e parametros ocultos

Duas classes de bug costumam ficar sem teste em pentest de API e pagam bem. Primeiro, upload de arquivos: teste cada endpoint de upload por content-type confusion (um payload PHP ou SVG declarado como image/png), path traversal no nome (../../avatar.php), falta de validacao de tamanho e MIME, e, quando ha processamento de imagem no lado servidor, cadeias de ImageMagick ou ffmpeg que levam a RCE ou SSRF. Segundo, desserializacao: APIs que aceitam objetos serializados em cookies, headers ou corpos (Java, .NET, PHP, pickle do Python, Marshal do Ruby) sao caminho direto para RCE se existir uma gadget chain. Procure blocos base64 que comecam com magic bytes conhecidos (rO0 para Java, ac ed em hex). Some parameter mining com Arjun ou param-miner: muitas APIs processam campos nao documentados como debug=true, preview ou internal que nunca aparecem na doc oficial e furam checagens de autorizacao. As tres classes exigem um PoC limpo e nao destrutivo, e so cabem em alvos autorizados.

Reporting: por que se paga impacto, nao tecnica

Documente impacto com numero de registros expostos, valor financeiro estimado e PoC reproduzivel em curl. Programas pagam pelo impacto demonstrado, nao pela tecnica. Monte um template de relatorio com titulo CWE, passos numerados, request bruto, response truncada e sugestao de fix em uma linha. Submeta cedo, antes de duplicatas, mas nunca sem confirmar escopo. Um relatorio limpo e conciso com impacto claro e pago mais rapido e mais alto que um muro de texto cheio de cenarios especulativos.

Checklist pratico

(1) escopo e autorizacao confirmados por escrito. (2) superficie totalmente mapeada (mobile, Wayback, ffuf). (3) IDOR/BOLA leitura e escrita com duas contas. (4) GraphQL introspeccao, batch, alias, mutations expostas. (5) JWT: alg confusion, kid/jku, expiracao, revogacao apos logout. (6) mass assignment em cada endpoint de escrita. (7) SSRF em cada parametro URL. (8) rate limit nos fluxos de auth e race nos fluxos de dinheiro. (9) business logic contra o fluxo real. (10) relatorio com impacto, PoC e fix.

FAQ: Com o que um iniciante deve comecar?

Com IDOR/BOLA. E o bug mais comum, mais facil de provar e bem pago, e so precisa de duas contas de teste e Burp com Autorize. Construa intuicao primeiro no seu proprio lab, como o setup DVWA/Juice Shop, antes de tocar um programa real. Depois que voce acha IDOR de forma confiavel, expanda para GraphQL e ma configuracao de JWT, tecnicamente relacionadas e que costumam aparecer juntas em APIs modernas.

FAQ: Como evito quebrar o escopo sem querer?

Configure o Burp com um target scope estrito e ative "Drop out-of-scope requests" para que nenhuma ferramenta atinja hosts alheios por acidente. Evite scanners ativos automatizados se a politica nao permite, e nunca dispare ataques de alto volume (podem contar como DoS). Na duvida, pergunte ao programa pelo canal oficial antes de testar. O erro mais caro nao e um bug perdido, e um teste fora da autorizacao.

Conclusao

Bug bounty legal e disciplina antes de criatividade, e e nessa disciplina que a Basilisk constroi reputacao em programas como o do Mercado Livre e Nubank. O fluxo e reproduzivel: escopo, mapeamento, passagem sistematica pelas classes de bug de API, relatorio de impacto limpo. Quem internaliza esse processo acha mais e melhores bugs que quem joga payload as cegas, e faz dentro das regras, que no longo prazo e o unico caminho que paga.

Leituras relacionadas

Nenhum comentário ainda

Seja o primeiro a comentar.

Deixe seu comentário

Entre com sua conta Canverly para comentar. Você pode usar a mesma conta em qualquer site da rede.

Entrar com Canverly