Skip to content

HtmlGenerator vulnerable to XSS

Moderate
jgniecki published GHSA-q898-frwq-f3qp Oct 3, 2024

Package

composer dev-lancer/minecraft-motd-parser (Composer)

Affected versions

<= 1.0.5

Patched versions

1.0.6

Description

Summary

The HtmlGenerator class is subject to potential cross-site scripting (XSS) attack through a parsed malformed Minecraft server MOTD.

Context

Minecraft server owners can set a so-called MOTD (Message of the Day) for their server that appears next to the server icon and below the server name on the multiplayer server list of a player's Minecraft client. The Minecraft server sends the MOTD in the description property of the Status Response packet. The jgniecki/MinecraftMotdParser PHP library is able to parse the value of the description property, which can be either a string or an array of text components. By utilizing the aforementioned HtmlGenerator class, it is also able to transform the value into an HTML string that can be used to visualize the MOTD on a web page.

Details

The HtmlGenerator iterates through objects of MotdItem that are contained in an object of MotdItemCollection to generate a HTML string. An attacker can make malicious inputs to the color and text properties of MotdItem to inject own HTML into a web page during web page generation. For example by sending a malicious MOTD from a Minecraft server under their control that was queried and passed to the HtmlGenerator.

This XSS vulnerability exists because the values of these properties are neither filtered nor escaped, as can be seen here:

Proof of Concept

JavaScript code can be injected into the HtmlGenerator by parsing either a string via TextParser or an array via ArrayParser. The following code examples demonstrate the vulnerability by triggering the alert dialog of the browser.

XSS via TextParser

<?php

use DevLancer\MinecraftMotdParser\Collection\MotdItemCollection;
use DevLancer\MinecraftMotdParser\Generator\HtmlGenerator;
use DevLancer\MinecraftMotdParser\Parser\TextParser;

$motdCollection = (new TextParser())->parse('<script>alert("XSS on page load")</script>', new MotdItemCollection());

echo (new HtmlGenerator())->generate($motdCollection);

XSS via ArrayParser

<?php

use DevLancer\MinecraftMotdParser\Collection\MotdItemCollection;
use DevLancer\MinecraftMotdParser\Generator\HtmlGenerator;
use DevLancer\MinecraftMotdParser\Parser\ArrayParser;

$motdCollection = (new ArrayParser())->parse([
    [
        'color' => '#" onmouseover="javascript:alert(\'XSS when mouse pointer enters the span element\')"',
        'text' => 'Hover me',
    ],
    [
        'color' => '#000000',
        'text' => '<script>alert("XSS on page load")</script>',
    ]
], new MotdItemCollection());

echo (new HtmlGenerator())->generate($motdCollection);

Impact

If the HtmlGenerator class of this library is used, this XSS vulnerability can potentially affect:

  • Players visiting Minecraft server list websites (of which there are several dozen online, written in PHP) that display the MOTD.
  • Users visiting Minecraft server status websites to query information about a Minecraft server.
  • Server owners managing their Minecraft server via a web interface that displays the MOTD, where the attack could be carried out by a malicious Minecraft server plugin that modifies the MOTD without the server owner's consent.

It is not clear if and which platforms depend on this library.

Remediation

I suggest converting all HTML special characters in the values of the color and text properties to HTML entities. The display of the HTML entities will still be correct in the browser, but the XSS vulnerability will be eliminated as the values will no longer be interpreted as HTML by the browser.

This could be achieved by introducing a new private escape function in the HtmlGenerator class:

private function escape(string $text): string
{
    return htmlentities($text, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}

This function should be called in the following two lines:

Disclosure Policy

The Krymo Software team is dedicated to working closely with the open source community and with projects that are affected by a vulnerability, in order to protect users and ensure a coordinated disclosure. When we identify a vulnerability in a project, we will report it by contacting the publicly-listed security contact for the project if one exists; otherwise we will attempt to contact the project maintainers directly.

If the project team responds and agrees the issue poses a security risk, we will work with the project security team or maintainers to communicate the vulnerability in detail, and agree on the process for public disclosure. Responsibility for developing and releasing a patch lies firmly with the project team, though we aim to facilitate this by providing detailed information about the vulnerability.

Our disclosure deadline for publicly disclosing a vulnerability is: 90 days after the first report to the project team.

We appreciate the hard work maintainers put into fixing vulnerabilities and understand that sometimes more time is required to properly address an issue. We want project maintainers to succeed and because of that we are always open to discuss our disclosure policy to fit your specific requirements, when warranted.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality Low
Integrity Low
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

CVE ID

CVE-2024-47765

Credits