hunt-fintech-graphql

⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a 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.

Porta de confirmação obrigatória 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, IP, conta ou recurso exato do alvo.
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 apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Por que o GraphQL de Fintech é uma Classe de Risco Diferente

Bugs genéricos de GraphQL (IDOR, atribuição em massa, introspecção, abuso de batching — veja hunt-graphql) ainda se aplicam aqui, mas o raio de explosão muda completamente: um bug de resolver em um aplicativo SaaS vaza dados, a mesma classe de bug em uma mutação de ledger move dinheiro. Três propriedades tornam os backends de GraphQL de fintech uma superfície de caça distinta:

• Mutations de movimentação de dinheiro são quase sempre resolvers sobre um ledger de partida dobrada. Uma única mutação GraphQL (transferFunds, redeemRewards, withdrawToBank) pode acionar múltiplas escritas no ledger (débito + crédito + taxa) que devem ser atômicas. A forma de entrada flexível do GraphQL e o batching de aliases facilitam a dessincronização dessas escritas.
• Decimais são entrada controlada pelo atacante, não formatação de exibição. Valores, taxas de câmbio, juros e pontos de recompensa são geralmente passados como escalares GraphQL (Float, String, escalares Decimal/Money personalizados). Como o resolver analisa e arredonda esse valor é uma superfície explorável por si só — isso mal existe em APIs GraphQL não financeiras.
• Campos KYC/PII ficam ao lado de campos de conta rotineiros no mesmo tipo. Tipos como User ou Account comumente expõem ssnLast4, routingNumber, kycStatus, governmentIdUrl ou linkedBankAccount ao lado de displayName e email — uma verificação de autorização em nível de campo ausente em um tipo usado em todos os lugares no esquema se espalha para todas as consultas que o tocam.

Sinais de Superfície de Ataque

Padrões de nomenclatura de URL / esquema (além da lista genérica de /graphql de hunt-graphql):

/graphql/ledger
/graphql/payments
/api/wallet/graphql
/internal/ledger-graphql
/banking/graphql

Nomes de campo/tipo que valem a pena buscar na introspecção do esquema ou em bundles JS:

balance, availableBalance, pendingBalance, ledgerEntry, ledgerEntries
transferFunds, withdraw, redeem, topUp, reverseTransaction, adjustBalance
kycStatus, ssnLast4, routingNumber, accountNumber, governmentIdUrl
quoteExchangeRate, interestAccrued, rewardsPoints, portfolioValue
idempotencyKey, clientMutationId

Indicações de stack de tecnologia específicas para esta vertical:

• Plaid/Stripe/Dwolla/Marqeta encapsulados por um gateway GraphQL interno (mutations bankLink, plaidLinkToken)
• Apollo Federation com um subgraph ledger ou payments dedicado — verifique se a introspecção do próprio subgraph é alcançável diretamente, contornando o esquema "costurado" do gateway
• Escalares GraphQL personalizados Money/Decimal/BigDecimal no esquema (scalar Money) — o parser para este escalar vale a pena ser fuzzado diretamente

Execute a metodologia de descoberta + introspecção de hunt-graphql primeiro para obter o esquema; tudo abaixo assume que você já tem (ou enumerou parcialmente) um esquema com tipos de movimentação de dinheiro.

Metodologia de Caça Passo a Passo

1. Mapeie todas as mutations que tocam o saldo, seja direta ou como efeito colateral. Não apenas transfer*/withdraw* — também redeemRewards, applyCoupon, upgradeTier, closeAccount (geralmente reembolsa um saldo), disputeTransaction (geralmente credita provisoriamente).

2. Para cada mutation de movimentação de dinheiro, identifique a forma de escrita no ledger. Uma mutation chama produz uma entrada no ledger ou várias (débito do remetente, crédito do receptor, entrada de taxa)? Escritas de múltiplas entradas são as que valem a pena correr — veja Estágio 4.

3. Teste o manuseio da chave de idempotência. Envie a mesma mutation (mesmo idempotencyKey / clientMutationId) duas vezes, uma após a outra e com um atraso. Uma escrita no ledger na segunda chamada significa que a idempotência não é aplicada no lado do servidor — replay = execução dupla.

…