GraphQL Attack Surface

What Is an Attack Surface?

An attack surface refers to all potential entry points an attacker can exploit to compromise a system. GraphQL, like any system, has its own unique vulnerabilities based on its features and configuration. These entry points include queries, mutations, subscriptions, and various other elements of the GraphQL language and type system.

Imagine a building with multiple doors and windows. Each entry point is an opportunity for attackers to exploit vulnerabilities. Similarly, GraphQL’s extensive capabilities create opportunities for misconfigurations, improper validation, and exploitation.

---

Core Components of the GraphQL Language

#	Component	Description
1	Operation type	Type that defines the method of interaction with the server (query, mutation, or subscription)
2	Operation name	Arbitrary client-created label used to provide a unique name to an operation
3	Top-level field	Function that returns a single unit of information or object requested within an operation (may contain nested fields)
4	Argument (of a top-level field)	Parameter name used to send information to a field to tailor the behavior and results of that field
5	Value	Data related to an argument sent to a field
6	Field	Nested function that returns a single unit of information or object requested within an operation
7	Directive	Feature used to decorate fields to change their validation or execution behavior, altering a value returned by a GraphQL server
8	Argument (of a directive)	Parameter name used to send information to a field or object to tailor its behavior and results
9	Argument (of a field)	Parameter name used to send information to a field to tailor the behavior and results of the field

GraphQL queries consist of various components, each of which has security implications:

Operation Types:

• Query: Retrieve data.

• Mutation: Modify data, such as creating or updating records.

• Subscription: Facilitate real-time communication between clients and servers.

Example: Mutation Query

mutation {
  editPaste(id: 1, content: "My first mutation!") {
    paste {
       id
       title
       content
    }
  }
}

This mutation modifies the content of a specific paste while also fetching the updated data. The flexibility in mutation operations can be a source of business logic vulnerabilities.

1. Subscriptions: Subscriptions rely on WebSocket connections for real-time updates. While useful, they are prone to vulnerabilities such as Cross-Site WebSocket Hijacking (CSWSH) and Man-in-the-Middle (MITM) attacks if origin validation or encryption (via TLS) is absent.

Example: WebSocket Handshake Request:

GET /subscriptions HTTP/1.1
Host: 0.0.0.0:5013
Connection: Upgrade
Upgrade: websocket

Response:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

After the handshake, a subscription might look like this:

subscription {
  paste {
     id
     title
     content
  }
}

1. Fields and Arguments: Fields return specific data and may contain nested fields. Arguments customize queries and filter responses.

Example: Query with Arguments

query {
  users(id: 1) {
    id
    username
  }
}

Response:

{
  "data": {
    "users": [
      {
        "id": "1",
        "username": "admin"
      }
    ]
  }
}

Arguments, while powerful, can be abused for injection attacks if improperly validated.

1. Directives: Allow modifications to the query at runtime, enhancing flexibility but adding complexity.

2. Operation Names: Custom operation names are labels that help identify operations but can also be manipulated.

Example: Operation Names

query getPasteTitles {
  pastes {
    title
  }
}
query getPasteContent {
  pastes {
    content
  }
}

Malicious clients could use misleading operation names to disguise their true intent in logs.

---

Key Attack Vectors in GraphQL

1. Field Suggestions: When a field is misspelled, GraphQL servers often suggest corrections. This helpful feature can inadvertently expose undocumented fields.

Example: Error Message with Suggestions

"Cannot query field \"titl\" on type \"PasteObject\". Did you mean \"title\"?"

1. Nested Queries: GraphQL allows deep nesting, which can lead to recursive queries and potential server overload.

Example: Circular Field Relationships

{
  id
  title
  content
  owner {
    name
    posts {
      title
      author {
        name
      }
    }
  }
}

1. Argument Exploitation: Arguments are client-driven and can contain malicious inputs. For example, improperly validated inputs can lead to injection attacks.

Example: Argument Exploitation

query {
  users(id: "1; DROP TABLE users;") {
    id
    username
  }
}

---

Aliases

Aliases allow renaming fields in GraphQL queries, resolving conflicts when the same field is queried with different arguments. For example:

query {
  pastes {
    myalias: title
  }
}

Response:

{
  "data": {
    "pastes": [
      { "myalias": "My Title!" }
    ]
  }
}

Example of avoiding conflicts:

Without aliases:

query {
  pastes(public: false) {
    title
  }
  pastes(public: true) {
    title
  }
}

Error: Fields conflict due to differing arguments.

With aliases:

query {
  queryOne: pastes(public: false) {
    title
  }
  queryTwo: pastes(public: true) {
    title
  }
}

Response:

{
  "data": {
    "queryOne": [{ "title": "My Title!" }],
    "queryTwo": [{ "title": "Testing Testing" }]
  }
}

---

Fragments

Fragments allow reusable field sets for improved readability:

fragment CommonFields on PasteObject {
  title
  content
}

query {
  pastes {
    ...CommonFields
  }
}

Note:

Fragments can create circular dependencies, leading to DoS vulnerabilities.

---

Variables

Variables simplify runtime argument handling:

query publicPastes($status: Boolean!) {
  pastes(public: $status) {
    id
    title
    content
  }
}

Passing variables via JSON:

{
  "status": false
}

---

Directives

Directives modify field behavior dynamically. Common directives:

Name	Description	Location
@skip	Omits a field when the condition is true	Query
@include	Includes a field only when true	Query
@deprecated	Marks a field/type as deprecated	Schema
@specifiedBy	Specifies a scalar type via URL	Schema

Example:

query pasteDetails($pasteOnly: Boolean!) {
  pastes {
    id
    title
    content
    owner @skip(if: $pasteOnly) {
      name
    }
  }
}

Custom directives like @computed can enhance functionality, e.g., merging fields:

type User {
  firstName: String
  lastName: String
  fullName: String @computed(value: "$firstName $lastName")
}

---

Data Types

GraphQL supports six types: Object, Scalar, Enum, Union, Interface, and Input.

Objects

Custom types with specific fields:

type PasteObject {
  id: ID!
  title: String
  content: String
  public: Boolean
}

Scalars

Core scalar types include ID, Int, Float, String, Boolean. Custom scalars:

scalar DateTime

Enums

Allow specific values for fields:

enum UserSortEnum {
  ID
  EMAIL
  USERNAME
  DATE_JOINED
}

Example:

query {
  users(limit: 100, order: { sort: ID })
}

Unions

Return one of multiple object types:

union SearchResults = UserObject | PasteObject

Query:

query {
  search(keyword: "p") {
    ... on UserObject { username }
    ... on PasteObject { title content }
  }
}

Interfaces

Define common fields across types:

interface SearchItem {
  keywords: [String!]
}

type UserObject implements SearchItem {
  id: ID!
  username: String!
  keywords: [String!]
}

Inputs

Simplify passing complex arguments:

input UserInput {
  username: String!
  password: String!
  email: String!
}

Mutation example:

mutation newUser($input: UserInput!) {
  createUser(userData: $input) {
    user {
      username
    }
  }
}

JSON for variables:

{
  "input": {
    "username": "tom",
    "password": "secret",
    "email": "[e-mail]"
  }
}

Apologies for missing the source code earlier. Here's a revised version that includes all relevant queries and responses.

---

GraphQL Introspection

Introspection type	Usage
__Schema	Provides all information about the schema of a GraphQL service
__Type	Provides all information about a type
__TypeKind	Provides the different kinds of types (scalars, objects, interface, union, enum, and so on)
__Field	Provides all information for each field of an object or interface type
__InputValue	Provides field and directive argument information
__EnumValue	Provides one of the possible values of an enum
__Directive	Provides all information on both custom and built-in directives

1. Empowering Clients:

   • Introspection allows clients to discover schema information, including:

     • Queries

     • Mutations

     • Subscriptions

     • Types

     • Fields

     • Directives

   • Example query for listing all types:

     query {
       __schema {
         types {
           name
         }
       }
     }

     Response:

     {
       "data": {
         "__schema": {
           "types": [
             { "name": "PasteObject" },
             { "name": "ID" },
             { "name": "String" },
             { "name": "OwnerObject" },
             { "name": "UserObject" }
           ]
         }
       }
     }

2. Deep Dive into Custom Types:

   • Investigate specific types to uncover fields and relationships:

     query {
       __type(name: "PasteObject") {
         name
         kind
         fields {
           name
           type {
             name
             kind
           }
         }
       }
     }

     Response:

     {
       "__type": {
         "name": "PasteObject",
         "kind": "OBJECT",
         "fields": [
           { "name": "id", "type": { "name": null, "kind": "NON_NULL" } },
           { "name": "title", "type": { "name": "String", "kind": "SCALAR" } },
           { "name": "content", "type": { "name": "String", "kind": "SCALAR" } },
           { "name": "owner", "type": { "name": "OwnerObject", "kind": "OBJECT" } }
         ]
       }
     }

---

Validation and Execution

1. Validation Process:

   • GraphQL queries are checked against the schema for:

     • Field existence

     • Argument correctness

     • Directive support

2. GraphQL Threat Matrix:

• A framework for comparing GraphQL implementations based on:

  • Security maturity

  • Default configurations

  • Known vulnerabilities

1. Execution Stage:

   • Resolvers process valid queries, but weak implementations can lead to exploits.

---

Common Weaknesses with Examples

1. Denial of Service (DoS):

   • Complex queries can overwhelm servers if protections aren’t in place.

   • Example vectors include:

     • Deeply nested queries

     • Excessive aliasing

     • Recursive fragments

2. Information Disclosure:

   • Introspection queries expose sensitive schema details:

     • Hidden fields

     • Relationships

   • Mitigation: Disable introspection in production environments.

3. Authentication/Authorization Flaws:

   • Example exploits:

     • Using aliases or batch queries to bypass restrictions.

   • Security must be enforced in resolvers, not just in schemas.

4. Injection Attacks:

   • Unvalidated input via arguments or mutations can lead to:

     • SQL injection

     • Command injection

   • Example mutation prone to injection:

     mutation {
       updateUser(id: "1"; name: "Injected Payload") {
         success
       }
     }