Credential probing via GraphQL stuffed queries: concerning OWASP API top ten's Unrestricted Access to Sensitive Business Flows

In the cyber defense of your organization’s API set, it is important to reckon that not all APIs are created equal. Some APIs, such as those involving authentication are obviously high value targets, and deserve paying more attention to their design and defense.

It is not uncommon, as part of the user sign-up workflow, to implement an API that checks if the userid is or is not already an existing user of the system.

An example implementation in GraphQL looks like the below:

The upper pane is the request, with POST body in GraphQL semantic, which is a query for checking if my social email is a registered user or not. The response is a JSON saying has never registered beforehand.

So after I gone through the new user registration process, if I run the same GraphQL API request again, you can see that the response JSON now shows a JSON with isExist equals to true:

Now the interesting question is, if we stuff more than one query into the request POST body, will the origin be so helpful as to answer all the queries?

In this particular GraphQL origin, the answer is yes. The origin didn’t check if the payload contains multiple malicious queries and answers them all, thus confirming my personal gmail is a registered user, while my personal hotmail is NOT.

This certainly violates OWASP API Top Ten’s Unrestricted Access to Sensitive Business Flows:

As well as the OWASP best practice on avoiding user account being guessable:

Would the usual tactic of WAF rate limiting be an effective countermeasure in this case? No, because though the stuffed queries can be thousands, the number of HTTPS POST request is just one.

Effective countermeasures in this case would involve multiple lines of defense:

  • WAF should block HTTP POST request with body size being unreasonably big, which is a sign of stuffed queries.
  • The origin should check if the number of queries inside the POST body being too many.
  • BotMan SDK to be adopted to allow Akamai Edge to detect if the request is from a real device or if the request is modified by a script or a bot.
  • API Security can be a radar screen, so that you are always in the know regarding what kind of traffic are hitting your API endpoints.