FirstBlood-#418 — Email of an appointment could be modified if cookie doctorAuthed is present
This issue was discovered on FirstBlood v2

On 2021-10-25, panya Level 7 reported:

The site allows modifying only an appointment message on https://579a3c7897af-panya.a.firstbloodhackers.com/manageappointment.php?aptid=<apptid> page.

But if we add doctorAuthed cookie with any value, an attacker could modify a user's email too.

Steps to reproduce:

  1. Make an appointment (e575ffcd-db10-40c5-a79c-97de287de2c0 id in our case).
  2. Modify the appointment via a request like this: 
    curl -X POST 'https://579a3c7897af-panya.a.firstbloodhackers.com/api/ma.php?success&aptid=e575ffcd-db10-40c5-a79c-97de287de2c0' -H 'csrf: 99215d4e-0ff3-4275' -H 'Cookie: doctorAuthed=1' -d 'message=test&id=e575ffcd-db10-40c5-a79c-97de287de2c0&[email protected]'
  3. Visit the appointment URL: https://579a3c7897af-panya.a.firstbloodhackers.com/manageappointment.php?success&aptid=e575ffcd-db10-40c5-a79c-97de287de2c0

Actual result:

The email of the appointment's user will be changed to [email protected].

Expected result:

There should be proper validation of the given parameters in the /api/ma.php endpoint. Modification of an email should not be allowed, even with the doctorAuthed cookie.

P3 Medium

Endpoint: /api/ma.php

Parameter: email

Payload: [email protected]

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.