offensive-graphql

Name: offensive-graphql
Author: SnailSploit

2.8kstars447forks

How to install offensive-graphql?

snailsploit/claude-red/offensive-graphql

$npx -y skills add SnailSploit/Claude-Red --skill offensive-graphql

Installs into the current project.

Summary

When this skill is active: 1. Load and apply the full methodology below as your operational checklist 2. Follow steps in order unless the user specifies otherwise 3. For each technique, consider applicability to the current target/context 4. Track which checklist items have been

Files · 1

View on GitHub

SKILL.md

1	# SKILL: GraphQL Vulnerabilities
2
3	## Metadata
4	- Skill Name: graphql-security
5	- Folder: offensive-graphql
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/graphql.md
7
8	## Description
9	GraphQL security testing checklist: introspection abuse, batching attacks, query depth/complexity DoS, field suggestion enumeration, IDOR via GraphQL, injection through arguments, authorization bypass. Use when assessing GraphQL endpoints in web app tests or bug bounty.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`GraphQL, introspection, batching attack, query depth, GraphQL injection, GraphQL IDOR, field suggestion, GraphQL auth bypass, GraphQL DoS, GraphQL security`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28	# GraphQL Vulnerabilities
29
30	## Shortcut
31
32	1. Identify GraphQL Endpoint: Look for common paths like `/graphql`, `/graphiql`, `/graphql.php`, `/graphql/console`. Check network requests in browser developer tools.
33	2. Introspection Query: Send an introspection query to fetch the schema. Tools like GraphiQL or Postman can help. `query={__schema{types{name}}}`
34	3. Analyze Schema: Look for sensitive types, fields, mutations, and subscriptions. Pay attention to authorization logic.
35	4. Test Queries/Mutations:
36	- Check for Information Disclosure (e.g., user data, configuration).
37	- Test for Authorization Bypass (IDOR, insufficient permission checks).
38	- Look for Injection (SQLi, NoSQLi, Command Injection) in input fields.
39	- Test for Denial of Service (complex/deeply nested queries, batching abuse).
40	- Explore Mutations for unintended state changes.
41	- Check Subscriptions for data leakage.
42	- Verify persisted/signed queries enforced in production; depth/complexity limits.
43	5. No Introspection? Try common field/type guessing (e.g., `user`, `admin`, `query`, `mutation`). Use tools like `clairvoyance` or `inql`.
44
45	## Mechanisms
46
47	- Over-Fetching: Clients can request excessive data, potentially leading to DoS or information disclosure if not properly limited.
48	- Under-Fetching/N+1 Problem: Primarily a performance issue—poorly designed resolvers make dozens of backend calls (N+1). While not a direct data‑exposure risk, extreme latency can create timing side‑channels an attacker could measure.
49	- Insecure Direct Object References (IDOR): Exposing internal IDs allows attackers to potentially access unauthorized data by guessing/enumerating IDs.
50	- Insufficient Authorization: Missing or flawed checks on types, fields, mutations, or subscriptions.
51	- Input Validation Issues: Failure to sanitize or validate user input can lead to injection attacks (SQLi, NoSQLi, XSS, SSRF) if resolvers interact with backend systems insecurely.
52	- Introspection Enabled in Production: Exposes the entire schema, simplifying reconnaissance for attackers.
53	- Batching Abuse: Sending multiple queries/mutations in a single request can overwhelm the server (DoS) or bypass rate limiting.
54	- Lack of Depth/Complexity Limiting: Allows excessively nested or complex queries, leading to DoS.
55	- Directive Flooding: Sending thousands of `@include`/`@skip` directives in a single query can exhaust parser and validation phases, triggering DoS (e.g., CVE‑2024‑47614 in async‑graphql).
56	- Incremental Delivery: `@defer`/`@stream` can multiply work and leak partial data; must be guarded by cost and auth checks on deferred subtrees.
57	- File Uploads: Implementations using `graphql-upload` or custom multipart handling can inherit classic upload bugs (path traversal, content-type trust, temp file exposure).
58	- Federation/Gateway: Cross-subgraph authorization gaps, entity resolver overfetching, and inconsistent role enforcement at the router vs. subgraphs.
59	- CSRF Considerations: If cookie‑based auth is used, enforce header + `Origin` validation; prefer Authorization header.
60	- WebSocket Security: GraphQL subscriptions over WebSocket often lack proper authorization on long-lived connections; auth tokens in connection params may not be re-validated after expiry.
61	- Field Suggestions: Error messages that suggest valid field names when invalid ones are queried can leak schema information even with introspection disabled.
62	- Relay Global IDs: Base64-encoded `Type:ID` patterns (e.g., `base64("User:123")`) are commonly used and can be decoded to reveal internal IDs.
63	- Apollo/Hasura Leaks: Production Apollo Server instances may leak schema via query extensions; Hasura permissions misconfiguration can expose direct DB access.
64	- Header Injection: `x-hasura-*` headers or custom auth headers may be trusted without validation, enabling privilege escalation.
65
66	## Hunt
67
68	### Preparation
69
70	- Identify the

People who liked this also viewed

6 picks

Type

offensive-graphql

2.8kstars447forks

View on GitHub

How to install offensive-graphql?

snailsploit/claude-red/offensive-graphql

$npx -y skills add SnailSploit/Claude-Red --skill offensive-graphql

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SKILL: GraphQL Vulnerabilities
2
3	## Metadata
4	- Skill Name: graphql-security
5	- Folder: offensive-graphql
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/graphql.md
7
8	## Description
9	GraphQL security testing checklist: introspection abuse, batching attacks, query depth/complexity DoS, field suggestion enumeration, IDOR via GraphQL, injection through arguments, authorization bypass. Use when assessing GraphQL endpoints in web app tests or bug bounty.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`GraphQL, introspection, batching attack, query depth, GraphQL injection, GraphQL IDOR, field suggestion, GraphQL auth bypass, GraphQL DoS, GraphQL security`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28	# GraphQL Vulnerabilities
29
30	## Shortcut
31
32	1. Identify GraphQL Endpoint: Look for common paths like `/graphql`, `/graphiql`, `/graphql.php`, `/graphql/console`. Check network requests in browser developer tools.
33	2. Introspection Query: Send an introspection query to fetch the schema. Tools like GraphiQL or Postman can help. `query={__schema{types{name}}}`
34	3. Analyze Schema: Look for sensitive types, fields, mutations, and subscriptions. Pay attention to authorization logic.
35	4. Test Queries/Mutations:
36	- Check for Information Disclosure (e.g., user data, configuration).
37	- Test for Authorization Bypass (IDOR, insufficient permission checks).
38	- Look for Injection (SQLi, NoSQLi, Command Injection) in input fields.
39	- Test for Denial of Service (complex/deeply nested queries, batching abuse).
40	- Explore Mutations for unintended state changes.
41	- Check Subscriptions for data leakage.
42	- Verify persisted/signed queries enforced in production; depth/complexity limits.
43	5. No Introspection? Try common field/type guessing (e.g., `user`, `admin`, `query`, `mutation`). Use tools like `clairvoyance` or `inql`.
44
45	## Mechanisms
46
47	- Over-Fetching: Clients can request excessive data, potentially leading to DoS or information disclosure if not properly limited.
48	- Under-Fetching/N+1 Problem: Primarily a performance issue—poorly designed resolvers make dozens of backend calls (N+1). While not a direct data‑exposure risk, extreme latency can create timing side‑channels an attacker could measure.
49	- Insecure Direct Object References (IDOR): Exposing internal IDs allows attackers to potentially access unauthorized data by guessing/enumerating IDs.
50	- Insufficient Authorization: Missing or flawed checks on types, fields, mutations, or subscriptions.
51	- Input Validation Issues: Failure to sanitize or validate user input can lead to injection attacks (SQLi, NoSQLi, XSS, SSRF) if resolvers interact with backend systems insecurely.
52	- Introspection Enabled in Production: Exposes the entire schema, simplifying reconnaissance for attackers.
53	- Batching Abuse: Sending multiple queries/mutations in a single request can overwhelm the server (DoS) or bypass rate limiting.
54	- Lack of Depth/Complexity Limiting: Allows excessively nested or complex queries, leading to DoS.
55	- Directive Flooding: Sending thousands of `@include`/`@skip` directives in a single query can exhaust parser and validation phases, triggering DoS (e.g., CVE‑2024‑47614 in async‑graphql).
56	- Incremental Delivery: `@defer`/`@stream` can multiply work and leak partial data; must be guarded by cost and auth checks on deferred subtrees.
57	- File Uploads: Implementations using `graphql-upload` or custom multipart handling can inherit classic upload bugs (path traversal, content-type trust, temp file exposure).
58	- Federation/Gateway: Cross-subgraph authorization gaps, entity resolver overfetching, and inconsistent role enforcement at the router vs. subgraphs.
59	- CSRF Considerations: If cookie‑based auth is used, enforce header + `Origin` validation; prefer Authorization header.
60	- WebSocket Security: GraphQL subscriptions over WebSocket often lack proper authorization on long-lived connections; auth tokens in connection params may not be re-validated after expiry.
61	- Field Suggestions: Error messages that suggest valid field names when invalid ones are queried can leak schema information even with introspection disabled.
62	- Relay Global IDs: Base64-encoded `Type:ID` patterns (e.g., `base64("User:123")`) are commonly used and can be decoded to reveal internal IDs.
63	- Apollo/Hasura Leaks: Production Apollo Server instances may leak schema via query extensions; Hasura permissions misconfiguration can expose direct DB access.
64	- Header Injection: `x-hasura-*` headers or custom auth headers may be trusted without validation, enabling privilege escalation.
65
66	## Hunt
67
68	### Preparation
69
70	- Identify the

People who liked this also viewed

6 picks

Type