Blog of a Security Engineer - ko2sec

Mostly wirte-ups and research documents.

6k$ Worth Account Takeover via IDOR in Starbucks Singapore

Posted at — Oct 7, 2020


While browsing Starbucks Singapore, I noticed a page loaded with content from a 3rd party site. Let’s call this site in order not to disclose it. When I did some research on this site, I saw the same login page on in the directory, and at this point I had two possibilities.

  1. This application can be an environment where current developments of are made and tested.
  2. Or it may have been used as an old test environment and is in an idle state.

Both possibilities increased the probability of a bug here, but the main problem is that I did not know whether a bug I will find here would affect the production environment. To understand this, I created a user account at and tried to log into with this account. BINGO! I was able to successfully login with the account I just created. Both applications seemed to be using the same authentication mechanism.

Scheme-1, both applications are using same database table.


From this point I browsed and discovered an endpoint which does not exist in the production app. The POST data this endpoint received was as follows.

When I write the email address of the account I want to takeover in the email parameter here and send a request, I saw the partial information of the account belonging to that email address on my profile page. I could not fully takeover the account yet, and my password change request was not successful due to the invalid CSRF token generated in this application.

To get around this, I copied the PHPSESSID cookie value from to and BOOM! I was able to see all the information belongs to victim in the production environment, the valid CSRF tokens generated here allowed me to change the password and I was able to completely takeover an account whose e-mail address I know.


Except for seeing all personal information belonging to users and completely taking over the accounts, if there is a loaded credit in the user account, these credits can be spent in Starbucks stores via the mobile application.

Multiplying the Reward

I came across two other test environments on Let’s call them and With my account at, I was not able to login to either test environment. did not allow me to create a new account, so I tried my luck at and successfully created a new account. Things get a little complicated here, I will try to explain it as simply as possible.

I think the applications and were using test tables, so users in production could not login in these applications.

With the account I created at, I was able to log in to, but not However, the PHPSESSID I copied from was valid on and I could use that account. Considering all the scenarios, I created a chain here as follows:

  1. Create a dummy account with the victim’s email address at (Add to testusers table.)
  2. At, associate the account for that email with your own account via the same endpoint. (Associate the PHPSESSID with the email in the testusers table.)
  3. Copy the PHPSESSID to and takeover. (Takeover the real account of the same email address in the production users table.)

Scheme-2, relations between applicaitons and tables.

May 17th - Report Submitted
May 18th - Triaged
May 20th - Rewarded $4000 bounty
Jun 17th - Rewarded $2000 bounty as 1.5x multiplier