Denial of Service (DoS) assaults in GraphQL APIs are nothing new. It seems that whenever you let shoppers management what knowledge they need to obtain from the server, malicious customers attempt to abuse this flexibility to exhaust sources. Who might have guessed it?
However after we discuss stopping DoS in GraphQL, we’re often discussing easy methods to deal with advanced queries with deeply nested or round relationships and even about stopping batching assaults, but it surely’s not usually that alias and directives are talked about as potential vectors.
GraphQL’s alias characteristic permits a consumer to carry out the identical operation a number of instances in the identical HTTP request, which is usually not attainable, by attributing a reputation (or alias) to every “result”.
From the docs:
Directives, alternatively, are a option to conditionally embody or exclude fields, fragments, and even top-level operations.
Once more, from the docs:
So, a GraphQL server will allow you to carry out the identical question a number of instances in a single request when you assign a distinct identify to every of them, and it may also will let you use the identical directive a number of instances in a single question, multiplying the outcomes.
You possibly can see how these options could also be helpful to an attacker when searching for methods to carry out a DoS assault.
Instruments like graphQL-cop make testing these situations a lot simpler:
Observe that the –proxy choice sends the requests via 127.0.0.1:8080 which lets us additional examine them.
As you possibly can see under, within the highlighted question, the instrument tries to request the identical subject (__typename) with 100 totally different aliases:
Though the instrument marked this API as weak to “Alias Overloading” because the request is profitable, word that there could also be optimizations in place that really resolve all of those separate queries as a single one – a sluggish profitable response must be a greater indicator that DoS could also be attainable.
On this explicit API, we will see that there’s a distinction of solely 2 milliseconds between utilizing 10 aliases or 100 aliases, which implies that the server might be not performing separate operations for every alias when fetching this particular subject:
The instrument additionally exams “Directive Overloading” by making an attempt to ship the identical directive a number of instances in the identical question which, within the instance proven under, produces an error:
If the outcomes are multiplied, then it could point out that the server is weak. Nonetheless, a sluggish response with multiplied outcomes is a extra correct indicator.
If you happen to’re nervous about defending your GraphQL API, it is best to perceive how your explicit GraphQL server handles these options. The excellent news is that if you have already got measures in place to guard towards different vectors of DoS, they may most likely be efficient towards the sort of assault as properly.
Nicely-known strategies, comparable to question complexity evaluation, complexity-based price limiting, or implementing timeouts to “kill” queries that take too lengthy to resolve may be extremely efficient. Furthermore, you possibly can preserve an inventory of pre-approved operations that the server can execute, which prevents malicious customers from constructing “custom” weak queries.
