Organizations who are (justifiably) moving from REST APIs to more powerful and flexible GraphQL APIs need to be aware: would-be attackers are watching. Your GraphQL APIs are a prize that could pay out a treasure trove of sensitive data (or serve up other opportunities for bad actors to take advantage of your services for their monetary gain).
For these reasons, some attackers want nothing more than to locate and exploit your GraphQL APIs, and will deploy rather sophisticated methods to subtly poke and prod for revealing 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 so that attacks are blocked as soon as they betray their presence.
Attackers can be impressively resourceful at passively collecting valuable reconnaissance before they even risk sending packets at your application. Browsing your organization’s GitHub page and public repositories can yield insights into the technologies you rely on, and other information that begins to home in on an attack strategy. If credentials are inadvertently left hard-coded in those repositories, clever attackers can find and exploit those small jackpots.
Attackers will also actively test the waters by sending GraphQL queries to your application and seeing what comes back. If your application is handling client requests at a high scale—and if your DevSecOps team isn’t equipped to sift through all that traffic efficiently—then anomalous behavior associated with attackers’ probing is likely to go unnoticed.
Queries tell attackers what they’re dealing with
GraphQL exists largely as a superior replacement technology that addresses and eliminates the cumbersome hassles 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 full list of an application’s users.
In contrast, GraphQL’s innovative declarative query language enables clients to express intent with a single endpoint (like /graphql) and a query. For example, this simple query collects the same full list of users:
users {
name
}
Sending queries allows attackers to determine if an application relies on GraphQL or some other API technology. By querying endpoints where GraphQL may reside (even with invalid queries), attackers invoke server responses that can confirm its presence.
For example, a cURL request sent with the intention of probing for a GraphQL endpoint could resemble:
$ curl https://example.inigo.io/graphql -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 the likely GraphQL endpoint locations include: /graphql, /query, /api, /playground, /console, and /graphiql. API versioning will also place GraphQL in these paths: /v1/graphql, /v2/graphql, /v1/query, /v2/query, /v1/console, and /v2/console. Leveraging this knowledge, attackers can automate the above method to seek out GraphQL at multiple endpoints at once, starting with the most common locations.
While DevSecOps teams can customize GraphQL servers to point to any locations of their choice rather than the usual predictable list, GraphQL API responses themselves remain predictable by their nature. The official GraphQL specification requires that GraphQL request responses must be maps, and that the response map has to contain an entry for any key errors raised. The response map must similarly include an entry with key data if the request included execution, and may include an entry with key extensions. Thus, GraphQL responses feature data, error, and extension keys for attackers to anticipate with automated scanning tools—giving them helpful clues in hunting down GraphQL API locations.
Hunting the hunters
Attackers’ automated tooling may be effective in probing endpoints with queries, but that query behavior itself is an anomalous and a telltale signal of malicious actors. Inevitably, this attack method produces some invalid queries that result in server exceptions. By employing tooling to detect those poorly-structured queries and their bulk traffic targeting both existing and non-existing endpoints, DevSecOps teams can ultimately recognize, block, and mitigate attacks before exploits can occur.
In this way, teams can implement GraphQL security layers that efficiently detect attackers’ efforts, and beat them at their own game.
