FirstBlood-#866The endpoint MA.php (to modify an appointment) only allows for certain values to be modified, however due to some application logic error, if the user has tried to signup as a doctor and has the cookie "doctorAuthed" set, then it allows them to modify the email address for any appointment.
This issue was discovered on FirstBlood v2



On 2021-10-29, vishal Level 2 reported:

Description:The endpoint MA.php (to modify an appointment) only allows for certain values to be modified, however due to some application logic error, if the user has tried to signup as a doctor and has the cookie "doctorAuthed" set, then it allows them to modify the email address for any appointment.

Note: By default neither admin doctor , doctor nor patients are allowed to change email once appointment is made but this logic failed to implement properly for doctors.

steps to Reproduce:

1.Create a doctor account you will get doctor's cookies. (go to reference)

  1. visit /book-appointment.php fill all the details and submit.
  2. you will get appointment id note is down.
  3. Now visit /yourappointments.php and submit appointment id from the last step.
  4. without making any change click on modify appointment and capture the req is proxy.
  5. Send to captured request to repeater and add parameter email=anythingnewmail & send the request you will get success msg.I had set it to abcd in below screenshot which was a originally. 7.Now repeat step 4 you will notice that now email have been changed successfully.

Update : I have just realized that drps cookie is not just doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9; is enough to make changes which is nothing but the base64 encrypted version of {"doctorAuth":authed}

Reference:

https://www.bugbountyhunter.com/hackevents/report?id=536 (TO know how i got doctor cookie's)

Impact: Business Logic /Application Logic has failed to implement properly.

Lastly let me know if anything missing or further information required Thanks and Regards - Vishal

P3 Medium

Endpoint: /api/ma.php

Parameter: email

Payload: anything


FirstBlood ID: 33
Vulnerability Type: Application/Business Logic

Our mistake: We did not intentionally leave the code to change emails if the correct values were set, however it created interesting results because most discovered this but missed bug ID 20 and 21 and whilst it was not possible to modify via integer, if the ID was known it would still work.