Lessons Learned from Gitlab’s GraphQL API Vulnerability

At the beginning of March, Rapid7 disclosed a vulnerability in Gitlab’s GraphQL API (CVE-2021-4191) showing several common mistakes in the GraphQL API design, which exposed usernames, names, and email addresses to unauthenticated attackers. This information may seem trivial, but as outlined in the disclosure, it is the first step in several brute force attacks like password guessing, password spraying, and credential stuffing. The now-patched vulnerability affected GitLab versions since 13.0.

On GraphQL, there is only one endpoint, which allows querying the different exposed objects. On most systems, it’s hundreds and thousands of different object types. In some cases, a basic authentication is being used, covering the whole endpoint; however, in cases that an advanced access mechanism is being used, it is harder to distinguish between object types that need authentication and those that don’t as well as which of these objects are possibly exposing sensitive information.

In the case of GitLab, the GraphQL API exposed the User object type without any sort of authentication. This allowed the listing of the GitLab usernames, names, email addresses, and even possibly photos. Some organizations might consider the mentioned information even more sensitive than others, as this can expose the company’s R&D employees and internal mail addresses.

These types of API vulnerabilities are more common than you might suspect, and aren’t detectable using traditional tools like API gateways or WAFs. Solutions like the Noname API Security Platform automatically detects GraphQL object types, identifies which objects don’t have authentication, and finds PII and other sensitive personal information — allowing you to easily find the more sensitive APIs that are more likely to be problematic.

Enterprises need to actively check which objects don’t need authentication and then validate the behavior of the API (trust but verify), ensuring that the API doesn’t output sensitive information. And if you have more than one role on your system, it is important to check which object types are exposing which data to which role.

If you are an enterprise in need of greater API posture management, runtime API security, and “shift left” API security testing, please request a demo from Noname Security to learn how to proactively address API vulnerabilities at your organization.