FirstBlood-#67Leak arbitrary users appointment details Manage/delete them
This issue was discovered on FirstBlood v1

On 2021-05-09, ibruteforce Level 4 reported:


My overall goal was to find a way to leak arbitrary user's appointments. Not really sure why it took so long but here it is.

Firstly, when you book an appointment at, you're given an ID which looks similar to this 99215d4e-0ff3-4275-aede-b3168428ec0a

Entering that ID over here: we can manage that particular appointment.

However, this ID is pretty long and it's pretty impossible to guess/bruteforce to sneak through other appointments. As of now, this looks pretty secure.

Logging into the doctor's panel, on the dashboard, when you click any of these new appointments, each of these makes a GET request to /drpanel/drapi/query.php?aptid=56910219

Looking at the GET request, we observe a parameter called aptid which sounds similar to the appointment ID.

Let's make a note of this parameter aptId which 56910219

Now, let's test this ID and see if this works on

Visit and enter 0-0 in the appointment field and intercept the request. We use 0-0 to bypass client side validation since if you look at the source code, it only makes a request if a '-' is included.

Now, edit the id parameter to 56910219 which we noted earlier and send the request.

We can now see that the request goes through and we get a response with the actual appointment ID.

Now to manage that appointment, copy the response text and paste it after your instance url like this.<YOUR RESPONSE TEXT> which should now look like

Now you can successfully edit/manage the appointment. So basically this ID 56910219 is much easier to bruteforce and increments with every appointment. But even better, looking through other appointment ID's, each appointment seems to be increment by 600. So all you need to do is increment each appointment id by 600 to manage the next appointment! :)

P2 High

Endpoint: /api/qa.php

Parameter: id

Payload: NA

FirstBlood ID: 5
Vulnerability Type: Insecure direct object reference

The endpoint QA.php (to query for an appointment) will allow for integer values to be used when querying for appointments. A bad cause of security through obscurity was attempted.