FirstBlood-#67 — Leak arbitrary users appointment details Manage/delete them
This issue was discovered on FirstBlood v1
On 2021-05-09, ibruteforce Level 4 reported:
Hi,
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 http://firstbloodhackers.com:49234/book-appointment.html
, you're given an ID which looks similar to this 99215d4e-0ff3-4275-aede-b3168428ec0a
Entering that ID over here: http://firstbloodhackers.com:49234/yourappointments.php
. 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 http://firstbloodhackers.com:49234/yourappointments.php
Visit http://firstbloodhackers.com:49234/yourappointments.php 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.
http://firstbloodhackers.com:49234/<YOUR RESPONSE TEXT>
which should now look like
http://firstbloodhackers.com:49234/manageappointment.php?success&aptid=99215d4e-0ff3-4275-aede-b3168428ec0a
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.