Read Part 1 on GraphQL here.
In last week’s blog we learnt about the basics of GraphQL and how to configure a GraphQL server. We also discussed some key differences between GraphQL and REST API.
Here’s a brief recap:
GraphQL is an open source query language for APIs that helps to load data from a server to the client in a much simpler way. Comparing multiple aspects of both GraphQL and REST API, we have seen that GraphQL operations are superior to that of REST API. Although the benefits of this open source language is plenty, it comes with security vulnerabilities that developers tend to encounter from time to time.
Picking up from there, in the second part, we will discuss:
- GraphQL: Common misconfigurations that enable hackers
- Testing common misconfigurations in GraphQL
GraphQL: Common misconfigurations that enable hackers
GraphQL is one of the most efficient and flexible alternatives to REST API. However, it is vulnerable to the same attacks that REST API is prone to.
GraphQL depends on API developers to implement its schema for data validation. During this process they could inadvertently introduce errors. In addition to this, new features and functionalities, which meet client requirements, are added to web applications by the hour. This also increases the chance of developers committing errors.
Here we highlight some of the common misconfigurations and issues with GraphQL, that allow hackers to exploit it.
-
Improper Access Control or Authorization Checks
The limitations of the user authentication process can potentially grant unauthorized access to anyone. In the event that the authentication process is defective, the web application fails to restrict access to an object or resource which leads to delivering the data of another user without performing authorization checks. The flawed method allows attackers to bypass the intended access restriction, exposing user data to abuse, deletion, or alteration.
Let’s consider the scenario where a user, with the numeric object ID: 5002, wants to retrieve his/her PII such as email ID, password, name, mobile number, etc. If this user knowingly or unknowingly uses a different user ID (say, 5005), and this ID belongs to another active user, but the search leaks his/ her data, it shows that the GraphQL resolver allows unauthorized access.
The following query consists of a user ID representing a logged in user and fetches the user’s PII:
query userData {
users(id: 5002) {
name
email
id
password
mobileNumber
authorizationKey
bankAccountNumber
cvvNumber
}
}
However, if the same authenticated user is able to fetch the data of ID 5005, that means there is improper access control to an object or resource. It enables hackers/ attackers to access the data of multiple users. It also allows an attacker to perform malicious activities like editing the user’s data, deleting the user from the database, etc.
-
Rate Limit Issue and Nested GraphQL queries leading DoS attack
In a single query, it is capable of taking multiple actions in response to multiple HTTP requests. This feature increases the complexity of GraphQL APIs, which makes it difficult for API developers to limit the number of HTTP requests. If the request is not properly handled by the resolver at the GraphQL API layer then it opens a door for actors to attack the API and to perform denial-of-service (DoS) attacks.
To avoid this, only a specific number of requests per minute should be allowed to the API, and in case the number of requests exceeds the limit, it should trigger an error or reject the response.
Let’s look at the following example of such nested queries:
query nestedQuery {
allUsers {
posts {
follower {
author {
posts {
follower {
author {
posts {
follower {
author {
posts {
id
}
}
}
}
}
}
}
}
}
}
}
}
-
Default introspection system reveals internal information
Some API endpoints enable server-to-server communications and are not meant for the general public. And yet, GraphQL’s feature of introspection makes this possible without much difficulty.
Assume the instance where someone sends a query against an internal endpoint only to gain access to admin credentials and thereby obtain Admin Privilege.
Here is an example of a single endpoint which has the potential to allow attackers to access hidden API calls from the backend.
There are several websites such as https://apis.guru/graphql-voyager/ that display the entire list of API calls available at the backend. This provides a better understanding of the its interface and also demonstrates ways to gather sensitive information from the server.
We have covered a few of the misconfigurations here, but there could be many others. Also, it is vulnerable to all bugs that affect any other API.
Testing common misconfigurations in GraphQL
Here we’ll be exploring two ways to test these common misconfigurations, further exploited to gain access to sensitive data or information:
- Burp Suite – Advance intercepting proxy tool
- Altair GraphQL – GraphQL interface available as software, extension for OS and browser.
Testing GraphQL misconfigurations with Burp Suite
Burp Suite is a popular pentesting framework that works as a great proxy tool to intercept and visualize requests. Assuming that readers are already aware of how to configure it, we’ll be focusing on testing alone.
- This is what a normal HTTP request in GraphQL looks like:
- Modify the POST query per your requirements and send it to the server.
- If it is misconfigured, it will fetch sensitive/ internal data.
- However, if you find it difficult to visualize or modify the query, you can use a Burp plugin called “GraphQL” to achieve the same results.
But the major drawback of testing it in Burp Suite is the inadequate visualization of the entire schema documentation. This could result in several common misconfigurations being overlooked, unless we locate the proper documentation of API endpoints or calls implemented at the backend. Another issue related to using Burp is that we have to modify or debug the query manually which makes the process more complex. All these issues can be resolved with the help of the following method.
Debugging GraphQL with Altair GraphQL
Altair helps with debugging GraphQL queries and server implementations. It rectifies the problem of modifying the queries manually and instead helps to focus on other aspects.
Altair GraphQL is available as a software for Mac, Linux, and Windows OS and also as an extension for almost all browsers. It provides proper documentation of the entire schema that is available at the backend. All we need to do is configure the web application we are testing.
All three operations of GraphQL can be seen in the documentation section as shown above. You can further explore these options to get other fields, API endpoints, etc.
Altair is capable of solving one of the most challenging tasks in this process: Adding a query manually. It comes with the feature that enables automatic query generation. So, all we need to do is pass supported type values.
- Click on the ADD QUERY as shown above, to automatically add a query along with its arguments and fields.
- Now, provide the argument values to test for any bugs or misconfigurations.
Altair makes bug hunting on any web application quite easy. You can test GraphQL queries and server implementations easily, as Altair performs the complex part of the process and lets you focus on the results.
Conclusion
In comparison with REST API, GraphQL offers developers improved standards of API development. And yet, it has its own security misconfigurations that can be exploited relatively easily. However, it is capable of bridging the gaps created by REST API. Alternatively, REST can help address the drawbacks of GraphQL as well. They need not be referred to as two incompatible technologies. Moreover, we believe these technologies can coexist with each other.