CVE-2024-10031

Vulnerability Description: Cross-site Scripting (Stored) - CWE-79

Software Version: 7.0.15

NIST: https://nvd.nist.gov/vuln/detail/CVE-2024-10031

CVSS: 5.4

Severity: Medium

Credits: Claudia Bartolini, Marco Ventura, Andrea Carlo Maria Dattola, Debora Esposito, Massimiliano Brolli

In Eclipse GlassFish version 7.0.15 is possible to perform Stored Cross-site scripting attacks. Stored cross-site scripting vulnerabilities arise when user input is stored and later embedded into the application's responses in an unsafe way. An attacker can use the vulnerability to inject malicious JavaScript code into the application, which will execute within the browser of any user who views the relevant application content.

Step-by-step instructions and PoC

A remote user, that has the permissions to modify the configuration file through the Operating System, can store malicious JavaScript code within the “groups” parameter. Successfully exploitation of this vulnerability can cause the extraction of some information and/or the execution of arbitrary HTTP Request in the context of victim's session.

Affected Endpoints

•          URL: https://[IP]:[PORT]/management/domain/configs/config/server-config/security-service/auth-realm/admin-realm/list-users

•         Vulnerable Configuration Parameter: groups

Below there is the evidence with the vulnerability details and the payloads used.

Payload used to exploit the vulnerability:

echo "user3;{SSHA256}qXV9vLHbkJRoMaJkGsNUrz5jSHDzMTR0CyFmZjUt8HJQVlIi2X8XaA==;asadmin<img src=x onerror=alert(1)>" >> {PATH}/glassfish7/glassfish/domains/domain1/config/admin-keyfile

This first step consists of add the malicious user in the admin-keyfile configuration file, as reported previously.

Below the evidence of the javascript code injection in the web pages that show the groups value:

Security Impact

An attacker can exploit this vulnerability to extract some information or run arbitrary HTTP Request in the context of victim's session.

Remediation Steps

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:

-        Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.

-        User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.

Torna indietro