Skip to content

Latest commit

 

History

History
62 lines (51 loc) · 7.85 KB

attack-surface.md

File metadata and controls

62 lines (51 loc) · 7.85 KB

Attack Surface Analysis for 99designs/gqlgen

Attack Surface: Overly Permissive Schema

  • Description: A GraphQL schema that exposes more data and operations than necessary, granting attackers access to sensitive information or functionalities.
  • gqlgen Contribution: gqlgen directly translates the schema definition into the API. If the schema is poorly designed and overly permissive, gqlgen will generate code that reflects this vulnerability. gqlgen itself doesn't enforce schema restrictions beyond syntax correctness.
  • Example: A schema exposes a User type with fields like internalUserId, passwordHash, and a mutation promoteUserToAdmin intended only for internal use, but accessible through the public GraphQL API.
  • Impact: Unauthorized access to sensitive data, privilege escalation, data manipulation, and potential system compromise.
  • Risk Severity: High to Critical
  • Mitigation Strategies:
    • Principle of Least Privilege: Design the schema to expose only the data and operations absolutely necessary for the intended clients.
    • Schema Reviews: Conduct thorough security reviews of the GraphQL schema to identify and remove overly permissive fields and mutations.
    • Field-Level Authorization: Implement authorization checks at the field level in resolvers to control access based on user roles and permissions, even if the field is present in the schema.

Attack Surface: Lack of Input Validation in Schema and Resolvers

  • Description: Insufficient validation of input data provided through GraphQL queries and mutations, leading to potential injection vulnerabilities or unexpected application behavior.
  • gqlgen Contribution: gqlgen generates code based on the schema's input types. If the schema doesn't define validation rules (e.g., through custom scalars with validation), and resolvers don't implement robust input validation, vulnerabilities arise. gqlgen's code generation itself doesn't automatically add input validation.
  • Example: A mutation takes a username string without length limits or character restrictions. An attacker sends a username containing SQL injection payloads or excessively long strings, potentially causing database errors or data breaches.
  • Impact: SQL injection, NoSQL injection, command injection, cross-site scripting (XSS), denial of service, and data corruption.
  • Risk Severity: High to Critical
  • Mitigation Strategies:
    • Schema-Level Validation (Custom Scalars): Define custom scalars in the schema with built-in validation logic for input types (e.g., using regular expressions, length constraints).
    • Resolver-Level Validation: Implement explicit input validation within resolvers before processing data or interacting with backend systems. Use validation libraries to enforce rules.
    • Input Sanitization/Encoding: Sanitize or encode user inputs before using them in database queries, API calls, or rendering output to prevent injection attacks.

Attack Surface: Complex Query Attacks (GraphQL DoS)

  • Description: Attackers craft excessively complex GraphQL queries with deep nesting or numerous fields to overwhelm the server's resources, leading to denial of service.
  • gqlgen Contribution: gqlgen processes queries as defined by the schema. If the schema allows for complex queries and no complexity limits are enforced, gqlgen will execute these resource-intensive queries. gqlgen itself doesn't inherently prevent complex query attacks without explicit configuration.
  • Example: A query with deeply nested relationships (e.g., users { posts { comments { author { ... } } } }) or a query selecting a large number of fields across multiple types, causing excessive database queries and CPU usage.
  • Impact: Denial of service, application unavailability, performance degradation for legitimate users.
  • Risk Severity: High
  • Mitigation Strategies:
    • Query Complexity Analysis and Limits: Implement query complexity analysis (using libraries or custom logic) to calculate the cost of queries based on nesting depth, field selections, and other factors. Reject queries exceeding predefined complexity limits.
    • Query Depth Limiting: Restrict the maximum depth of GraphQL queries to prevent excessively nested requests.
    • Rate Limiting: Implement rate limiting on the GraphQL endpoint to restrict the number of requests from a single IP address or user within a given time frame.
    • Resource Monitoring and Throttling: Monitor server resource usage and implement throttling mechanisms to limit resource consumption by individual queries or users.

Attack Surface: Error Handling Revealing Sensitive Information

  • Description: Detailed error messages in GraphQL responses expose internal application details, potentially aiding attackers in reconnaissance and vulnerability exploitation.
  • gqlgen Contribution: gqlgen's default error handling might expose verbose error messages. While useful for development, these messages can be too detailed in production. gqlgen provides customization options for error handling, but developers need to configure it securely.
  • Example: A GraphQL query triggers a database error, and the error response includes the full database error message, stack trace, and internal file paths, revealing database schema details or code structure.
  • Impact: Information disclosure, aiding attackers in understanding the application's architecture and identifying potential vulnerabilities, potentially leading to further attacks.
  • Risk Severity: High
  • Mitigation Strategies:
    • Custom Error Handling: Implement custom error handling in gqlgen to provide generic, user-friendly error messages to clients in production.
    • Error Logging: Log detailed error information securely on the server-side for debugging and monitoring purposes, but avoid exposing these details in client-facing responses.
    • Disable Debug Mode in Production: Ensure that debug mode or development-specific error reporting is disabled in production environments.

Attack Surface: Schema Introspection Enabled in Production

  • Description: Leaving GraphQL schema introspection enabled in production environments allows attackers to easily discover the entire API structure, facilitating targeted attacks.
  • gqlgen Contribution: gqlgen and GraphQL by default enable schema introspection. While useful for development tools, it's a security risk in production if not explicitly disabled or controlled. gqlgen doesn't automatically disable introspection in production.
  • Example: An attacker uses introspection queries to retrieve the complete schema definition, including types, fields, arguments, and directives, gaining a comprehensive understanding of the API's capabilities and potential vulnerabilities.
  • Impact: Information disclosure, significantly aiding attackers in reconnaissance and planning targeted attacks, increasing the overall attack surface.
  • Risk Severity: High
  • Mitigation Strategies:
    • Disable Introspection in Production: Disable schema introspection in production environments to prevent unauthorized schema discovery. This is often a configuration setting in GraphQL server libraries or gateways.
    • Access Control for Introspection: If introspection is needed for specific purposes in production (e.g., monitoring), implement strict access control to restrict introspection queries to authorized users or services only.