Graphql Exploitation – Part 2- Unauthorized Execution of Queries
In part1 , we understood the basic of graphql that we need to know before we exploit it nicely. In this part, we will try to exploit the Graphql to execute unauthorized operations. We can test unauthorized execution if we come to know the operations in the schema.
The noticing point in graphql is that it doesn’t have something that checks directly for the authorization before execution of graphql operations on an object. So suppose, if a query needs a variable “id” and it fetches details belonging to that ID number then we can try random ID numbers to get details of other IDs. Oh Yes, an IDOR. Let’s understand this with an example:
The “query_question” is a query type that takes an “id” value and provides the question details. For the id=7014, it provides the general question assign to user “A”.
But if we change the “id” variable value, we will get the question assigned to some other user.
Note, the id variable is needed from graphql client/frontend and the backend didn’t even bother to check if the requested query is authorised or not.
This can itself lead to different kinds of vulnerabilities depending upon the data sent in response. Let suppose a case where instead of the “query_question” query operation we try to fetch sensitive user information using different query operations (if the operation exists in the schema). We can exfiltrate data very easily by just analysing the available schema and converting them to queries to get what we want. Yes, if there is no query operation in the schema that can generate this type of vulnerability then we just have to decide if the fetched data could be count as sensitive and considered unauthorised or not.
Let see another example, where there is an “auth” query operation that fetches an authentication token for a veterinarian.
In the above example, we have seen unauthorised fetching of some useful information. But if this can happen with a query type of operation then think of mutations. We can also try the unauthorised execution of mutations assigned in the schema.
Let’s try to exploit a mutation, assuming we get a mutation type operation to reset the password of a user. let say the mutation name is “register_user”.
Although using this operation someone can register an account but it is also overwriting the password of existing users associated with an “id”.
The exploitation of exposed mutations can be extensively harmful as we will get the ability to directly modify or insert values in the database/data source. Moreover, many other business logic attacks can be done like payment transaction status modifications etc., depending upon the nature of the application and exposed mutations.
How to stop it?
Although Graphql doesn’t have its feature to validate authorization if the query is primary coming from the client-side and without authorization check (by backend language/framework ) directly executing, we can stop this type of attacks.
Use of middleware
Almost all application framework can set up a middleware for the API route of graphql endpoint that will check the authorization of token going in the header. the middleware will reject any request which is not meant to be executed without proper authorization.
Use of non-variable queries in the schema and asking backend for object mapping
If we can’t control critical variables then we can’t fetch or modify data unless a query is meant to fetch data without variable. In many cases, we have found that graphql web IDE is exposed, and schema is also exposed but the implementation of queries are such that they don’t take any controllable value from the client side. Instead, it takes the values from the authorization token going in the header. For example,
In the above image, the schema is showing a mutation named “MyFriendlyLawyer”. But this mutation is not expecting any variable from the frontend. So if we try to execute it, it will directly show an error that the authorization token is missing, because this mutation is made to work on a user but to know which user, it is expecting details from the backend session manager to map out the user.
Note that the non-variable queries don’t mean that they can’t be executed. So it is better to try executing them and check whether they do some operations at their end or not.
References
About Payatu
Payatu is a Research Focused, CERT-In impaneled Cybersecurity Consulting company specializing in security assessments of IoT product ecosystem, Web application & Network with a proven track record of securing applications and infrastructure for customers across 20+ countries.
Get in touch with us. Click on the get started button below.
