FirstBlood-#682 — Stored XSS through DOB
This issue was discovered on FirstBlood v2
On 2021-10-27, eliee reported:
It is possible to achieve stored XSS on the DrPanel through the DOB displayed in
Today's Missed Appointmentswhen clicking on the patient's name. This lets the attacker steal the cookies of the logged in doctor as they aren't marked
Steps to reproduce
As there is no way to "miss" an appointment at the moment, this requires database access for now, but
dobis vulnerable to storing the information when booking an appointment.
- Set the
Sean zseano(id 56910419, state 1) to
<img/onerror='alert(document.cookie)'/src=x><< this should contain & lt; & gt; instead of angle brackets but seems they are replaced. Either way, the input emulates how DOB is normally encoded when signing up.
- Log in to the drpanel and click on
Sean zseanoin the
Today's Missed Appointmentssection
- An alert should display your current cookies
It is possible to set the DOB to the payload when registering. Simply intercept the request to
/ba.phpand change the value of
<img/onerror='alert(document.cookie)'/src=x>and it will end up as
& lt;img/onerror='alert(document.cookie)'/src=x& gt;(spaces added by me) in the db. Cookies are accessible as they aren't marked
Cookie still valid after logout
Even if logging out, the logged in session won't be made invalid until the doctor signs in again at
/login.php. This is testable by copying the
drpscookie value from the alert, clicking
Securely log outand then entering
document.cookie = "drps=cookievalue;"into the console before visiting
It is possible to break out of the tooltip tag and use dangling markup etc as well (though stealing the
drpscookie would be the main goal of an attacker).
Stored XSS executing on the admin part of the webpage which lets an attacker steal the cookies of the logged in doctor. The stolen cookie won't be invalidated until the doctor performs a new login - just logging out does not invalidate the session!
As DOB is user controlled input, it should be properly sanitized before being used on any webpage.
drpscookie should be marked
FirstBlood ID: 41
Vulnerability Type: Stored XSS
Not fully working: Whilst it isn't possible to achieve Stored XSS without having access to the database (from SQL or RCE), when an appointment is "missed" with the "state=1", the date of birth is not protected from XSS. We ran out of time to finish building appointment handling so it doesn't count towards unique finds, but this was an intended feature we planned to build so it was interesting to see someone discovered it!