# [Tokopedia] Site-Wide CSRF Through Graphql Request ## What is Cross Site Request Forgery ?
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

## What is Graph Query Language ?
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

## Proof of Concept
When visiting [https://m.tokopedia.com](https://m.tokopedia.com/), most of the request is using ```GraphQL``` endpoint in [https://gql.tokopedia.com](https://gql.tokopedia.com/).Here is the example request to add product to wishlist : ![example_request_add_wishlist.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1657865460909/zGEPwtH_J.png align="left")

When looking at the request in burpsuite, i notice something interesting.The request to ```GraphQL``` endpoint is not using an authentication key or token in the request header.Usually, ```GraphQL``` is more like ```API``` style that use authentication key to get data, but Tokopedia seems to implement the request to ```GraphQL``` endpoint using session and cookie as authentication.

Indeed, before make an actual request to get the data, it will check the authentication to ```GraphQL``` using this request : ![request_check_auth_graphql.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1657865584822/aoy80fBRm.png align="left")

I'm thinking if we can somehow perform a CSRF attack to the ```GraphQL``` endpoint.Then i try to modify request data in burpsuite.Several change that i made to the request : 1. Remove the ```Referer``` 2. Set ```Origin``` to ```null``` 3. Set ```content-type``` to ```text/plain``` 4. Append ```"="``` to the end of body request Appending ```"="``` to the end of the body request is to test if we can make a request of ```JSON``` data using post form in html and using enctype ```text/plain```.After modifying the request, test to send the request. (Example image below is request to change profile image) ![example_request_change_picture.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1657865595559/BnOdrrbT3.png align="left")

And it works !



We can then craft a simple html to make a CSRF attack (This POC use sample request of uploading a product to the store) : ```html

Site Wide CSRF GraphQL : Add Product to Target User

``` In above crafted html, is to make a CSRF request to add product to the store (by just modifying the ```etalase_id``` to id that the targeted store own).When a targeted user or store account visit webpage that hosting this crafted html and click the submit button (or we can make this auto submit using javascript), the CSRF request will be fired and a product is added to the targeted store without user consent.

## Impact
Seeing that request in [https://m.tokopedia.com](https://m.tokopedia.com/) mostly using ```GraphQL```, there is several impact from this security issue : 1. Change user account profile picture 2. Add, edit and delete product from the store 3. Add, edit and delete address from user account 4. Change profile picture, description, status, slogan of the store 5. Add, edit and delete send address of the store 6. Add, edit and delete store note 7. Stealing tokopedia wallet by adding attacker bank account to targeted user account 8. Perform anything about ```order``` action behalf of the user 9. etc That's all from my first blog post, see you again in my next blog post (hopefully).
Happy Bug Hunting ! ## Timeline
Timestamp Description
February 6th 2019 Report Submited
February 6th 2019 Report is valid and marked as high severity
March 25th 2019 Check the vulnerability is fixed and follow up to tokopedia team
March 25th 2019 Tokopedia confirm the bug has been fixed
May 27th 2019 Reward sent
July 15th 2019 Tokopedia Agree to Disclose The Bug