OpenRefine's error page lacks escaping, leading to potential Cross-site Scripting on import of malicious project

Vulnerability

The OpenRefine error page, displayed when an exception occurs, includes the exception message and stack trace without escaping HTML tags [1][3]. This means an attacker who can influence an error message (for example, by crafting a malicious file that causes an exception with an attacker-controlled message) can inject arbitrary HTML and JavaScript into the page when the victim views it [4]. The vulnerable code paths are in Command.respondWithErrorPage and HttpUtilities.respondWithErrorPage, which render the Velocity template error.vt [3]. The template directly includes $message and $stack variables without sanitization [3].

Exploitation

In the base OpenRefine product, the most plausible way to trigger an attacker-influenced error is by convincing a victim to import a malicious project file [1][4]. This could be delivered via a URL or uploaded file, as shown in the project's proof-of-concept (see reference [4] for the link). However, out-of-tree extensions may also call respondWithErrorPage in ways that could expose additional attack surfaces [1][4]. Note that errors reported as JSON responses are not affected because they are not interpreted as HTML by the browser [4].

Impact

Successful exploitation leads to execution of arbitrary JavaScript in the victim's browser within the context of the OpenRefine session [4]. The attacker's script can perform any action the victim is able to do, such as modifying projects, accessing data, or performing other operations available in the web interface. The impact is moderate, as it requires user interaction (importing a malicious project) and relies on the victim being logged into OpenRefine [1][4].

Mitigation

The vulnerability is fixed in OpenRefine version 3.8.3 [1][4]. Users should upgrade to this version or later. There is no mention of a workaround for older versions in the available references.