The export-rows
command can be used in such a way that it reflects part of the request verbatim, with a Content-Type header also taken from the request.
An attacker could lead a user to a malicious page that submits a form POST that contains embedded JavaScript code. This code would then be included in the response, along with an attacker-controlled Content-Type
header, and so potentially executed in the victim's browser as if it was part of OpenRefine.
The attacker must know a valid project ID of a project that contains at least one row.
The malicious form sets contentType
to text/html
(ExportRowsCommand.java line 101) and preview
to true
(line 107). This combination causes the browser to treat what OpenRefine thinks of as an export preview as a regular webpage.
It would be safer if the export-rows
command did not allow overriding the Content-Type header at all, instead relying on the exporter to provide the correct Content-Type. It could also require a CSRF token. As an additional measure, it could add a Content-Security-Policy header to the response disabling scripts and such entirely.
At least the CSV exporter (separator
and lineSeparator
fields) and templating exporter (any field) are affected. It may also be possible to inject into the dateSettings.custom
field or the SQL exporter default value field, if the project contains date or null cells.
An example form that demonstrates the issue is available on https://wandernauta.nl/os/.
Execution of arbitrary JavaScript in the user's browser. The attacker-provided code can do anything the user can do, including deleting projects, retrieving database passwords, or executing arbitrary Jython or Closure expressions, if those extensions are also present.