FirstBlood-#830 — Patients can still change their application email
This issue was discovered on FirstBlood v2

On 2021-10-29, 0x1452 Level 3 reported:

Hey!

Summary

In the previous version it was reported that patients were able to edit their email on applications if the doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9 cookie was present. This cookie is automatically set after trying to register, even if it fails.

This issue is still present and the UI still tells us that we're not supposed to be allowed to edit our email:

Steps to reproduce

  1. Try to register at /register.php (doesn't matter if it's valid or not). Alternatively, set the cookie doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9 manually.
  2. Book an appointment at /book-appointment.php
  3. Copy the appointment ID and submit it at /yourappointments.php
  4. Notice that the UI only lets you edit your message. Click on Modify Appointment.
  5. Repeat the request to /api/ma.php in a tool like Burp but add the parameter email=whatever to the body
  6. Repeat step 3 or directly navigate to /manageappointment.php?success&aptid=:aptid and notice that the email got changed to whatever

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.