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:
act=cancel as a parameter is key in this attack.
- Edit the
message parameter with the payload below, and send the request:
- So here is the full changes you have to do (there is no need to change your
/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:
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:
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
This happens because of two cookies misconfiguration:
Cookies are not set as
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=/
- 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.
- 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.
- Proper sanitization on the
message parameter when the appointments are going to be canceled.
- Preferably set
- Account takeover of various users/admins