GraphQL is a data query language developed by Facebook and was released in 2015. GraphQL acts as an alternative to REST API. Rest APIs require the client to send multiple requests to different endpoints on the API to query data from the backend database. With graphQL you only need to send one request to query the backend. This is a lot simpler because you don’t have to send multiple requests to the API, a single request can be used to gather all the necessary information.
## GraphQL
As new technologies emerge so will new vulnerabilities. By **default** graphQL does **not** implement **authentication**, this is put on the developer to implement. This means by default graphQL allows anyone to query it, any sensitive information will be available to attackers unauthenticated.
When performing your directory brute force attacks make sure to add the following paths to check for graphQL instances.
* _/graphql_
* _/graphiql_
* _/graphql.php_
* _/graphql/console_
Once you find an open graphQL instance you need to know what queries it supports. This can be done by using the introspection system, more details can be found here: [**GraphQL: A query language for APIs.**
_It’s often useful to ask a GraphQL schema for information about what queries it supports. GraphQL allows us to do so…_graphql.org](https://graphql.org/learn/introspection/)
### Basic Enumeration
Graphql usually supports GET, POST \(x-www-form-urlencoded\) and POST\(json\).
#### query={\_\_schema{types{name,fields{name}}}}
With this query you will find the name of all the types being used:
With this query you can extract all the types, it's fields, and it's arguments \(and the type of the args\). This will be very useful to know how to query the database.
#### Errors
It's interesting to know if the **errors** are going to be **shown** as they will contribute with useful **information.**
In the introspection you can find **which object you can directly query for** \(because you cannot query an object just because it exists\). In the following image you can see that the "_queryType_" is called "_Query_" and that one of the fields of the "_Query_" object is "_flags_", which is also a type of object. Therefore you can query the flag object.
If these objects don't need any argument to search, could **retrieve all the information from them** just **asking** for the data you want. In this example from Internet you could extract the saved usernames and passwords:
However, in this example if you try to do so you get this **error**:
Looks like somehow it will search using the "_**uid**_" argument of type _**Int**_.
Anyway, we already knew that, in the [Basic Enumeration](graphql.md#basic-enumeration) section a query was purposed that was showing us all the needed information: `query={__schema{types{name,fields{name, args{name,description,type{name, kind, ofType{name, kind}}}}}}}`
If you read the image provided when I run that query you will see that "_**user**_" had the **arg** "_**uid**_" of type _Int_.
So, performing some light _**uid**_ bruteforce I found that in _**uid**=**1**_ a username and a password was retrieved:
`query={user(uid:1){user,password}}`
Note that I **discovered** that I could ask for the **parameters** "_**user**_" and "_**password**_" because if I try to look for something that doesn't exist \(`query={user(uid:1){noExists}}`\) I get this error:
And during the **enumeration phase** I discovered that the "_**dbuser**_" object had as fields "_**user**_" and "_**password**_.
#### Query string dump trick \(thanks to @BinaryShadow\_\)
If you can search by a string type, like: `query={theusers(description: ""){username,password}}` and you **search for an empty string** it will **dump all data**. \(_Note this example isn't related with the example of the tutorials, for this example suppose you can search using "**theusers**" by a String field called "**description**"_\).
GraphQL is a relatively new technology that is starting to gain some traction among startups and large corporations. Other than missing authentication by default graphQL endpoints can be vulnerable to other bugs such as IDOR.
For this example imagine a data base with **persons** identified by the email and the name and **movies** identified by the name and rating. A **person** can be **friend** with other **persons** and a person can **have movies**.
You can **search** persons **by** the **name** and get their emails:
```javascript
{
searchPerson(name: "John Doe") {
email
}
}
```
You can **search** persons **by** the **name** and get their **subscribed****films**:
```javascript
{
searchPerson(name: "John Doe") {
email
subscribedMovies {
edges {
node {
name
}
}
}
}
}
```
Note how its indicated to retrieve the `name` of the `subscribedMovies` of the person.
You can also **search several objects at the same time**. In this case, a search 2 movies is done:
In the **introspection** you can find the **declared****mutations**. In the following image the "_MutationType_" is called "_Mutation_" and the "_Mutation_" object contains the names of the mutations \(like "_addPerson_" in this case\):
For this example imagine a data base with **persons** identified by the email and the name and **movies** identified by the name and rating. A **person** can be **friend** with other **persons** and a person can **have movies**.
A mutation to **create new** movies inside the database can be like the following one \(in this example the mutation is called `addMovie`\):
```javascript
mutation {
addMovie(name: "Jumanji: The Next Level", rating: "6.8/10", releaseYear: 2019) {
movies {
name
rating
}
}
}
```
**Note how both the values and type of data are indicated in the query.**
There may also be also a **mutation** to **create****persons** \(called `addPerson` in this example\) with friends and files \(note that the friends and films have to exist before creating a person related to them\):
```javascript
mutation {
addPerson(name: "James Yoe", email: "jy@example.com", friends: [{name: "John Doe"}, {email: "jd@example.com"}], subscribedMovies: [{name: "Rocky"}, {name: "Interstellar"}, {name: "Harry Potter and the Sorcerer's Stone"}]) {
This information was take from [https://lab.wallarm.com/graphql-batching-attack/](https://lab.wallarm.com/graphql-batching-attack/).
Authentication through GraphQL API with **simultaneously sending many queries with different credentials** to check it. It’s a classic brute force attack, but now it’s possible to send more than one login/password pair per HTTP request because of the GraphQL batching feature. This approach would trick external rate monitoring applications into thinking all is well and there is no brute-forcing bot trying to guess passwords.
Below you can find the simplest demonstration of an application authentication request, with **3 different email/passwords pairs at a time**. Obviously it’s possible to send thousands in a single request in the same way:
As we can see from the response screenshot, the first and the third requests returned _null_ and reflected the corresponding information in the _error_ section. The **second mutation had the correct authentication** data and the response has the correct authentication session token.
