Soluções

Segurança de APIs GraphQL: pentest autônomo que modela o schema

APIs GraphQL escondem os bugs que pagam dentro do schema: IDOR em nós, autorização por campo, batching. Veja como o EVERSEC RAGE modela o schema e deduz esses bypasses.

Por que GraphQL quebra a ferramenta tradicional

GraphQL move a autorização do endpoint para o campo. Um único /graphql expõe dezenas de tipos, nós e mutations, e o scanner que varre rota por rota não enxerga essa superfície. Por isso os bugs que pagam em GraphQL raramente são injeções clássicas: são falhas de lógica e de autorização escondidas no schema.

Os riscos reais

  • Introspection exposta: __schema liberado em produção entrega o mapa inteiro da API (tipos, campos, argumentos, deprecations). Não é o bug em si, mas é o combustível de todos os outros.
  • IDOR em nós (node-level): node(id: "...") ou queries por ID que devolvem objetos de outro tenant. A autorização passa no resolver do topo mas vaza num campo aninhado.
  • Autorização por campo (field-level): o usuário pode ler user { email } mas não deveria ver user { paymentMethods }, e o resolver daquele campo esqueceu de checar.
  • Batching e DoS: aliases repetidos, queries aninhadas profundas ou um array de operations num único POST que multiplicam o custo, brute force sob o radar do rate limit e amplificação de carga.
  • Mutations sem escopo: a mutation confia no ID que o cliente manda em vez de derivar do token.

Como o EVERSEC RAGE modela o schema e deduz o bypass

O diferencial do EVERSEC RAGE é modelar-e-deduzir em vez de só disparar payloads. Em GraphQL isso é literal:

  1. Reconstrói o schema, via introspection quando disponível, ou inferido a partir do tráfego observado quando ela está desligada.
  2. Mapeia a matriz de autorização inteira (authz_matrix): qual ator alcança qual tipo/campo/mutation, cruzando papéis e tenants.
  3. Aprende a máquina de estados dos fluxos críticos (auth, checkout) e faz model-checking: cada contraexemplo é um bypass de autorização deduzido, não um chute.
  4. Resolve o input exato do bypass e valida com verificação metamórfica para bugs de lógica.

Todo candidato passa pelo firewall determinístico: 10 gates + AutoReject + confiança recomputada. Quem decide se vira report é código, não o modelo: um "IDOR" que na verdade era dado público, ou uma introspection sem impacto, morre ali.

Comparação honesta

Capacidade EVERSEC RAGE Scanner de template Pentest manual
Introspection / má-config Detecta Detecta bem Detecta
IDOR em nó aninhado Deduz do modelo Raramente Sim, com esforço
Bypass de autorização por campo Deriva da matriz Não Sim
Cobertura contínua Sim (Modo Profundo) Sim Pontual
Lógica de negócio densa Boa Nenhuma A melhor

Quando usar cada um:

  • Scanner de template (graphql-cop, nuclei): triagem rápida de má-configuração, introspection ligada, field suggestions, CSRF. Barato, mas para na superfície.
  • Pentest manual: quando o alvo é crítico e você precisa do julgamento humano sobre lógica de negócio densa. Insubstituível, e caro por hora.
  • EVERSEC RAGE: quando você quer cobertura autônoma e persistente da matriz de autorização, deduzindo bypasses de nó e de campo que o template não acha, sem pagar hora de consultor. Ele não substitui o pentester sênior num alvo de alto valor; cobre o volume e o longo prazo que o humano não escala.

O EVERSEC RAGE roda como SaaS 100% gerenciado, com workers isolados em pods gVisor por tenant, firewall de egress e Postgres com FORCE-RLS: isolamento por arquitetura, não um perímetro que você mesmo precisa manter. BYO-key: você traz sua própria chave de LLM, sem custo de inferência embutido.

Quer ver o EVERSEC RAGE modelar o schema de um alvo GraphQL do seu programa? Conecte um escopo e deixe o Modo Profundo rodar.

Perguntas frequentes

O EVERSEC RAGE precisa de introspection ligada para testar GraphQL?
Não. Quando `__schema` está exposto, ele acelera o mapeamento; quando está desligado, o EVERSEC RAGE infere o schema a partir do tráfego observado e continua deduzindo a matriz de autorização.
Qual a diferença entre graphql security testing com scanner e com o EVERSEC RAGE?
O scanner de template acha má-configuração (introspection, CSRF, field suggestions). O EVERSEC RAGE modela o schema e deduz bypasses de autorização por nó e por campo, bugs de lógica que o template não enxerga.
Como o EVERSEC RAGE evita falso-positivo de IDOR em GraphQL?
Todo candidato passa por um firewall determinístico (10 gates + AutoReject + confiança recomputada). O juiz é código, não o modelo: um IDOR sobre dado público ou autocontido é morto antes de virar report.
O EVERSEC RAGE causa DoS ao testar batching e profundidade de query?
Não. Ele modela o vetor (aliases, aninhamento, batching) e demonstra a primitiva de forma contida, com contenção declarada. A prova é de alcance, não de dano: degradar o serviço é proibido.
Dá para rodar o EVERSEC RAGE contra uma API GraphQL interna, atrás de VPN?
Depende do alcance de rede: como o EVERSEC RAGE é SaaS, o worker precisa conseguir alcançar o alvo dentro do escopo autorizado; uma API completamente isolada, sem nenhuma exposição de rede, fica fora de alcance. O que a arquitetura garante, para qualquer alvo que você conecte, é o isolamento por tenant: sandbox gVisor, firewall de egress e Postgres com FORCE-RLS, então o teste de uma API sensível não se mistura com o de outro cliente.

Relacionados