FirstBlood-#238 — Stored XSS on /manageappointment.php using the message parameter leading to account takeover
This issue was discovered on FirstBlood v1
On 2021-05-14, holybugx reported:
I found out that there is a stored XSS on the
/manageappointment.phpendpoint on the vulnerable
messageparameter, 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.htmlendpoint, 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.phpendpoint and enter the appointment id that you got from the previous step.
- Intercept the request to
"Modify Appointment"and make the following changes:
act=cancelas a parameter is key in this attack.
- Edit the
messageparameter 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.phpendpoint 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.phpURL endpoint that is injected with the attacker's XSS payload:
An attacker can use the following payload on the
messageparameter to steal the victim's cookie and use his
drpscookie to take over his account, the payload is:
http://attacker.comis 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=cancelparameter results in filtering/sanitization on the special characters such as
- After adding the
act=cancelparameter 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
messageparameter when the appointments are going to be canceled.
- Preferably set
- Account takeover of various users/admins
FirstBlood ID: 9
Vulnerability Type: Stored XSS
When cancelling an appointment, an attacker can add a malicious XSS payload that will execute on manageappointment. Any user (non authed) can view this and will be affected.