CSRF risk factors are often hidden, and misunderstood, in GraphQL implementations
Endpoints using GraphQL may be at risk of exploitation due to failures to mitigate cross-site request forgery (CSRF) attack vectors, researchers warn.
On May 20, Doyensec researchers Tomasz Swiadek and Andrea Brancaleoni said that an examination of enterprise endpoints using GraphQL revealed that configuration issues in implementations might be exposing systems to unnecessary risks.
GraphQL is an open source query language for APIs. The developer tool has been designed to streamline queries by using data decoupling from a database via graphs, together with one endpoint, rather than pulling data from multiple sources.
CSRF is a class of attack caused by malicious web applications that force web browsers to perform actions on behalf of a user without their consent – as well as circumvent ‘same origin’ policies. This could include changing the settings of an online service account, changing passwords, or transferring funds.
According to Swiadek and Brancaleoni, there are two forms of GraphQL CSRF at hand that developers should be aware of.
The first is a POST-based CSRF. GraphQL endpoints usually accept Content-Type headers when they are set to application/json only, but when ‘middleware’ translates requests from other formats – such as query parameters, application/x-www-form-urlencoded, or multipart/form-data – and no CSRF protections are in place, this can provide an avenue for exploitation.
“GraphQL implementations are often affected by CSRF,” the researchers say. “Another incorrect assumption is that JSON cannot be created from urlencoded requests. The false sense of security works in the attacker’s favor, since it creates an attack surface which is easier to exploit.”
For example, a CSRF could be triggered, under the right conditions, if a valid GraphQL query is sent via POST and converted in Burp.
The other vulnerability of note is the possibility of GET-based CSRFs.
There are two common issues the cybersecurity firm has encountered which could be exploited to trigger this form of attack, the first being the accidental exposure of GraphiQL consoles, which are only intended for developer environments.
GraphiQL permits mutations in GET requests, so if exploited, the researchers say it can be abused to perform CSRF by forcing browsers to “issue arbitrary query or mutation requests”.
The second issue is also down to misconfiguration – namely, when state-changing GraphQL operations are misplaced in queries which are normally non-state changing.
Swiadek and Brancaleoni also say that in some cases, developers will choose to bypass available CSRF protections entirely, and this oversight can also create a wider attack surface.
Testing the attacks
During a limited, two-day test of “top” companies that utilize GraphQL and roughly 30 endpoints belonging to them, the duo discovered what they called an “impressive amount of unpatched vulnerabilities”.
In total, 14 were vulnerable to an XS-Search attack (GET-based CSRF), and three were vulnerable to some form of CSRF.
In XS-Search attacks leveraging a CSRF, in which a victim is forced to send a data request, response times measurements could also create additional data leaks – such as whether or not a specific file exists.
“The implications of a successful XS-Search attack on a GraphQL endpoint cannot be overstated,” the researchers note. “However, as previously mentioned, CSRF-based issues can be successfully mitigated with some effort.”
The Daily Swig has reached out to the GraphQL Foundation with additional queries and we will update when we hear back.
DON’T FORGET TO READ Nagios IT monitoring vulnerabilities chained to compromise telco customers en masse