FirstBlood-#731 — Posibility to modify email of any appointment via /api/ma.php endpoint if attacker know the appointment id
This issue was discovered on FirstBlood v2
On 2021-10-27, neolex Level 2 reported:
Getting started
Learn about vulnerability types 
Getting started in bug bounties 
Test your knowledge
Free Web Application Challenges
Guides for your hunts 
ZSeano's Methodology
Effective Note Taking for bug bounties
Useful Resources 
Disclosed HackerOne Reports 
Our community
Endorsed Members
Hackevents 
Member Articles
Description
It is possible for an attacker to modify the email of any appointment by using the https://792406c141d1-neolex.a.firstbloodhackers.com/api/ma.php endpoint
Step to reproduce
-
Go to https://792406c141d1-neolex.a.firstbloodhackers.com/manageappointment.php?success&aptid=da30e94c-c910-44ac-8b9e-aa7299a141d6
with replacing the id of appoitement by the one you want to modify
-
Click on "modify appointment" and intercept the request in burp or another proxy
-
append the email parameter with your email like
message=&id=da30e94c-c910-44ac-8b9e-aa7299a141d6&fname=neo&name=neo2&[email protected]
impact
it is possible for an attacker to modify any appointement email if they have the appointment id
P3 Medium
Endpoint: /api/ma.php
This report contains multiple vulnerabilities:
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.
FirstBlood ID: 21
Vulnerability Type: Insecure direct object reference
Not working correctly: The endpoint MA.php was fixed to prevent the use of integer values however whilst it does not require any type of authentication to view normally, it is still vulnerable to IDOR as long as the appointmentID is known. We intended to add another feature which would allow users to convert integer > encrypted ID and this was an over sight on our behalf. This bug doesn't count towards unique finds.