Reflected XSS Vulnerability in time.php

CVE-2021-41139.

Reflected XSS vulnerability in time.php existed in Time Tracker versions below 1.19.30.5600. When a logged on user selects a date in Time Tracker, it is being passed on via the date parameter in URI. Because of not checking this parameter for sanity in versions prior to 1.19.30.5600, it was possible to craft the URI with malicious JavaScript, use social engineering to convince logged on user to click on such link, and have the attacker-supplied JavaScript to be executed in user's browser.

Patches

Affected versions: Time Tracker 1.19.30.5599 and prior. Patched in version 1.19.30.5600.

Workarounds

Upgrade is recommended. If it is not practical, introduce ttValidDbDateFormatDate function as in the latest version and add a call to it within the access checks block in time.php.

ttValidDbDateFormatDate function code at the time of this writing:

// ttValidDbDateFormatDate is used to check user input to validate a date in DB_DATEFORMAT.
function ttValidDbDateFormatDate($val)
{
  $val = trim($val);
  if (strlen($val) == 0)
    return false;

  // This should validate a string in format 'YYYY-MM-DD'.
  if (!preg_match('/^\d\d\d\d-\d\d-\d\d$/', $val))
    return false;

  return true;
}

Here is how a call to ttValidDbDateFormatDate looks in access checks section for time.php.

// Access checks.
...
// If we are passed in a date, make sure it is in correct format.
$date = $request->getParameter('date');
if ($date && !ttValidDbDateFormatDate($date)) {
  header('Location: access_denied.php');
  exit();
}
...
// End of access checks.

If you need help with upgrading or migrating your system you can order paid support. We can also host Time Tracker for your organization on our servers. If you have any questions feel free to contact us.