org.sonar.l10n.py.rules.python.S6785.html Maven / Gradle / Ivy
GraphQL servers are vulnerable to Denial of Service attacks when they fail to limit the depth of queries. In such a case, an attacker is able to
craft complex, deeply nested queries to make the application unwillingly consume an important amount of resources.
Why is this an issue?
When a server receives a deeply nested query, it attempts to resolve all the requested data. This process can consume a substantial amount of
computational resources, leading to a slowdown in server response times.
What is the potential impact?
A server that faces a resource exhaustion situation can become unstable. The exact impact will depend on how the affected application is deployed
and how well the hosting server configuration is hardened.
In the worst case, when the application is deployed in an uncontained environment, directly on its host system, the memory exhaustion will affect
the whole hosting server. The server’s operating system might start killing arbitrary memory-intensive processes, including the main application or
other sensitive ones. This will result in a general operating failure, also known as a Denial of Service (DoS).
In cases where the application is deployed in a virtualized or otherwise contained environment, or where resource usage limits are in place, the
consequences are limited to the vulnerable application only. In that case, other processes and applications hosted on the same server may keep on
running without perturbation. The vulnerable application will still stop working properly.
In general, that kind of DoS attack can have severe financial consequences. They are particularly important when the affected systems are
business-critical.
How to fix it
Code examples
Noncompliant code example
from graphql_server.flask import GraphQLView
app.add_url_rule("/api",
view_func=GraphQLView.as_view( # Noncompliant
name="api",
schema=schema,
)
)
Compliant solution
from graphql_server.flask import GraphQLView
from graphene.validation import depth_limit_validator
app.add_url_rule("/api",
view_func=GraphQLView.as_view(
name="api",
schema=schema,
validation_rules=[
depth_limit_validator(10) # Choose a value that fits your application's requirements
]
)
)
How does this work?
Avoid circular references
A prerequisite for deeply nested query to be executed is the presence of circular references in the database schema. Avoid or minimize circular
references when designing the application’s database schema.
Set limits
Limit the depth of the queries your server will accept. By setting a maximum depth, you can ensure that excessively nested queries are rejected.
Remember, the values for maximum depth and complexity should be set according to your application’s specific needs. Setting these limits too low could
restrict legitimate queries, while setting them too high could leave your server vulnerable to attacks.
The easiest way to set such a limit is to use the query validation API available from Graphene 3. Applications running Graphene 2 should consider
upgrading to Graphene 3 to benefit from this API.
Resources
Standards
- OWASP - Top 10 2021 Category A4 - Insecure Design
- OWASP - Top 10 2021 Category A5 - Security Misconfiguration
- OWASP - Top 10 2017 Category A6 - Security
Misconfiguration
- CWE - CWE-707 - Allocation of Resources Without Limits or Throttling
- STIG Viewer - Application Security and
Development: V-222667 - Protections against DoS attacks must be implemented.