Organizations that (justifiably) move from REST APIs to more powerful and flexible GraphQL APIs should be aware: future attackers are watching. Your GraphQL APIs are a bounty that can pay off a treasure trove of sensitive data (or provide other opportunities for bad actors to exploit your services for their monetary gain).

For these reasons, some attackers want nothing more than to find and exploit your GraphQL APIs, and will deploy quite sophisticated methods of subtle nudging and prodding to reveal information.

However, by learning to recognize the telltale signs of these methods, DevSecOps teams can flip the script on attackers so that the hunter becomes the hunted and attacks are blocked as soon as they make their presence known.

Attackers can be impressively inventive in passively gathering valuable intelligence before they even risk sending packets to your application. Examining your organization’s GitHub page and public repositories can provide insight into the technologies you rely on and other information that begins to guide an attack strategy. If credentials are inadvertently left hard-coded in these repositories, clever attackers can find and exploit these small jackpots.

Attackers will also actively test the waters by sending GraphQL queries to your application and seeing what is returned. If your application processes client requests at a high scale—and if your DevSecOps team isn’t equipped to sift through all that traffic effectively—then the abnormal behavior associated with probing by attackers will likely go unnoticed.

Requests tell attackers what they’re dealing with

GraphQL exists largely as a superior replacement technology that addresses and eliminates the cumbersome issues of working with REST APIs. With REST, clients express intent by combining an HTTP method (with GET/PUT/POST/DELETE requests) and the resource path. As an example, a GET request to the path /v1/users can collect a complete list of the application’s users.

In contrast, GraphQL’s innovative declarative query language allows clients to express an intent with a single endpoint (such as /graphql) and a query. For example, this simple query collects the same full list of users:

users {

name

Email

}

Sending requests allows attackers to determine whether the application relies on GraphQL or another API technology. By querying endpoints where GraphQL might be located (even with invalid queries), attackers elicit server responses that can confirm its presence.

For example, a cURL request sent with the intent to search for a GraphQL endpoint might look like:

$ curl -d ‘{“query”:”query { users { name email } }”}’ -H “Content-Type: application/json”

The following JSON represents a typical GraphQL response, complete with a telltale GraphQL validation failure message:

{“errors”:[{“message”:”Cannot query field ”users” on type ”Query”.”,”extensions”:{“code”:”GRAPHQL_VALIDATION_FAILED”}}]}

Attackers know that likely GraphQL endpoint locations include: /graphql, /query, /api, /playground, /console, and /graphiql. API versions will also place GraphQL in these paths: /v1/graphql, /v2/graphql, /v1/query, /v2/query, /v1/console, and /v2/console. Using this knowledge, attackers can automate the above method to query GraphQL on multiple endpoints at once, starting with the most common locations.

While DevSecOps teams can customize GraphQL servers to point to any locations of their choosing rather than the usual predictable list, GraphQL API responses themselves remain predictable in nature. The the official GraphQL specification requires that GraphQL query responses must be maps, and that the response map must contain a record of any key errors that occurred. The response map must similarly include a key data record if the request involves execution, and may include a key extension record. In this way, GraphQL responses contain data keys, errors, and extensions for attackers to predict with automated scanning tools – giving them useful clues when finding GraphQL API locations.

Hunting the hunters

Automated attacker tools may be effective at probing endpoints with queries, but the query behavior itself is anomalous and a telltale sign of malicious actors. Inevitably, this attack method produces some invalid requests that result in server exceptions. By using tools to detect these poorly structured requests and their mass traffic directed at both existing and non-existing endpoints, DevSecOps teams can ultimately recognize, block and mitigate attacks before exploits occur.

This way, teams can implement GraphQL security layers that effectively detect attackers’ efforts and beat them at their own game.

DevSecOps Must Turn the Tables on GraphQL API Attackers

Previous articleData analytics and artificial intelligence, key industrial strategic missions for labor
Next articleOrange Beach police are warning of scam calls made by individuals