💻 computer science

GraphQLer: Enhancing GraphQL Security with Context-Aware API Testing

O GraphQLer é um framework de teste de segurança automatizado de código aberto que aumenta a segurança de APIs GraphQL ao construir grafos de dependência tipados a partir de esquemas vivos para sintetizar cadeias de vulnerabilidades de múltiplas etapas, superando assim ferramentas existentes como ZAP e EvoMaster na detecção de falhas complexas e dependentes de estado, tais como IDOR, UAF e vulnerabilidades de injeção.

Autores originais: Omar Tsai, Jianing Li, Tsz Tung Cheung, Lejing Huang, Hao Zhu, Jianrui Xiao, Iman Sharafaldin, Mohammad A. Tayebi

Publicado 2026-08-05

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Omar Tsai, Jianing Li, Tsz Tung Cheung, Lejing Huang, Hao Zhu, Jianrui Xiao, Iman Sharafaldin, Mohammad A. Tayebi

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine a internet como uma cidade gigante e movimentada onde diferentes programas de computador (aplicativos) conversam constantemente entre si para compartilhar informações. Por anos, essas conversas seguiram um mapa estrito e previsível: se você quisesse uma foto, pedia pela pasta "foto"; se quisesse uma mensagem, pedia pela pasta "mensagem". Isso era como pedir algo de um menu onde cada prato tem um nome e um local fixos. Mas recentemente, uma nova forma de conversar chamada GraphQL tornou-se popular. Em vez de um menu fixo, o GraphQL é como uma máquina de vendas mágica e metamorfa. Você pode pedir exatamente o que quer, e ela tentará construir isso para você na hora. O problema é que, como essa máquina é tão flexível, às vezes ela esquece de verificar quem está parado na frente dela. Uma máquina de vendas comum poderia dar apenas um refrigerante para alguém com uma moeda, mas esta máquina mágica poderia acidentalmente entregar um diário particular ou uma conta bancária se você pedir da maneira certa. É aqui que os pesquisadores de segurança entram, tentando descobrir como enganar a máquina para revelar seus segredos sem realmente destruir a cidade.

O artigo que você está prestes a ler apresenta um novo detetive digital chamado GraphQLer. Pense na maioria dos scanners de segurança como turistas desajeitados que se aproximam da máquina de vendas, apertam um botão aleatório e veem o que acontece. Se apertarem "Refrigerante" e receberem um refrigerante, eles seguem em frente. Se apertarem "Água" e receberem um erro, eles desistem. Eles nunca percebem que, para conseguir o "Estoque Secreto", primeiro você tem que apertar "Comprar Refrigerante", depois "Pegar Recibo" e, então, apertar "Estoque Secreto". As ferramentas antigas são burras demais para conectar os pontos; elas testam cada botão isoladamente e perdem as sequências complexas necessárias para quebrar o sistema.

O GraphQLer é diferente. É como um detetive que primeiro estuda as plantas da máquina (o "schema") para entender como os botões estão conectados. Ele constrói um mapa mental mostrando que o "Botão A" cria um novo item, o "Botão B" deleta um item e o "Botão C" ainda pode ser capaz de ver um item mesmo depois que ele foi removido. Com esse mapa, o GraphQLer não apenas aperta botões aleatoriamente; ele cria cadeias específicas de ações. Ele simula um cenário onde um usuário compra um item, depois tenta roubá-lo, ou o deleta e depois tenta lê-lo novamente.

Os pesquisadores testaram este novo detetive em 21 APIs reais e falsas, porém realistas (os sistemas de computador sendo testados). Eles descobriram que o GraphQLer foi uma melhoria massiva em relação às ferramentas antigas. Enquanto as melhores ferramentas existentes conseguiam alcançar apenas cerca de 29% dos botões da máquina, o GraphQLer conseguiu alcançar 85,52% deles. Mais importante ainda, quando se tratava de encontrar problemas de segurança complexos, as ferramentas antigas encontraram zero dos problemas de múltiplos passos. O GraphQLer, no entanto, encontrou todas as cinco vulnerabilidades "IDOR" confirmadas (onde você pode ver as coisas de outra pessoa apenas mudando um número) e até detectou um erro de "Use-After-Free" (onde você pode ver um arquivo após ele ter sido deletado).

Em um teste do mundo real em um sistema financeiro (que os autores chamam de "FinServ" para manter o anonimato), o GraphQLer encontrou oito potenciais falhas de segurança sem precisar de senhas ou documentos secretos. Ele até encontrou maneiras de fazer o sistema travar e revelar seu código interno, o que é um grande erro de segurança. O artigo também mostrou que o GraphQLer pode reproduzir vulnerabilidades conhecidas em uma plataforma de código aberto popular chamada Saleor, provando que ele funciona em sistemas que já são conhecidos por estarem quebrados.

Os autores são muito cuidadosos ao dizer que, embora sua ferramenta seja excelente para encontrar esses tipos específicos de erros de reação em cadeia, ela não é uma varinha mágica que resolve tudo. Ela ainda tem dificuldades com alguns cenários muito específicos e complexos onde a máquina exige várias informações ao mesmo tempo para funcionar. Mas para a vasta maioria dos aplicativos modernos que usam essa tecnologia flexível do GraphQL, o GraphQLer prova que você não pode mais testar botões um por um. Você tem que entender a história que a máquina está contando e, só então, poderá encontrar onde estão os furos no roteiro.

Resumo Técnico: GraphQLer

Declaração do Problema

As APIs GraphQL tornaram-se dominantes em sistemas de produção devido ao seu design baseado em esquemas e endpoint único. No entanto, esta arquitetura introduz desafios de segurança únicos, ausentes em APIs REST. Diferente do REST, onde os verbos HTTP e as estruturas de URL codificam a intenção, o GraphQL expõe todas as operações através de um único endpoint sem controle de acesso integrado.

O artigo identifica que vulnerabilidades críticas de controle de acesso — especificamente Referência Direta Insegura a Objetos (IDOR), Uso de Memória Após Liberação (Use-After-Free - UAF) e injeção dependente de estado — escapam rotineiramente de testes de segurança automatizados. Scanners padrão da indústria (ex: ZAP) e fuzzers de pesquisa (ex: EvoMaster) testam operações isoladamente. Eles falham em modelar a estrutura de dependência estatal do GraphQL, onde uma mutação pode depender silenciosamente de recursos criados por operações anteriores. Consequentemente, vulnerabilidades que exigem sequências de múltipl de etapas (ex: criar um recurso como Usuário A, depois acessar esse recurso como Usuário B) são invisíveis para ferramentas que não conseguem compor cadeias de operações.

Metodologia

Os autores apresentam o GraphQLer, um framework de teste de segurança automatizado de código aberto projetado para tratar cadeias de vulnerabilidade (sequências ordenadas de operações) como construtos de primeira classe. O framework opera em duas fases principais:

1. Fase de Compilação

O GraphQLer analisa o esquema vivo via introspecção para construir um grafo de dependência tipado.

Anotação de Ação: Ele infere a semântica da mutação (CREATE, UPDATE, DELETE ou UNKNOWN) analisando nomes e descrições. Casos ambíguos podem ser resolvidos via um resolver opcional baseado em LLM.
Inferência de Dependência: Como o GraphQL não expõe explicitamente as dependências de entrada de forma legível por máquina, o GraphQLer infere arestas correspondendo campos de entrada do tipo ID a tipos de objetos usando derivação de padrões de nome e pontuação de distância de Levenshtein.
Construção do Grafo: O sistema cria nós para queries, mutações e tipos de objetos, vinculando-os através de arestas direcionadas que representam dependências rígidas (não anuláveis) e suaves (anuláveis).

2. Fase de Teste

A fase de teste percorre o grafo de dependência usando uma estratégia de três passagens (CREATE/Queries $\rightarrow$ UPDATE $\rightarrow$ DELETE) e materializa payloads.

Materialização de Payload: Ele gera payloads minimamente e maximamente válidos, além de payloads fuzados (injetando SQLi, XSS, comando OS, etc.). Ele mantém um balde de objetos (objects bucket) para armazenar recursos retornados (IDs, estado) para reutilização em operações subsequentes.
Estratégias de Cadeia de Vulnerabilidade: O GraphQLer emprega três estratégias especializadas para sintetizar sequências de ataque específicas:
1. Estratégia de Cadeia Topológica: Utiliza a condensação de Componentes Fortemente Conectados (SCC) para lidar com grafos cíclicos, garantindo uma ordem de execução válida para alcance geral.
2. Estratégia de Cadeia IDOR: Pega cadeias regulares e as reproduz com uma credencial de "usuário primário" para a etapa de CREATE e uma credencial de "usuário secundário" (não privilegiado) para as etapas subsequentes. Uma vulnerabilidade é sinalizada se o usuário secundário acessar um recurso que não deveria.
3. Estratégia de Cadeia UAF: Sintetiza cadeias onde um recurso é criado, deletado e depois lido. Ele busca por quadruplas $(c, o, d, r)$ onde $c$ é CREATE, $d$ é DELETE e $r$ é READ. Se a etapa de READ retornar dados após o DELETE, uma vulnerabilidade de UAF é detectada.

O framework também suporta assinaturas baseadas em WebSocket e expõe seu pipeline como um servidor de Protocolo de Contexto de Modelo (MCP) para fluxos de trabalho assistidos por IA.

Principais Contribuições

Cadeias de Vulnerabilidade: A introdução de sequências ordenadas de operações GraphQL como um construto primário de teste, especificamente projetado para detectar vulnerabilidades de múltiplas etapas perdidas por ferramentas de operação única.
Três Estratégias Especializadas: Implementação de travessia topológica de SCC, replay de IDOR entre usuários e síntese de aresta de grafo de UAF para cobrir superfícies de ataque críticas.
Ferramenta GraphQLer: Uma implementação de código aberto apresentando um grafo de dependência, um conjunto de injeção cobrindo nove categorias de vulnerabilidade, um resolvedor de dependência assistido por LLM e um motor de perfil de multi-autenticação.
Avaliação Abrangente: Avaliação em 21 APIs, incluindo APIs públicas, APIs de plataformas de produção, aplicações com vulnerabilidades conhecidas (Saleor, DVGA) e APIs de verdade fundamental (ground-truth) criadas para o propósito.

Resultados

A avaliação demonstra que o GraphQLer supera significativamente as ferramentas existentes tanto em cobertura quanto em detecção de vulnerabilidades:

Cobertura de Operação: Em 11 APIs públicas, o GraphQLer alcançou uma Cobertura Positiva média de 85,52%, comparado a 29,29% para o EvoMaster e 21,80% para o ZAP.
Detecção de Verdade Fundamental (Ground-Truth):
- IDOR: Detectou todos os 5 endpoints de IDOR confirmados em uma API criada para o propósito.
- UAF: Detectou comportamento de UAF na VVSM-API e incidentalmente na IDOR-API.
- Injeção: Confirmou SQLi, XSS e injeção de comando OS em APIs criadas para o propósito e validou de forma independente XSS e SQLi na aplicação de terceiros DVGA.
- Comparação de Linha de Base: Todas as ferramentas de linha de base (ZAP, EvoMaster, Schemathesis, GraphQL-Cop) detectaram zero vulnerabilidades baseadas em cadeia (IDOR ou UAF).
Aplicação no Mundo Real: Em uma API financeira de produção (FinServ), o GraphQLer identificou oito vulnerabilidades potenciais, incluindo vetores de negação de serviço expondo stack traces, sem documentação prévia ou credenciais. Em uma instância da Saleor vinculada ao CVE-2022-39275, ele reproduziu todas as quatro mutações de quebra de controle de acesso citadas no aviso de segurança.

Significância e Alegações

O artigo alega que o GraphQLer aborda uma lacuna estrutural no teste de segurança automatizado: a incapacidade das ferramentas existentes de modelar dependências de estado e múltiplas etapas no GraphQL. Ao sintetizar cadeias de vulnerabilidade, o GraphQLer expõe falhas que são invisíveis para fuzzers de operação única.

Os autores posicionam o GraphQLer não apenas como um scanner, mas como uma ferramenta para triagem industrial e coleta de evidências, capaz de operar de maneira totalmente black-box para identificar vetores de alto risco em sistemas de produção. O trabalho destaca que, embora ferramentas de operação única possam verificar a conformidade do esquema, elas são arquitetonicamente incapazes de detectar vulnerabilidades que dependem da sequência e do estado das operações. O lançamento das APIs de verdade fundamental (IDOR-API, Injection-API, VVSM-API) tem como objetivo fornecer os primeiros benchmarks rotulados para a detecção de vulnerabilidades de cadeia baseadas em GraphQL.

O artigo permanece modesto quanto às limitações, reconhecendo que certas precondições complexas (ex: autenticação de múltiplos campos para injeção) e problemas de materialização de escalares ainda podem levar a falsos negativos, e que a validação externa independente de IDOR/UAF em aplicações de terceiros em larga escala permanece como um trabalho futuro.