GraphQL Exploitation: Secondary Context Attacks and Business Logic

### Overview In this presentation, Will van dender, a senior staff security researcher at Sprocket Security, examines secondary context attacks within GraphQL architectures. Modern enterprise applications frequently employ the Backend-for-Frontend (BFF) design pattern, where an incoming client request to an external gateway or GraphQL server triggers a secondary internal request to underlying REST microservices. When user input from the primary GraphQL context is concatenated or embedded into backend requests without proper normalization or sanitization, attackers can leverage path traversal and other techniques to redirect requests to unauthorized internal endpoints. This talk covers the mechanics of secondary context vulnerabilities, real-world case studies demonstrating data exposure and SQL injection, discovery workflows, and strategies for both offensive testers and defensive teams.

### Key Topics - **Secondary Context Attacks in BFF Patterns**: Understanding the distinction between external client requests and the secondary requests executed internally between a GraphQL proxy and internal microservices. - **Authentication & Authorization Decoupling**: How authorization headers (such as JWTs or API keys) hard-coded or automatically appended at the BFF can be inadvertently inherited by an attacker targeting secondary endpoints. - **GraphQL Scaler Weaknesses**: Analysis of default GraphQL scalar types, focusing on how `String` and `ID` scalers accept arbitrary string inputs (such as path traversal payloads or SQL injection strings) without strict validation. - **Testing Methodology & Tooling**: Techniques for fingerprinting GraphQL instances, brute-forcing schema objects when introspection and suggestions are disabled, using custom Burp Montoya filters/B-Checks, and reviewing proxy history. - **Defense and Remediation**: Using secure-by-default custom scalers (e.g., the `graphql-scalars` package), enforcing backend input validation, and avoiding trust boundaries that rely on hard-coded proxy authentication.

### Technical Details Van dender illustrates secondary context attacks through two real-world enterprise assessments:

1. **Blind SQL Injection via Secondary Endpoint Routing**: On an external target with GraphQL introspection and field suggestions disabled, verbose error disclosures on validation failures revealed internal backend paths. By dictionary brute-forcing objects, an internal endpoint (`/api/v1/query`) accepting arbitrary SQL queries was uncovered, though it lacked direct external user input. Simultaneously, testing an input-accepting query (`contact`) demonstrated that user input was appended to backend URLs and accepted directory traversal (`../`). By supplying a crafted payload containing directory traversal sequences directed at `/api/v1/query` along with SQL injection syntax, van dender executed a blind timing-based SQL injection against the backend database.

2. **SSO Account Access & IDOR Stitching**: In a single sign-on enterprise application, queries retrieving account data (`getAccountByID`) appended user-supplied account IDs to an internal path like `/microservice/api/me/accounts/{id}`. Supplying traversal sequences confirmed that path normalization allowed breaking out of the `/me/` path scope. By chaining a separate GUID disclosure vulnerability with path traversal (`../../{target_user}/accounts/{id}`), the attacker accessed arbitrary private user data. The request inherited the BFF's internal authorization credentials, granting access that standard cross-user authorization controls should have denied.

From an assessment perspective, van dender highlights that `ID` scalers in GraphQL serialize as strings intended merely to denote non-human-readable identifiers, meaning they accept path traversal payloads like `../` or encoded variations (`..%2f`). Discovery can be automated or streamlined using Burp Suite Montoya HTTP filters (BOMbata scripts) to parse operation names into proxy columns or flag queries using `ID` or `String` scalers, as well as offline tools like van dender's `burp-parser-plugin`.

### Takeaways - **For Attackers / Pentesters**: Look for `ID` and `String` inputs in GraphQL queries and mutations. Test unexpected strings and path traversal sequences (`../`, URL-encoded variants) to identify 404, 400, or 503 error reflections indicating internal routing control. Secondary context traversal can often be chained with SSRF (via open redirects), IDORs, or SQL injection. - **For Developers & Defenders**: Do not assume GraphQL scalar types provide type safety against malicious formats; `ID` and `String` fields require rigorous input validation or URL encoding (`encodeURIComponent`) before passing into downstream HTTP requests. Organizations should adopt strict, secure-by-default libraries such as `graphql-scalars` to enforce dedicated types (e.g., `UUID`) at the GraphQL layer. Finally, avoid hard-coding blanket administrative authorization tokens at proxy layers, and monitor backend microservices for anomalous spikes in 404 and 400 status codes.