hunt-graphql

⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato do alvo, IP, conta ou recurso.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Alvos Principais (Crown Jewel Targets)

Vulnerabilidades GraphQL são de alto valor porque a superfície de ataque é ampla e profunda — um único endpoint pode expor modelos de dados inteiros, caminhos de escalonamento de privilégios e confusão de estado entre APIs. Os maiores retornos ocorrem em:

• APIs de Plataforma (alvos do nível GitHub, Shopify, Stripe) onde mutações GraphQL interagem com APIs REST que gerenciam os mesmos recursos
• Condições de corrida entre mutações GraphQL e endpoints REST onde a sincronização de estado não é atômica — estas atingem gravidade média a alta de forma confiável
• Bugs de persistência de autorização onde o estado de associação de equipe/organização/repositório é controlado por uma API, mas legível/gravável por outra
• Plataformas SaaS B2B onde um inquilino afetando outro através de travessia de esquema = crítico
• Endpoints GraphQL de administração interna acidentalmente expostos a usuários de menor privilégio

Os relatórios do GitHub demonstram o padrão de alvo principal: privilégios que deveriam ser revogados persistem porque duas APIs discordam sobre a verdade fundamental.

Sinais da Superfície de Ataque

Padrões de URL:

/graphql
/api/graphql
/v1/graphql
/query
/gql
/graph
/api/v2/graphql
/internal/graphql

Cabeçalhos de Resposta:

Content-Type: application/json  (with query body)
X-Request-Id + no REST-style path params = likely GraphQL

Padrões de Código Fonte JavaScript:

// grep for these in JS bundles
"query {"
"mutation {"
"__typename"
"apollo"
"ApolloClient"
"graphql-tag"
"gql`"
"operationName"
"GRAPHQL_URI"

Sinais de Pilha Tecnológica:

• Apollo Server/Client em pacotes JS
• Relay em aplicativos React
• graphene ou strawberry (Python), graphql-ruby, gqlgen (Go), Lighthouse (Laravel)
• Requisições POST com corpo {"query": "..."} no histórico do Burp
• __schema ou __type em qualquer resposta = GraphQL confirmado

Fontes de Reconhecimento:

• Pesquisa github.com: "graphql" site:target.com
• Wayback Machine para caminhos /graphql
• Escaneamento de pacotes JS com LinkFinder ou getallurls

Metodologia de Caça Passo a Passo

1. Descobrir o endpoint — rastrear pacotes JS, verificar /graphql, /api/graphql, revisar acertos de varredura passiva do Burp para POST application/json com campos de consulta

2. Testar introspecção — enviar a consulta de introspecção completa. Mesmo que bloqueado, tente enumeração em nível de campo:

   { __typename }
   

   Se isso retornar, a introspecção pode estar parcialmente bloqueada, mas o esquema é detectável

3. Mapear o esquema completo — usar InQL (extensão Burp) ou graphql-voyager para visualizar relacionamentos. Procure especificamente por:

   • Mutações que modificam propriedade, permissões ou associação
   • Mutações que espelham a funcionalidade da API REST

4. Identificar sobreposição REST/GraphQL — documentar cada recurso que pode ser modificado por AMBOS REST e GraphQL. Essas superfícies de escrita dupla são seus alvos de RC.

5. Testar limites de autorização por mutação — reproduzir mutações como usuários de menor privilégio. O servidor impõe a mesma autorização que a chamada REST equivalente?

6. Caçar dessincronização de estado entre APIs — encontrar sequências onde:

   • A ação REST deveria revogar o acesso
   • A mutação GraphQL concede novamente ou o preserva
   • Testar a ordem: REST primeiro → GraphQL → verificar estado; depois GraphQL primeiro → REST → verificar estado

7. Testar privilégio persistente após alterações de função/associação — remover um usuário via REST, em seguida, chamar a mutação GraphQL correspondente para esse recurso. Consultar o estado atual através de ambas as APIs e comparar.

8. Sondar por IDOR em IDs de nó — IDs globais GraphQL frequentemente codificam tipo de objeto + ID. Trocar IDs entre limites de objeto e entre contextos de conta.

…