BugBountyHunter

Hi zseano

Summary

This is my first bug on FirstBlood hackevent. This is a P2 information leak of users. This is also an IDOR since I can cancel and modify the details of appointments of every other user.

Appointment process flow

When a user wants an appointment he must go to http://firstbloodhackers.com/book-appointment.html, fill in his personal information like Firstname, Lastname, Address, Phone Number etc. and click on the submit button. Then, you will be given an appointment ID which must be remembered by the user.

You can modify your appointment on http://firstbloodhackers.com:49198/manageappointment.php?success&aptid={{appointment_id_here}}.

Attack scenario

But, I came to know that there is another parameter 'id' whose value when used in the place of appointment_id which is kept safely by the user(patient). And these values start with 5691 and has 8 digits.

So, if we bruteforce here for those remaining 4 digits after 5691 on the endpoint /api/qa.php in a POST request we get the response /manageappointment.php?success&aptid={{appointment_id}} which leaks the appointment id of the user(patient).

Using this appointment_id, I am able to cancel the user's appointment and modify the user's appointment.

Steps to reproduce

• Bruteforce values in a POST request on /api/qa.php on the parameter 'id' starting with 5691. So the id value becomes 5691****. By the way, I'm not sure if every id value starts with 5691 since I created not more than 10 accounts. If it is not the case, an attacker can bruteforce all the digits as there is no rate limit. (I've not done that so as to not put load on the server).
• For successful id values, you can observe the appointment_id in the response.
• Using those appointment_ids, a malicious attacker can get access to users' P2 information, able to cancel the appointment and able to modify the appointment.

Initially, I didn't know the value of sticking with the target. But it helped me a lot. I kept looking for things and observed that there are two parameters pointing to the same thing(appointment). Then I just changed one parameter with the other and found that the endpoint is leaking the actual value needed for changing other's appointment details using that parameter(aptid).

Thanks zseano for this amazing application which teaches things and bugs easily. Please let me know if you need any more information regarding this bug.

Note : I've added attachments for your reference